[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] The state of MRTs
On Tue, Mar 20, 2012 at 7:56 PM, Gregg Tavares (勤) <firstname.lastname@example.org> wrote:
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.
*) 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.
*) 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.