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

Re: [Public WebGL] EXT_shader_texture_lod in WebGL2?

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?

Kind Regards,

On 20 January 2017 at 18:24, Zhenyao Mo <zmo@chromium.org> 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 <jujjyl@gmail.com> 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 time.

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?