[Public WebGL] EXT_shader_texture_lod in WebGL2?

Kenneth Russell [email protected]
Mon Jan 23 09:52:17 PST 2017

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

> I'm not sure ETC1 is supported by desktop either, but has almost identical
> support stats. It suggests that they have same code-path for both formats.
> OES_texture_float shows high support, but reality is that in some cases it
> is not "real 32bit", we've got to that problem where been packing stuff
> into it assuming it was 32 bits, but on some Android it was coming totally
> weird. So we've implemented a test for precision of it:
> https://github.com/playcanvas/engine/blob/master/
> src/graphics/device.js#L721

That's unexpected. Would you please put up a pull request adding a test
case to the WebGL conformance test
sdk/tests/conformance/extensions/oes-texture-float.html in
https://github.com/KhronosGroup/WebGL ? It looks like
requires that the 32-bit floating-point texture formats are really 32-bit,
so any loss in precision is unexpected.

Note that the floating-point precision in shaders may be applying here. I
haven't re-checked the ESSL 1.00 spec but you would almost certainly need
to use highp precision, and I'm not sure that that guarantees full 32-bit

> Bliting depth texture in WebGL 2 on Windows (only) does gets into CPU
> path, making performance to go below the floor. https://bugs.chromium.
> org/p/angleproject/issues/detail?id=1710

Thanks for your input on this and for your test case. I've raised the bug
to high priority and we'll try to figure out what's going wrong with
ANGLE's handling of multisampled depth textures. I can tell you that a
couple of days were invested trying to integrate your sample code and it's
not trivial to figure out why it doesn't work in the context of ANGLE.

And I bet there is much more, of cases. The problem is profiling them is
> nearly impossible, and when performance is bad in complex applications,
> developer spends a lot of time figuring out what's the heck. And after
> long-long pain, things might point to one or the other thing, again, ANGLE..
> *ANGLE - is great, and WebGL wouldn't be possible without it.*
> But there are certain ideology used, that are extremely harmful to whole
> WebGL platform. CPU paths and dishonesty of API - is one of them.

Max, this is unkind to the ANGLE developers and irrelevant to the Android
issue you raised above; ANGLE is not used on that platform.

We want to work with you and other developers pushing the leading edge to
address these issues and ensure portability, high performance, and a good
feature set for WebGL. Please keep the conversations civil and please
continue to point out issues you encounter.


> Kind Regards,
> Max
> On 21 January 2017 at 22:03, 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]>
>>> wrote:
>>>> This suggests they haven't done it:
>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=658763&desc=2
>>>> 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 EAC.
>>>>> 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]
>>>>>> > wrote:
>>>>>>> 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.
>>>>>> https://www.khronos.org/webgl/public-mailing-list/archives/1
>>>>>> 609/msg00074.php
>>>>>> 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/20170123/e8d19a99/attachment.html>

More information about the public_webgl mailing list