[Public WebGL] EXT_shader_texture_lod in WebGL2?

Kai Ninomiya [email protected]
Sat Jan 21 14:58:53 PST 2017


FYI I checked FF beta and it is still enabled, so they probably didn't have
time before their WebGL 2 launch.

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

> Changed the text to:
>
> Often implemented in browsers by decompressing on the CPU and uploading
> full size to GPU with severe performance, vram and quality impacts. Fixed
> in Chrome 57 and Firefox ??
>
>
>  Will remove the warning a month after the fix has landed in Chrome and
> Firefox public releases (Jeff please inform me which FF version).
>
> On Sat, Jan 21, 2017 at 11:28 PM, Kai Ninomiya <[email protected]> wrote:
>
> 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
> January).
>
> 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.
>
> -Kai
>
> 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]>
> 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/1609/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/20170121/5074addf/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/5074addf/attachment.p7s>


More information about the public_webgl mailing list