[Public WebGL] EXT_shader_texture_lod in WebGL2?

Kai Ninomiya [email protected]
Sat Jan 21 14:28:08 PST 2017

In Chrome, the ETC1+2 formats should be disabled on both WebGL 1 and WebGL
2 on ANGLE (i.e. Windows) unconditionally. Unfortunately I made a mistake
in my first patch to disable ETC1 on ANGLE, so it won't roll out until
Chrome 57 (beginning of March). ETC2 should be correct in 56 (end of

So the warning should very soon become outdated, and it would be good to
mention that in the warning text. I am not sure about the status in Firefox
but IIRC they agreed to implement the same semantics and it's probably in
the version they are releasing this week(?)

The linked bug (658763) is for re-enabling it on desktop platforms which
have hardware support (maybe Intel), and for ANGLE on other platforms.


On Sat, Jan 21, 2017, 2:04 PM Florian Bösch <[email protected]> wrote:

I'll add a disclaimer to the ETC and ETC1 extension that empathically
discourages people from using these extensions. Are there any other
extensions I should warn people not to use?

On Sat, Jan 21, 2017 at 11:01 PM, Florian Bösch <[email protected]> wrote:

Well we had the lengthy debate with a clear outcome, do not expose
capabilities that the hardware doesn't support, especially not when the
emulation has drastically different characteristics and leads to worse
outcomes than when it wasn't pretend supported. I'm guessing this then
falls under "WebGL1 is in maintenance mode and we won't fix it."?

On Sat, Jan 21, 2017 at 10:54 PM, Maksims Mihejevs <[email protected]>

This suggests they haven't done it:

We wanted to add ETC2 support, but currently blocked by this, as it is
totally unacceptable path: more VRAM (comparing to alternatives) and more
Download size.

On 21 January 2017 at 21:46, Maksims Mihejevs <[email protected]> wrote:

Correct me if I'm wrong.
But ETC2 and EAC is mandatory on OpenGL ES 3.0+ and OpenGL 4.3+ right?
I could not find any information that Nvidia GPU actually supports ETC2 and

On Windows, using ANGLE, there is no OpenGL involved.

So why then we seeing 71% support of WEBGL_compressed_texture_etc on
Desktop Windows? And where there is OpenGL, such as Linux and OSX, we see
only 5% on Linux, and 0% on OSX? :)

I believe, they haven't actually decided anything, and wen't their way
regarding CPU path, unless there is somebody here to prove that I'm wrong.

On 21 January 2017 at 15:55, Florian Bösch <[email protected]> wrote:

On Sat, Jan 21, 2017 at 1:32 PM, Maksims Mihejevs <[email protected]>

We've seeing already many enormous issues. For example MSAA with ANGLE has
CPU path, and is unusable at all, as performance drops insanely. ETC2 was
another case where CPU path was pushed a lot.

Are you sure ETC2 is software decoded and put on the GPU plain? Because if
so, we've had a lengthy debate in 2016 about ETC1 that ended with Jeff
Gilbert stating:

Update: The WG is planning on only exposing the extension where there
is 'native' support. (Not D3D, maybe not Desktop NV?) We feel this
best matches what devs expect when they see support for a compressed
texture extension. Compressed image formats are a better delivery
mechanism than compressed texture formats, if they're going to be
decompressed anyway.


I don't believe we'll need to have this debate all over again... do we?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170121/ee2e4cec/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4845 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170121/ee2e4cec/attachment.p7s>

More information about the public_webgl mailing list