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

Re: [Public WebGL] Please review WebGL multiple render target extension proposal



On Sat, Nov 3, 2012 at 12:04 AM, Cedric Vivier <cedricv@neonux.com> wrote:
> On Sat, Nov 3, 2012 at 4:07 AM, Kenneth Russell <kbr@google.com> wrote:
>> Are there any objections to moving the WebGL MRT extension spec from
>> "proposed" to "draft" status? This would enable prefixed prototypes
>> (i.e., MOZ_WEBGL_multiple_render_targets,
>> WEBKIT_WEBGL_multiple_render_targets).
>
> There is a minor typo for DrawBuffersWEBGL, it should start with a
> lowercase "d".

Thanks for catching this. Fixed.

> Other than this, what do you think of getting get rid of the _WEBGL
> suffixes everywhere?
>
> In WebGL, namespacing is already handled through the WebGL extension
> object, therefore the suffixes are unnecessary and makes the API feel
> quite verbose/alien imho.
>
> Additional benefit is that it simplifies porting and
> backward-compatibility shims whenever we have ES 3.0 support directly
> in the core API.

Will reply later in the thread.

-Ken


> Regards,
>
>>
>> Even though the underlying ANGLE extension still needs to be
>> thoroughly reviewed by TransGaming, I don't anticipate major changes.
>> It merely pulls the OpenGL ES 3.0 semantics for MRTs back to OpenGL ES
>> 2.0. The only potential issue I can think of is that two extensions
>> (fbo_color_attachments and draw_buffers) were merged into one, and the
>> extension name exposed to GLSL was changed; if this turns out to be a
>> problem for some reason, then the extension might need to be split up.
>>
>> -Ken
>>
>>
>> On Wed, Oct 17, 2012 at 11:45 AM, Kenneth Russell <kbr@google.com> wrote:
>>> Yes.
>>>
>>>
>>> On Wed, Oct 17, 2012 at 11:25 AM, Florian Bösch <pyalot@gmail.com> wrote:
>>>> Right, so the idea's to introduce FP-textures properly a second time around
>>>> which would modify the framebuffer/mrt extensions clamping behavior?
>>>>
>>>>
>>>> On Wed, Oct 17, 2012 at 8:14 PM, Kenneth Russell <kbr@google.com> wrote:
>>>>>
>>>>> Ah, sorry, pulled the trigger too quickly on that email. I see the
>>>>> section you're pointing out.
>>>>>
>>>>> It's been pointed out most vehemently by Mark Callow that I in
>>>>> particular glossed over the subtleties of floating-point render
>>>>> targets when adding optional support for them in the WebGL exposure of
>>>>> OES_texture_float. There is an ongoing discussion about the
>>>>> correctness of the OES_texture_float conformance test as well
>>>>> (http://www.khronos.org/bugzilla/show_bug.cgi?id=729).
>>>>>
>>>>> Another OpenGL ES extension proposal should be coming soon which
>>>>> supports floating-point render targets more thoroughly than WebGL's
>>>>> exposure of OES_texture_float, and I think that rather than try to
>>>>> patch up the existing specs we should just wait for that one to come
>>>>> along and then point to it. From the standpoint of the MRT extension,
>>>>> OES_texture_float should be considered to affect individual color
>>>>> attachments in the same way that it affects the previous single color
>>>>> attachment to FBOs. I wouldn't want to do a half-baked job again
>>>>> trying to add FP render target support to this MRT extension so again
>>>>> let's wait for the new extension.
>>>>>
>>>>> The vast majority of ES 2.0 hardware will not support floating-point
>>>>> render targets, but my hope is that some or most ES 3.0 hardware will.
>>>>>
>>>>> -Ken
>>>>>
>>>>>
>>>>> On Wed, Oct 17, 2012 at 11:04 AM, Kenneth Russell <kbr@google.com> wrote:
>>>>> > This is pretty much an orthogonal question to the MRT proposal. Please
>>>>> > start a new thread for it.
>>>>> >
>>>>> > -Ken
>>>>> >
>>>>> >
>>>>> > On Wed, Oct 17, 2012 at 2:11 AM, Florian Bösch <pyalot@gmail.com> wrote:
>>>>> >> I think that's fine. I've got one question though. I know that when I
>>>>> >> attach
>>>>> >> a floating point texture, that the output values are not clamped to
>>>>> >> 0-1. I
>>>>> >> also know that the OpenGL ES 2.0 specification states the clamping as
>>>>> >> behavior (which is also mentioned in this extension). I'm not sure, but
>>>>> >> I
>>>>> >> think the desktop versions of OpenGL don't specify the clamping at the
>>>>> >> shader output level (there's some function to control clamping).
>>>>> >>
>>>>> >> I'm a bit worried that this might be a behavioral difference between
>>>>> >> Mobiles/Desktops that could shoot you in the foot if/when you find a
>>>>> >> mobile
>>>>> >> with floating point texture render target support. Anybody know if
>>>>> >> mobiles
>>>>> >> do the clamping regardless of target format?
>>>>> >>
>>>>> >> On Wed, Oct 17, 2012 at 3:51 AM, Kenneth Russell <kbr@google.com>
>>>>> >> wrote:
>>>>> >>>
>>>>> >>>
>>>>> >>> Please review an extension proposal adding multiple render target
>>>>> >>> functionality to WebGL:
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiple_render_targets/
>>>>> >>>
>>>>> >>> It mirrors a proposed extension for ANGLE which adds this
>>>>> >>> functionality to OpenGL ES 2.0:
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> https://angleproject.googlecode.com/svn/trunk/extensions/ANGLE_multiple_render_targets.txt
>>>>> >>>
>>>>> >>> Please provide your feedback on both.
>>>>> >>>
>>>>> >>> Apologies for how long it took to produce these extensions. They
>>>>> >>> couldn't be drafted until OpenGL ES 3.0 was released, because in order
>>>>> >>> to avoid compatibility issues in the future, it was necessary to
>>>>> >>> derive their contents from the ES 3.0 specification. The draft ANGLE
>>>>> >>> extension modifies the same areas of the OpenGL ES 2.0 specification
>>>>> >>> modified by the GL_NV_fbo_color_attachments and GL_NV_draw_buffers
>>>>> >>> extensions, but draws the majority of its text and semantics from the
>>>>> >>> ES 3.0 spec.
>>>>> >>>
>>>>> >>> -Ken
>>>>> >>>
>>>>> >>> -----------------------------------------------------------
>>>>> >>> 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
>> -----------------------------------------------------------
>>

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