On Tue, Mar 20, 2012 at 2:03 PM, Florian BÃsch <email@example.com>
On Tue, Mar 20, 2012 at 7:56 PM, Gregg Tavares (å) <firstname.lastname@example.org>
So I've been meaning to propose this. Here's a first stab
I think the fbo_color_attachments name is wrong. I used that one back when I wrote my message board entry because NV_draw_buffers wasn't on the extension list (but I saw it show up on device statistics). The correct one would probably be WEBGL_draw_buffers, and it would be permissible to emulate it with ARB_draw_buffers, NV_draw_buffers or NV_fbo_color_attachments.
How it's emulated is relevant as long as it works no?Â
*) It's not really a new feature. No new APIs are added. It's similar to texture fetch in vertex shaders where the max allowed is allowed to be 1.
Some new API will be required to specify the FBO attachment point.
Âgl.framebufferRenderbuffer(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT7, gl.RENDERBUFFER, somerenderbuffer);
Âgl.framebufferTexture2D(gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT6, gl.TEXTURE_2D, sometexture, 0);
What new API is needed?
*) It's relatively easy to implement
I think there might be trouble in getting the HLSL cross compiler to accept N > 0 (at least it's an angleproject update)
I don't really see that as much a valid argument in that some day this feature will be supported one way or another (WebGL 2.0?), at that point the same issue will exist, some hardware will support 0, some 4, some 8, some 16, etc.. Apps that use multiple render targets will have to have fallbacks for hardware that doesn't support the number they ideally need.ÂSo, why not just expose it now?
I'm all for exposing. On the topic of fallbacks. It would probably be possible to intercept shader source calls and dissect shaders so that the identical API could seamlessly work but instead of using MRT it just draws multiple times invisibly behind.
I don't think that's possible. Each draw call may effect depth and stencil buffers and so the next call would not do the same thing as the previous.Â