[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] The state of MRTs



On Fri, Mar 30, 2012 at 4:15 PM, Kenneth Russell <kbr@google.com> wrote:
>
> On Tue, Mar 20, 2012 at 11:56 AM, Gregg Tavares (å) <gman@google.com> wrote:
>> So I've been meaning to propose this. Here's a first stab
>>
>> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/WEBGL_fbo_color_attachments/index.html
>
> A few technical issues:
>
> 1) I think it is also necessary to include the DrawBuffers entry point
> in this extension. Even when rendering to an FBO, DrawBuffers maps the
> color attachments to gl_FragData's indices. If DrawBuffers isn't
> included, then this extension defines behavior which would be
> divergent from, say, the OpenGL 4.2 core spec's behavior, or that of
> NV_draw_buffers.
>
> 2) Regarding "Referencing gl_FragData[n] where n is greater then the
> number of supported attachments will generate a GLSL compile or linker
> error.": it's not feasible to enforce this behavior. At best it would
> require extensive static analysis of shaders and at worst it won't be
> able to be determined at compile time. Instead, similar language to
> that in http://www.khronos.org/registry/webgl/specs/latest/#4.5 should
> be used; the behavior should be that the gl_FragData index is clamped
> between 0..getParameter(MAX_COLOR_ATTACHMENTS).

Array accesses are already restricted to constant integer expressions.
What is this extensive static analysis that would be required? In what
case would the gl_FragData index be undeterminable at compile time?

> 3) If the intent is to make this extension truly complete then there
> is a lot of spec language missing which affects the behavior of the
> OpenGL ES 2.0 pipeline. See for example
> http://www.khronos.org/registry/gles/extensions/NV/GL_NV_draw_buffers.txt
> . Note that despite the naming, NVIDIA's extension actually applies
> only to FBOs: "DrawBuffersNV may only be called when the GL is bound
> to a framebuffer object".
>
> As I see it, (3) is the most serious concern with introducing this
> particular extension. MRTs seem to modify the behavior of the OpenGL
> pipeline in several places. If future mobile hardware happens to come
> out with MRT support, but its semantics are slightly different than
> that in this extension, then it won't be possible to fold this
> extension into the core WebGL spec. I don't know how big a problem
> this would be. Maybe if a hypothetical WebGL 2.0 incorporated MRT
> support, then that context type could drop support for the
> "WEBGL_draw_buffers" extension. Or, per my other email, maybe this
> extension could be left in draft state indefinitely, so that it's
> always vendor prefixed and browsers wouldn't have to commit to
> supporting it forever.
>
> I think that the majority of this extension's behavior should be
> defined in an ANGLE extension, as has been done for some others; see
> http://code.google.com/p/angleproject/source/browse/trunk#trunk%2Fextensions
> . Then this WebGL extension could reference the other one. (The ANGLE
> extension would be needed anyway to make this functionality work in
> Chrome on Windows, and any other browsers using ANGLE.)
>
> -Ken
>
>
>> Whether there's any chance to get it approved by the group I don't know.
>>
>> Arguments for:
>>
>> *) Multiple render targets are super awesome! Lots, in fact most modern
>> graphics applications use this feature extensively. Supporting it will go a
>> long way to helping adoption of WebGL with more impressive apps.
>>
>> *) 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.
>>
>> *) It's relatively easy to implement
>>
>> *) It doesn't raise any extra security or validation issues that I know of.
>>
>> Arguments against:
>>
>> *) Some mobile hardware only supports 1 target.
>>
>> 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?
>>
>>
>
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------