[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:33 PM, David Sheets <kosmo.zb@gmail.com> wrote:
> 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?

It would be necessary to compute the minimum and maximum values for
the index expression as the loop iteration variable goes through its
range, and the math in the expression can potentially be complex.
ANGLE's shader translator doesn't contain any loop analysis code right
now and I think it's overkill to require its introduction just for
this extension so that the shader compilation can fail. All of the
other out-of-range array access behavior in the WebGL spec is defined
in a way that allows simple but secure implementations.


>> 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