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

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



Indeed, that is my understanding of their original purpose and meaning, but for WebGL, I believe it is largely irrelevant.

I should think that translation to WebGL constants already needs to go through a translation step here, since you can't use |GL_HALF_FLOAT_OES| directly anyway. Instead, the translator not only needs to be aware of the |WebGLContext| object, but it needs to query the extension from it, and *from that extension object*, access |OES_texture_half_float.HALF_FLOAT_OES|.

On the human translation front, it's exceedingly simple to just drop vendor suffixes and such: |HALF_FLOAT_OES| becomes |HALF_FLOAT|. It's not even easy to keep straight which extensions are EXT or ARB, or which are KHR vs. OES. This is less of an issue with WebGL, since you need to query the extension to get the functionality you want. (which is fantastic, might I add)

Further, in not so many words, do WebGL devs really care which vendor originally wrote an extension? If we want to let people know which extension mirrors what, we should just put a note in the extension document, or even a link to the original. (We already do both, actually)

Original:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 16, 16, 0, GL_RGBA, GL_HALF_FLOAT_OES, nullptr);

WebGL with vendor decorations:
var ext = gl.getExtension("OES_texture_half_float");
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 16, 16, 0, gl.RGBA, ext.HALF_FLOAT_OES, null);

WebGL without vendor decorations:
var ext = gl.getExtension("texture_half_float");
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 16, 16, 0, gl.RGBA, ext.HALF_FLOAT, null);

Given the documentation we already do for WebGL extensions, I don't think the second case has any benefit over the third.

----- Original Message -----
From: "Florian Bösch" <pyalot@gmail.com>
To: "Jeff Gilbert" <jgilbert@mozilla.com>
Cc: "Cedric Vivier" <cedricv@neonux.com>, "Brandon Jones" <bajones@google.com>, "public webgl" <public_webgl@khronos.org>, "Kenneth Russell" <kbr@google.com>
Sent: Tuesday, November 6, 2012 5:25:21 AM
Subject: Re: [Public WebGL] Please review WebGL multiple render target extension proposal

The suffix derives from the prefix. There are different classes/meanings of them. 


OpenGL: 
- <vendor>: vendor specific extensions, we're not doing those afaik 
- EXT: extensions implemented by multiple vendors, but not ratified by the architecture review board 
- ARB: extensions ratified by the architecture review board 


OpenGL ES: 
- <vendor>: vendor specific extensions, we're not doing those afaik 
- OES: extensions ratified by the architecture review board specific to ES 
- EXT/ARB: extensions which mirror OpenGL extensions 1:1 


WebGL: 
- OES/EXT/ARB: extensions which mirror the ES extensions 1:1 
- WEBGL: extensions which are specific to webgl 


Now there is a a fairly good reason to keep extension suffixes where extensions are mirrored. The reason is that people who have code already written against those extensions will try to access symbols/enumerants with the suffix. However the original reason for the suffix was that there is one global namespace in C for enumerants, and symbols/enums couldn't co-exist. 


There might be a fairly good reason to keep the WEBGL suffix such as to support the automatisms that people with existing wrappers already have. But other than that, the original reason to keep the suffix is absent. So it seems to me the debate around a WEBGL suffix is mainly a debate around how important code auto generators are that specifically want to target WEBGL and whom we wouldn't want to write a couple extra conditionals to handle WEBGL specific extensions slightly differently. 



On Tue, Nov 6, 2012 at 1:42 PM, Jeff Gilbert < jgilbert@mozilla.com > wrote: 


I would actually be strongly in favor of dropping extension vendor prefixes and suffixes where they don't add value. (Which, it seems to me, is everywhere) I'm all ears if someone has a great reason for them at the WebGL level. At Mozilla, we're actually moving away from vendor decorations on functions or constants, with the notable exception of ANGLE-only extensions. 

With WebGL's extra layer of namespacing provided by things being attached to extension objects, I don't see a compelling reason to keep the extra verbosity. 

I'll add that I would disagree that we should seek to copy OpenGL in every detail, but this is somewhat beyond the scope of this discussion. I think using objects instead of int handles, locking down UniformLocations, and the variety of texImage2D calls were fantastic choices. I only wish we went further in this direction. 



----- Original Message ----- 
From: "Cedric Vivier" < cedricv@neonux.com > 
To: "Kenneth Russell" < kbr@google.com > 
Cc: "Brandon Jones" < bajones@google.com >, "Florian Bösch" < pyalot@gmail.com >, "public webgl" < public_webgl@khronos.org > 
Sent: Monday, November 5, 2012 11:21:44 PM 
Subject: Re: [Public WebGL] Please review WebGL multiple render target extension proposal 


On Tue, Nov 6, 2012 at 7:40 AM, Kenneth Russell < kbr@google.com > wrote: 
> A central tenet of WebGL is that it doesn't arbitrarily diverge from 
> the OpenGL rules. If this change were made, then it could be argued 
> that all of the other WebGL extensions like 
> EXT_texture_filter_anisotropic, OES_standard_derivatives, etc. would 
> drop the suffixes from the enums they expose. 
> I don't think this is a 
> good idea so am leaving the naming convention as it stands. 

I have no issue using suffixes from native EXT or OES when they already exist. 
Indeed, staying as close as OpenGL as possible is one of the great 
feature of WebGL. 
But I'm not sure to agree this is a case of diverging from OpenGL here 
as we are not reusing an existing 'MRT all-in-one' native extension 
here - and our extension system is already divergent per-design 
anyways. 

Also, WEBGL_debug_shaders, which is the first and only approved 
WEBGL_* extension to introduce a function signature, already does not 
follow this as it declares getTranslatedShaderSource, not 
getTranslatedShaderSourceWEBGL. 


> cleanup will give us all something to look forward to when the OpenGL 
> ES 3.0 functionality is folded in to the core WebGL spec. 

Cleaning up the names now will allow developers to access MRT-related 
enums and functions in a backward compatible way on both WebGL ES 2.0 
and WebGL ES 3.0 contexts using something as simple as "glmrt = 
gl.drawBuffers ? gl : gl.getExtension("WEBGL_MRT");". 


Either way, I still think we should take the opportunity of clarifying 
now that WEBGL_ extensions do or do not not need suffixes while we 
still haven't clearly moved in one direction or another (the currently 
approved WEBGL extensions are in an unfortunate 50/50 situation - one 
with two _WEBGL-suffixed enums, the other with no suffix on an 
function signature). 


Thoughts? 


> 
> -Ken 
> 
> 
> On Sun, Nov 4, 2012 at 8:32 PM, Brandon Jones < bajones@google.com > wrote: 
>> Most extensions use postfixes, they're just normally OES, EXT, etc. I'm not 
>> sure why WEBGL would be a special case. 
>> 
>> 
>> On Sun, Nov 4, 2012 at 8:00 PM, Cedric Vivier < cedricv@neonux.com > wrote: 
>>> 
>>> On Sat, Nov 3, 2012 at 11:05 PM, Florian Bösch < pyalot@gmail.com > wrote: 
>>> > That awkward moment you realize you've been doing something annoying but 
>>> > you 
>>> > keep on doing it because it would be silly to stop now. I can tell you 
>>> > all 
>>> > about it :) 
>>> 
>>> IIRC we have only one 'approved' extension using the WEBGL postfix 
>>> enums right now : WEBGL_debug_renderer_info, a somewhat minor and very 
>>> webgl-specific one that is. 
>>> So it is imho something we could and should fix now before promoting 
>>> any new extension to draft or 'approved' status. 
>>> 
>>> Regards, 
>>> 
>>> 
>>> > 
>>> > 
>>> > On Sat, Nov 3, 2012 at 3:59 PM, Brandon Jones < bajones@google.com > 
>>> > wrote: 
>>> >> I'm not sure what the reasoning is behind the WEBGL postfix, but I 
>>> >> agree 
>>> >> with Cedric: it does lend a somewhat clunky feel to the function calls. 
>>> >> I 
>>> >> wouldn't be sad to see them go. 
>>> >> 
>>> >> Of course, this isn't the only extension that does this 
>>> >> (OES_vertex_array_object postfixes all of its functions as well) so it 
>>> >> may 
>>> >> be even more awkward to stop doing it now. 
>>> >> 
>>> >> On Nov 3, 2012 12:07 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". 
>>> >>> 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. 
>>> >>> 
>>> >>> 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 
>>> >>> ----------------------------------------------------------- 
>>> >>> 
>>> > 
>> 
>> 

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