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

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



On Sun, Nov 4, 2012 at 5:16 PM, David Sheets <kosmo.zb@gmail.com> wrote:
> On Fri, Nov 2, 2012 at 1:07 PM, 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).
>
> No objections from me. Looks great!
>
> The WebGL 1.0.1 spec link is broken. Has 1.0.1 been published
> separately? Perhaps it is compatible with 1.0?

Sorry about this. No, 1.0.1 hasn't been officially published yet. A
snapshot was taken many months ago, but due to driver bugs on Mac OS
in particular, it is not yet possible for any browser vendor to pass
the 1.0.1 conformance suite according to the current conformance
rules. For this reason we have held off publishing this version of the
spec. The top of tree spec has continued to evolve.

To fix the broken link I changed this extension to reference version
1.0 of the spec for the time being.

-Ken


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