[Public WebGL] EXT_shader_texture_lod in WebGL2?
Fri Jan 20 11:35:41 PST 2017
Zhenyao, question regarding availability of EXT_shader_texture_lod in
webgl1, we've noticed at PlayCanvas lack of it on many mobile platforms,
and had to come up with several workarounds for different things. One of
them is image based lighting for physically based rendering. On those
platforms we have to use alternative approach, and on runtime generate
atlas texture with all mip levels in it, so in shader we have to do 2
samples and lerp between them, basically simulating LoD.
For IBL using cube maps, you would store different prefilter levels of
cubemap as mips, and then with texture_lod simply pick them.
This drives big problems, and makes IBL quiet slow on those platforms,
because as you guess, sampling twice same texture from very different
locations (atlas), leads to constant sample block cache revalidation. And
this has pretty sad impact on performance.
Question is: *how much of a trouble would be actually make texture_lod
still work when webgl1 is implemented on top of ES3?*
On 20 January 2017 at 18:24, Zhenyao Mo <[email protected]> wrote:
> Underlying ES3 drivers don't expose the EXT_shader_texture_lod, so
> currently you are not getting EXT_shader_texture_lod on most mobile
> platforms in WebGL1 because we don't expose this if WebGL1 is implemented
> on top of ES3 drivers.
> There are other incompatibilities between WebGL1/WebGL2 shaders, like
> texture2D -> texture, etc. You will need to rewrite or prep-process your
> old shaders anyway. I don't see a strong reason to expose older semantics
> for texture lod in WebGL2.
> On Fri, Jan 20, 2017 at 7:46 AM, Jukka Jylänki <[email protected]> wrote:
>> I'm working on upgrading an engine to use WebGL 2 from WebGL 1, and I
>> find that EXT_shader_texture_lod has been added to the core WebGL 2 spec.
>> In WebGL 2, one can write #version 100 and #version 300 es shaders, with
>> the idea that in WebGL2, one could reuse GLSL 1.0/GLES2 shaders without
>> having to mass re-write all of them to GLSL 3.00/GLES3 when migrating.
>> This is great for backwards compatibility, however I find that neither
>> Firefox or Chrome implementations of WebGL 2 expose EXT_shader_texture_lod
>> anymore. This means that if one does run #version 100 shaders in a WebGL 2
>> context, they lose the ability to do textureCubeLodEXT() and so forth,
>> which forces one to go and mass convert all shaders to GLSL 3.00/GLES3. If
>> one wants to simultaneously target both WebGL1 and WebGL2, i.e. gracefully
>> falling back to WebGL1 on older browsers, this means that one needs to
>> author two versions of each shader that needs this extension, which is a
>> lot of hassle to manage.
>> Could implementations still carry EXT_shader_texture_lod around in WebGL
>> 2 so that #version 100 shaders with that extension would still keep
>> working? I know WebGL is neither backwards or forwards compatible, but it
>> would be great to minimize these types of breaking changes where possible,
>> so that engines that co-target both versions on the fly would have easier
>> Though I do admit I'm not completely sure how this looks like in
>> different vendors' native GLES3 implementations, and if they have this
>> mechanism available as well for this extension.
>> Does anyone know if there was any fundamental reason to not advertise
>> EXT_shader_texture_lod anymore in WebGL 2, or was it just a "oh, that's in
>> core now so no need to have it present anymore" type of thought?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl