[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 11:56 AM, Gregg Tavares (勤) <firstname.lastname@example.org> wrote:
> So I've been meaning to propose this. Here's a first stab
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
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
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
. 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
. 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.)
> 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 email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: