WebGL Angle DX9 Stencil Bugs

[Alecazam]

I'm seeing stencil bugs in Chrome that aren't present in Firefox on Windows 7.   This leads to a lot of rendering issues with polygons where stencil is used for the winding count.  This is on an older AMD 5650 HP Envy 14 with switchable graphics.   The old Chrome/Firefox had the canvas flipped incorrectly, but the newer builds have corrected that.

The only difference that I can tell is that Firefox is running DX11, but Chrome disables DX11 in favor of DX9 backend as a bug workaround.    I tried enabling OpenGL backend on both browsers.  Not sure how yet to force the DX11 path.   In Chrome, this is far from easy since you have to kill all instances, and set a command line argument on the shortcut.   

With WebGL, Chrome complains "Not enough varyings or uniforms".  Huh?  It's the same card, and should have more of these accessible in OpenGL than the DirectX backend.  Firefox is so much easier to switch to OpenGL, but complains about the GPU being blacklisted.  I'll see how to workaround the blacklist now, but a few users have been reporting the same issue.  The inability to switch easily to OpenGL is a big problem.  ANGLE's translation layer isn't always the most optimal, and OpenGL seems like a much more direct path for shaders and commands even if the drivers aren't as solid for OpenGL.

[Kenneth Russell]

Do you have a reduced test case for the stencil bugs you're seeing in ANGLE's D3D9 backend? If so could you please file a bug on https://bugs.chromium.org/p/angleproject/issues/list ?

Also, how exactly are you turning on Chrome's OpenGL backend? The only supported way to do this at this point is --use-angle=gl. ANGLE emulates OpenGL ES 2.0 on top of desktop OpenGL, and does it well -- this is being tested on Chrome's waterfall: https://build.chromium.org/p/chromium.gpu.fyi/console .

-Ken

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jamie Madill]

Hey all,

This is likely the same issue as http://crbug.com/597107. If you comment there that'll help.

I tried to dig into this earlier this week but was blocked because of hardware issues. Geoff and I should work on getting this fixed.

[Alecazam]

Feels like GL_INCR is mapped to D3D_STENCILOP_INCR instead of INCR_SAT. I checked the Angle source and it looked correct. This is on AMD switchable graphics. Chrome disables Angle DX11 and has the bug with Angle DX9. Firefox takes Angle DX11 and works on same GPU. Will isolate the case. Just thought something obvious might turn up.

[Alecazam]

That sounds a lot like what I'm experiencing.  This is an AMD 5650 switchable graphics card with AMD enabled.  The drivers are ancient, but Firefox works and Chrome doesn't.  Firefox takes the DX11 Angle path. I think Chrome takes the Angle DX9 path, and that AMD path, and then produces fills that don't honor the stencil.  The stencil pass uses colorWrite 0.  Intel GPU switch fixes the issue on Chrome.    Seems like messing with the color write and blend states in the state manager isn't worth the workaround.   Plus this was from 2011.   Blanket AMD switches like this without a designated driver range to apply it seems problematic and seem to lead to more harm than good.

[Alecazam]

The majority of the bugs from our users are on older AMD chips on Windows 7 and Window 10.   I tested on Intel and got a slightly different bug, but similar issues on curve fills, where the fill encompasses the entire triangle instead of being masked by stencil, but the rendering was fine in Firefox.   I'm not sure how blend state and colorWriteEnable would break things, but I can see where for a depth-stencil only target, you really don't want to enable colorWriteEnable.

[Alecazam]

So here's a capture from a user that's hitting the issue.  D3D11 is disabled due to AMD switchable graphics.  It's still really confusing since the Vendor reported is AMD, but the renderer is reported at Intel HD 4000.   Could be that ANGLE DX9 isn't classifying correctly.  Possibly taking the AMD path, even though the active GPU is Intel.  This make it look like an Intel driver bug, but the bug is actually in ANGLE DX9.

• Disable Direct3D11 on systems with AMD switchable graphics: 451420
  Applied Workarounds: disable_d3d11

GPU0	VENDOR = 0x1002, DEVICE= 0x682f
AMD switchable	true

GL_RENDERER	ANGLE (Intel(R) HD Graphics 4000 Direct3D9Ex vs_3_0 ps_3_0)
GL_VERSION	OpenGL ES 2.0 (ANGLE 2.1.0.c46018b8598d)

Not sure if these are related, but these were some of the errors that were captured.

• [9148:10208:0418/110713:ERROR:gles2_cmd_decoder.cc(7728)] : [.CommandBufferContext]RENDER WARNING: there is no texture bound to the unit 0
• [9148:10208:0418/132531:ERROR:gles2_cmd_decoder.cc(13643)] : [.CommandBufferContext.RenderWorker-03EFCC90]GL ERROR :GL_INVALID_VALUE : glCopySubTextureCHROMIUM: source texture has no level 0

[Kenneth Russell]

Unfortunately http://crbug.com/451420 was quite a tricky problem that affected many machines on Chrome Stable, and wasn't caught in automated testing before it shipped.

I'm not sure it's feasible to support D3D11 and hardware-accelerated video decoding on Windows machines with AMD switchable graphics.

-Ken

[Alecazam]

I wasn't suggesting that.  It sounds like the original bug had an bug with marking dirty state, so that might solve the issues.  Ideally the workaround could be activated by detecting the case instead of blanket application to all AMD devices/drivers.    Firefox allows the DX11 path most of the time, but I have a feeling that forcing the DX9 path would activate this bug there.

[Geoff Lang]

I believe the problem is now fixed on ToT Chrome and is testable in the latest Chrome canary (52.0.2712.0 in chrome://version/).  Can you verify that the bug is fixed there?

[Alecazam]

A quick update.  I haven't had time yet to test on my AMD machine, but our users are reporting that the bug is still there.   Maybe something specific to stencil state.  I wonder if the original workarounds are a result of state tracking bugs in ANGLE DX9.  I need to create a repro case on this.

[Alecazam]

Okay, finally had time to update to Window 10, and verified that the stencil issues occur on both Chrome and Chrome Canary on Windows 7 and Windows 10 (and likely Windows 8). No other browsers exhibit this bug, but I may have only tested the DX11 path on Firefox.  I attached the test case to the Chromium bug earlier in this thread.  We'd really like to see this fixed, as we recommend Chrome first. 

Unrelated to WebGL, but copy-pasted images from Photoshop to Chrome via DataTransfer are always downsampled by 2x in width and height in Chrome on Retina OSX.  That is also a needed fix too.  The exclusion of clipboard images and other content from the clipboard by most browsers, and in this case modification of existing data really make interop with the native app world a challenge.  I've starred the appropriate issue on that.

[Kenneth Russell]

On Fri, Apr 22, 2016 at 2:40 PM, Alecazam <al...@figma.com> wrote:

Okay, finally had time to update to Window 10, and verified that the stencil issues occur on both Chrome and Chrome Canary on Windows 7 and Windows 10 (and likely Windows 8). No other browsers exhibit this bug, but I may have only tested the DX11 path on Firefox.  I attached the test case to the Chromium bug earlier in this thread.  We'd really like to see this fixed, as we recommend Chrome first. 

Unrelated to WebGL, but copy-pasted images from Photoshop to Chrome via DataTransfer are always downsampled by 2x in width and height in Chrome on Retina OSX.  That is also a needed fix too.  The exclusion of clipboard images and other content from the clipboard by most browsers, and in this case modification of existing data really make interop with the native app world a challenge.  I've starred the appropriate issue on that.

If the bug ID is http://crbug.com/355477 I've pushed on it. Thanks for highlighting this.

-Ken

[Alecazam]

Thanks Ken.  I was hopeful seeing other people reporting an issue with pasting, but less hopeful after seeing that it was first reported Mar 25, 2014.  Some of these fundaments seem like they need priority over adding support for new functionality (f.e. the <picture> element).  Especially if web apps are going to truly complete with native apps, then they need to at least have access to the data needed for interop.

Some big remaining issues to web app development remain.

1.  Lack of anchor download in Safari and auto-opens blob with blob name and auto-opens exported zip files (unsuccessfully).  There's a WebKit bug indicating this might get fixed soon, but then it's another wait for the next OSX release.   Can finally override pinch-zoom gesture, but you have to be on 10.11.4.

2.  DataTransfer on Safari reports image/tiff from Photoshop, but there are no files to process.  All images seem to be stripped.  I don't know where to report this.  Why is the clipboard filtering, and why was it a DOMString from getData in the first place.  We've requested a lot of action on improving the clipboard transfer API, but the stakeholders don't seem to want to improve this.

3. DataTransfer on Firefox has no image types or files.  There's a bug with a patch about to hit that will include png/jpg/gif there.  Feels like browsers could transcode a lot more formats to help apps with interop.

So to get this back to WebGL related topics.  I've been looking over WebGL 2, and it looks really good.  I noticed a few missing pieces.  

A.  I hope that WebGL 2 can still mix large depth buffers with smaller color targets.  That avoids needed to switch out depth/stencil when you change an FBO.  There was a comment about array textures, but I'm assuming the color targets all must match size, but the depth doesn't have to.

B.  I noticed that WebGL 2 interface was missing gl.SRGB_ALPHA  which you need for format/type for the most commonly used form of SRGB

C.  Access to more shader types - TS, HS, CS

D.  Compute

E.  SSO - fundamentally changes how shaders interoperate and connect

F.   Vertex Shader clip plane access - critical for single-card VR

G.  index offset so you can use 16-bit indices

H.  Chrome is missing depth-texture.  Makes doing shadows pretty difficult.  Firefox has this.

[Kenneth Russell]

On Fri, Apr 22, 2016 at 3:27 PM, Alecazam <al...@figma.com> wrote:

Thanks Ken.  I was hopeful seeing other people reporting an issue with pasting, but less hopeful after seeing that it was first reported Mar 25, 2014.  Some of these fundaments seem like they need priority over adding support for new functionality (f.e. the <picture> element).  Especially if web apps are going to truly complete with native apps, then they need to at least have access to the data needed for interop.

Alec,

Agree 100%.

 

Some big remaining issues to web app development remain.

1.  Lack of anchor download in Safari and auto-opens blob with blob name and auto-opens exported zip files (unsuccessfully).  There's a WebKit bug indicating this might get fixed soon, but then it's another wait for the next OSX release.   Can finally override pinch-zoom gesture, but you have to be on 10.11.4.

2.  DataTransfer on Safari reports image/tiff from Photoshop, but there are no files to process.  All images seem to be stripped.  I don't know where to report this.  Why is the clipboard filtering, and why was it a DOMString from getData in the first place.  We've requested a lot of action on improving the clipboard transfer API, but the stakeholders don't seem to want to improve this.

I've highlighted your report to a colleague who works on WebKit and hopefully he'll follow up. Presumably this should also be filed on https://bugs.webkit.org/ .

 

3. DataTransfer on Firefox has no image types or files.  There's a bug with a patch about to hit that will include png/jpg/gif there.  Feels like browsers could transcode a lot more formats to help apps with interop.

I've highlighted this to a colleague who works on Firefox.

 

So to get this back to WebGL related topics.  I've been looking over WebGL 2, and it looks really good.  I noticed a few missing pieces.  

A.  I hope that WebGL 2 can still mix large depth buffers with smaller color targets.  That avoids needed to switch out depth/stencil when you change an FBO.  There was a comment about array textures, but I'm assuming the color targets all must match size, but the depth doesn't have to.

This is problematic because Direct3D does not support it. The spec was crafted to allow efficient implementation on all platforms. I think this is a relatively small things to ask applications to manage for the benefit that applications will run quickly everywhere.

 

B.  I noticed that WebGL 2 interface was missing gl.SRGB_ALPHA  which you need for format/type for the most commonly used form of SRGB

Per the ES 3.0 spec, this is specified with format RGBA, type UNSIGNED_BYTE, and internal format SRGB8_ALPHA8. Please tell us if something appears to be missing.

 

C.  Access to more shader types - TS, HS, CS

Recent investigation has indicated that there are some fundamental differences between how tessellation shaders work in OpenGL and how they work in Direct3D, so any API that's portable between the two backends is going to have to reconcile this. It does not seem tractable to simply compile OpenGL's tessellation shaders to run on Direct3D. For this reason getting compute shaders on the web is going to be the next focus.

 

D.  Compute

This is the working group's top priority after WebGL 2.0 ships. We believe it should be a relatively small delta, be portable to all the platforms WebGL is supported on, and provide the biggest bang for the buck.

 

E.  SSO - fundamentally changes how shaders interoperate and connect

TBD whether the follow-on to WebGL 2.0 should pull in all the ES 3.1 functionality or just compute.

 

F.   Vertex Shader clip plane access - critical for single-card VR

I don't know about this.

 

G.  index offset so you can use 16-bit indices

Sorry, are you referring to https://www.khronos.org/registry/gles/extensions/OES/OES_draw_elements_base_vertex.txt or something else?

 

H.  Chrome is missing depth-texture.  Makes doing shadows pretty difficult.  Firefox has this.

I'm sorry? On what platform? On my Mac laptop the following works:

> var c = document.createElement('canvas')

undefined

> var gl = c.getContext('webgl')

undefined

> gl

WebGLRenderingContext {canvas: canvas, drawingBufferWidth: 300, drawingBufferHeight: 150}

> var ext = gl.getExtension('WEBGL_depth_texture')

undefined

> ext

WebGLDepthTexture {}

[Alecazam]

I appreciate a lot that you care about WebGL and WebGL2 enough to oversee its development and consistency.  I'm pretty excited about just how prevalent WebGL1 has become (Edge, Safari has it enabled, etc).

Chrome is missing WebGL_depth_texture on my laptop.   I'm running webglreport.com on a Macbook Air 2012.  The depth texture extension is present on WebGL1, but not in the WebGL2 extension list.  These are the only WebGL2 reported extensions for this Intel HD 4000.  Firefox does reports it, but seems to not be suppressing SRGB and other built-in extensions.  Could be that too many extensions are filtered from WebGL 2 list on Chrome?

	EXT_color_buffer_float
	EXT_disjoint_timer_query
	EXT_texture_filter_anisotropic
	OES_texture_float_linear
	WEBGL_compressed_texture_s3tc
	WEBGL_debug_renderer_info
	WEBGL_debug_shaders
	WEBGL_lose_context The webkit missing anchor download.   https://bugs.webkit.org/show_bug.cgi?id=64580 Firefox not supporting images in transfer   https://bugzilla.mozilla.org/show_bug.cgi?id=891247 Firefox not supporting pinch-zoom (Safari uses gesture).  Easiest test is use Google Maps on Chrome vs. Firefox/Safari and it's really obvious.    https://bugzilla.mozilla.org/show_bug.cgi?id=1052253 As far as mixed depth/stencil, I think you're misreading the DX11 text that was referenced.  Mind that I can't validate off my DX11 engine.  The text that was referenced in the DX spec was talking about render targets which are different from depth stencil.  DX has always allowed mixed size depth/color, and I don't think that changed in DX10 or DX11.  Even many consoles could alias/reuse the depth target across multiple color targets.  This one is a big deal, since reusing depth is important.  You can even mix depth renderbuffers and depth rendertextures with color buffers and textures, though the memory layout is very different. WebGL2 is crashing our WebGL1 app when enabled in Chrome.  I'm a little concerned about users turning on the flag.  Firefox doesn't break WebGL1 apps.  I had an error about a float parameter before, but now it's this.	[.CommandBufferContext.Offscreen-MainThread-0x7fa22ae20300]GL ERROR :GL_INVALID_ENUM : glTexImage2D: <- error from previous GL command	2Untitled:1 [.CommandBufferContext.Offscreen-MainThread-0x7fa22ae20300]GL ERROR :GL_INVALID_ENUM : glTexImage2D:

[Alecazam]

Render targets are not the same as DepthStencil targets.  They're the "color/data" target.  You've always had to have the same dimensions for color, although later hardware relaxed the limitation where all MRT had to be the same bit depth or full RGBA32F targets.   It should be easy to validate this assumption with a call to the DX creation calls, because I trust that it is not true.  It wasn't for DX9, and doesn't hold for OpenGL.  Shanon Woods or someone on the ANGLE DX11 team could verify it.

This was the text that was quoted for this limitation.

 

https://msdn.microsoft.com/en-us/library/windows/desktop/bb205074(v=vs.85).aspx 

Render targets must all be the same type of resource. If multisample antialiasing is used, all bound render targets and depth buffers must have the same sample counts.

When a buffer is used as a render target, depth-stencil testing and multiple render targets are not supported.

• As many as 8 render targets can be bound simultaneously.
• All render targets must have the same size in all dimensions (width and height, and depth for 3D or array size for *Array types).
• Each render target may have a different data format.
• Write masks control what data gets written to a render target. The output write masks control on a per-render target, per-component level what data gets written to the render target(s).

 

[Alecazam]

There's also this text, but this is talking about views not the actual texture sizes.  You can have several views off a given texture I believe.

https://msdn.microsoft.com/en-us/library/windows/desktop/ff476464(v=vs.85).aspx

If the render-target views were created from an array resource type, all of the render-target views must have the same array size. This restriction also applies to the depth-stencil view, its array size must match that of the render-target views being bound.

[Alecazam]

B.  I noticed that WebGL 2 interface was missing gl.SRGB_ALPHA  which you need for format/type for the most commonly used form of SRGB

> Per the ES 3.0 spec, this is specified with format RGBA, type UNSIGNED_BYTE, and internal format SRGB8_ALPHA8. Please tell us if something appears to be missing.

Good to know.  These three values have been abused in so many ways by GL, GLES1/2/3.  I thought SRGB8_ALPHA8 was the sized format.  I've also never understood why glTextStorage2D doesn't work for compressed format, since that mostly what you're allocating.  Also the fact that glTexStorage is size immutable means you still need glTexImage2D for render targets that resize.

 

G.  index offset so you can use 16-bit indices

> Sorry, are you referring to https://www.khronos.org/registry/gles/extensions/OES/OES_draw_elements_base_vertex.txt or something else?

Yes, that's the extension needed.  Then you're not have to muck with the vertex bindings to offset the indices.   I'm sure that has interesting challenges for WebGL index validation.

[Alecazam]

And... it appears Edge is ignoring "filename" on anchor download.   So you get blob guid name as the download.  Compared to these rough areas of the browser interop, WebGL is and has been very solid.  The only issue with Chrome WebGL has been the stencil problem I reported, but the Chrome speed and feature set is pretty close to ideal for our web app.

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/6594876/

[Mark Callow]

On Apr 23, 2016, at 11:45 AM, Kenneth Russell <k...@chromium.org> wrote:

C.  Access to more shader types - TS, HS, CS

Recent investigation has indicated that there are some fundamental differences between how tessellation shaders work in OpenGL and how they work in Direct3D, so any API that's portable between the two backends is going to have to reconcile this. It does not seem tractable to simply compile OpenGL's tessellation shaders to run on Direct3D. For this reason getting compute shaders on the web is going to be the next focus.

Will we really still need to worry about running on D3D at this level? Tessellation shaders were not introduced until OpenGL 4.0. In my experience, admittedly limited to only a few laptops, Intel has been providing good OpenGL drivers for their recent generations of integrated GPUs that are capable of supporting this level of OpenGL. I even see driver updates coming through Windows Update. And of course AMD and NVIDIA drivers have similar drivers which I think are also updated via Windows Update.

Regards

    -Mark

P.S. What is HS, a typo for GS?

[Mark Callow]

On Apr 23, 2016, at 1:00 PM, Alecazam <al...@figma.com> wrote:

I thought SRGB8_ALPHA8 was the sized format.

It is. Unsized internal formats are deprecated in both OpenGL and OpenGL ES. ES 3.0+ retains those that were in ES 2 for backwards compatibility.

Regards

    -Mark

[Alecazam]

> P.S. What is HS, a typo for GS?

I meant Hull and Tesselation Shaders, but there's Hull and Control Shaders.  I still remember the old ATI npatch shaders, and didn't the Sega only draw patches.  I'm old school DX so I still refer to Pixel Shaders instead of the more correct Fragment Shaders.

Thanks for the comment about the unsized internal format deprecation.  I've been using unsized in GL 3.3 core without issue, so that threw me off on SRGB.   

[Alecazam]

While I'm on the topic of web app hurdles.  One other issue I should raise is the inability to override alt+click on ChromeOS.  This is a major issue facing all web apps on that platform.  There are only so many modifiers, and there are existing conventions for alt usage (f.e. duplicate, measurement, etc).  This prevents consistent keyboard/mouse workflow on that platform.

https://productforums.google.com/forum/#!msg/chromebook-central/s6dDS-PNXI4/-Cr0u6kc4DYJ 

[Kenneth Russell]

On Fri, Apr 22, 2016 at 8:32 PM, Alecazam <al...@figma.com> wrote:

I appreciate a lot that you care about WebGL and WebGL2 enough to oversee its development and consistency.  I'm pretty excited about just how prevalent WebGL1 has become (Edge, Safari has it enabled, etc).

Chrome is missing WebGL_depth_texture on my laptop.   I'm running webglreport.com on a Macbook Air 2012.  The depth texture extension is present on WebGL1, but not in the WebGL2 extension list.  These are the only WebGL2 reported extensions for this Intel HD 4000.  Firefox does reports it, but seems to not be suppressing SRGB and other built-in extensions.  Could be that too many extensions are filtered from WebGL 2 list on Chrome?

I'd need to see about:gpu from your laptop to understand whether there's a blacklist entry preventing WEBGL_depth_texture from being exposed.

 

	EXT_color_buffer_float
	EXT_disjoint_timer_query
	EXT_texture_filter_anisotropic
	OES_texture_float_linear
	WEBGL_compressed_texture_s3tc
	WEBGL_debug_renderer_info
	WEBGL_debug_shaders
	WEBGL_lose_context The webkit missing anchor download.   https://bugs.webkit.org/show_bug.cgi?id=64580 Firefox not supporting images in transfer   https://bugzilla.mozilla.org/show_bug.cgi?id=891247 Firefox not supporting pinch-zoom (Safari uses gesture).  Easiest test is use Google Maps on Chrome vs. Firefox/Safari and it's really obvious.    https://bugzilla.mozilla.org/show_bug.cgi?id=1052253 As far as mixed depth/stencil, I think you're misreading the DX11 text that was referenced.  Mind that I can't validate off my DX11 engine.  The text that was referenced in the DX spec was talking about render targets which are different from depth stencil.  DX has always allowed mixed size depth/color, and I don't think that changed in DX10 or DX11.  Even many consoles could alias/reuse the depth target across multiple color targets.  This one is a big deal, since reusing depth is important.  You can even mix depth renderbuffers and depth rendertextures with color buffers and textures, though the memory layout is very different.

If this is a misunderstanding on the behalf of the WebGL working group then we'd like to lift this restriction. It would be helpful if you could help definitively prove this, since the restriction was informed by engineers from Microsoft who know the Direct3D API well.

 

WebGL2 is crashing our WebGL1 app when enabled in Chrome.  I'm a little concerned about users turning on the flag.  Firefox doesn't break WebGL1 apps.  I had an error about a float parameter before, but now it's this.

Apologies. Chrome isn't passing all of the WebGL 1.0 conformance tests on Mac OS X yet when --enable-unsafe-es3-apis is passed. We're working on them. Please file a bug with a reduced test case and email me the bug ID if you can isolate it.

-Ken

 

[.CommandBufferContext.Offscreen-MainThread-0x7fa22ae20300]GL ERROR :GL_INVALID_ENUM : glTexImage2D: <- error from previous GL command

2Untitled:1 [.CommandBufferContext.Offscreen-MainThread-0x7fa22ae20300]GL ERROR :GL_INVALID_ENUM : glTexImage2D:

[Kenneth Russell]

On Mon, May 2, 2016 at 2:24 PM, Kenneth Russell <k...@chromium.org> wrote:

On Fri, Apr 22, 2016 at 8:32 PM, Alecazam <al...@figma.com> wrote:

I appreciate a lot that you care about WebGL and WebGL2 enough to oversee its development and consistency.  I'm pretty excited about just how prevalent WebGL1 has become (Edge, Safari has it enabled, etc).

Chrome is missing WebGL_depth_texture on my laptop.   I'm running webglreport.com on a Macbook Air 2012.  The depth texture extension is present on WebGL1, but not in the WebGL2 extension list.  These are the only WebGL2 reported extensions for this Intel HD 4000.  Firefox does reports it, but seems to not be suppressing SRGB and other built-in extensions.  Could be that too many extensions are filtered from WebGL 2 list on Chrome?

I'd need to see about:gpu from your laptop to understand whether there's a blacklist entry preventing WEBGL_depth_texture from being exposed.

 

	EXT_color_buffer_float
	EXT_disjoint_timer_query
	EXT_texture_filter_anisotropic
	OES_texture_float_linear
	WEBGL_compressed_texture_s3tc
	WEBGL_debug_renderer_info
	WEBGL_debug_shaders
	WEBGL_lose_context The webkit missing anchor download.   https://bugs.webkit.org/show_bug.cgi?id=64580 Firefox not supporting images in transfer   https://bugzilla.mozilla.org/show_bug.cgi?id=891247 Firefox not supporting pinch-zoom (Safari uses gesture).  Easiest test is use Google Maps on Chrome vs. Firefox/Safari and it's really obvious.    https://bugzilla.mozilla.org/show_bug.cgi?id=1052253 As far as mixed depth/stencil, I think you're misreading the DX11 text that was referenced.  Mind that I can't validate off my DX11 engine.  The text that was referenced in the DX spec was talking about render targets which are different from depth stencil.  DX has always allowed mixed size depth/color, and I don't think that changed in DX10 or DX11.  Even many consoles could alias/reuse the depth target across multiple color targets.  This one is a big deal, since reusing depth is important.  You can even mix depth renderbuffers and depth rendertextures with color buffers and textures, though the memory layout is very different.

If this is a misunderstanding on the behalf of the WebGL working group then we'd like to lift this restriction. It would be helpful if you could help definitively prove this, since the restriction was informed by engineers from Microsoft who know the Direct3D API well.

Alec, an engineer from Microsoft highlighted the spec text introducing these restrictions and wrote a test case demonstrating that the restrictions as written are needed. I can't simply copy-paste the email but the restrictions need to stand in the WebGL 2.0 spec to keep it portable.

-Ken

[Alecazam]

> I'd need to see about:gpu from your laptop to understand whether there's a blacklist entry preventing WEBGL_depth_texture from being exposed.

Sent that off.  Hope the case is helpful.  

Alec, an engineer from Microsoft highlighted the spec text introducing these restrictions and wrote a test case demonstrating that the restrictions as written are needed. I can't simply copy-paste the email but the restrictions need to stand in the WebGL 2.0 spec to keep it portable.

If Microsoft says it can't be done, then it can't be done.  My understanding was that you had a buffer, and multiple views on it.  My last DX11 engine only stored a single view with each buffer, but it seemed possible to create multiple buffers.  Always strange how abstract OpenGL gets away with being so flexible but DX doesn't, but DX tends to be a little better on performance.  It's not super hard to workaround.

Other WebGL1/2 oddities.  I know these are also in ES2/ES3.  Seems odd that glTexStorage2D can't handle compressed formats, and glCompressedTexImage2D requires a dummy set of mips to create one level.  You can't resize texStorage2D, so one cannot use it for render targets or depth easily.  Good old glTexImage2D takes null and does all that behind the scenes, but then you still have to retain the old code paths for it and handle all of the crazy mips for cubes/2D/3D/array textures.  

 

[Kenneth Russell]

On Wed, May 4, 2016 at 2:11 PM, Alecazam <al...@figma.com> wrote:

> I'd need to see about:gpu from your laptop to understand whether there's a blacklist entry preventing WEBGL_depth_texture from being exposed.

Sent that off.  Hope the case is helpful.  

Alec, an engineer from Microsoft highlighted the spec text introducing these restrictions and wrote a test case demonstrating that the restrictions as written are needed. I can't simply copy-paste the email but the restrictions need to stand in the WebGL 2.0 spec to keep it portable.

If Microsoft says it can't be done, then it can't be done.  My understanding was that you had a buffer, and multiple views on it.  My last DX11 engine only stored a single view with each buffer, but it seemed possible to create multiple buffers.  Always strange how abstract OpenGL gets away with being so flexible but DX doesn't, but DX tends to be a little better on performance.  It's not super hard to workaround.

Other WebGL1/2 oddities.  I know these are also in ES2/ES3.  Seems odd that glTexStorage2D can't handle compressed formats

It can. Chrome's WebGL 2.0 implementation was busted. I just fixed this in http://crbug.com/605129 and the fix is present in 52.0.2724.0 (Official Build) canary (64-bit) (on Mac; different version number on Windows). If there are more bugs **please** file them with test cases.

 

, and glCompressedTexImage2D requires a dummy set of mips to create one level.

Sorry, what? It should be possible to allocate exactly one level and set NEAREST or LINEAR filtering. Again, if not, *please* file a bug with a test case.

 

  You can't resize texStorage2D, so one cannot use it for render targets or depth easily.  Good old glTexImage2D takes null and does all that behind the scenes, but then you still have to retain the old code paths for it and handle all of the crazy mips for cubes/2D/3D/array textures.  

I don't understand these comments. TexStorage2D can easily be used to allocate a render target; just allocate a single level. It should be preferred in WebGL 2.0 code.

-Ken

[Jeff Dash]

TexStorage works with any compressed format that supports CompressedTexSubImage updates.

IIRC there was one format that forbid all CompressedTexSubImage updates, so TexStorage is inviable there. It should work in general.

Also the common hint to use TexImage without mip allocation is to set a texture's filtering to non-mipmap filters before calling TexImage. It's not guaranteed to work the way TexStorage is, but IIRC some drivers take this as a hint.

It looks to me like D3D can allow multiple views, but that the views don't allow specifying subsets of a Texture's data. Buffers support subviews, but I don't think those can replace Textures.

[Alecazam]

I think I tried DXT1/3/5, and that failed.

> It looks to me like D3D can allow multiple views, but that the views don't allow specifying subsets of a Texture's data. Buffers support subviews, but I don't think those can replace Textures.

That seems to be the case.  The RenderTargetView has a dimension field, but it's just the format of the buffer (1D, 2D, etc).  That's too bad.  There are Nvidia driver extensions to overlay target memory for MSAA and regular render textures in DX.   Most of the games I did re-used the main depth target for everything in DX9, but the drivers may have been allocating unique texture behind the scenes.   Maybe DX12 will enable this again, but I haven't looked.

[Jeff Dash]

S3TC supports TexStorage, so if it's busted it's an implementation issue. Please file a bug!

[Kenneth Russell]

Note: the conformance/extensions/webgl-compressed-texture-s3tc.html test has already been expanded to cover allocation of the texture via TexStorage2D. Run with:

https://www.khronos.org/registry/webgl/sdk/tests/conformance/extensions/webgl-compressed-texture-s3tc.html?webglVersion=2&quiet=0

to get it to run with the WebGL 2.0 context and verify the new code path.

[Alecazam]

Opera, Firefox, and Chrome exhibit the Angle DX9 stencil bug. Chrome Canary has been verified as fixed by one of our users.

[Alecazam]

Just reading your comments here.

gl.compressedTexImage2D whether you allocate mips or not requires a dummy allocated buffer to be passed on each mip level allocated.  You can pass null to gl.texImage2D, but not to this call.  I seem to recall the same issue in es2, but it's still makes it harder for people to pre-allocate the DXT/PVRTC textures, and then upload to them later.   Seems like WebGL could just assign an internal 0 sized buffer, so the caller doesn't have to.

gl.texStorage2D works for creating a render target, but then you can't resize it because of the immutability.  So then you're back to texStorage2D if the target/depth are backing something like the window.

I was able to create depth textures in WebGL2.  The issue was the format changes, and the removal of the extension on Chrome (but not on Firefox).  Would be good to list the depth combos on the WebGL 2 page - there are color format/type/internalFormats listed for everything else.

[Kenneth Russell]

On Wed, May 11, 2016 at 8:52 AM, Alecazam <al...@figma.com> wrote:

Just reading your comments here.

gl.compressedTexImage2D whether you allocate mips or not requires a dummy allocated buffer to be passed on each mip level allocated.  You can pass null to gl.texImage2D, but not to this call.  I seem to recall the same issue in es2, but it's still makes it harder for people to pre-allocate the DXT/PVRTC textures, and then upload to them later.   Seems like WebGL could just assign an internal 0 sized buffer, so the caller doesn't have to.

Understood, and sorry about that. There was some concern that it might be difficult to construct valid "empty" data for each of the compressed texture formats. In other words, just passing a zeroed-out buffer might not result in valid compressed texture data for some of them. This is less of a concern right now. We ended up having to do this internally in the browser to handle TexStorage2D, anyway, since it wouldn't be OK to have garbage data in the mipmap levels.

We could consider relaxing this requirement. public_webgl at khronos.org would be a better place to discuss it.

 

gl.texStorage2D works for creating a render target, but then you can't resize it because of the immutability.  So then you're back to texStorage2D if the target/depth are backing something like the window.

Right, understood. You could delete and reallocate, which the driver's probably doing internally anyway. (But you're probably not using it with compressed textures if it's a render target.)

 

I was able to create depth textures in WebGL2.  The issue was the format changes, and the removal of the extension on Chrome (but not on Firefox).

The extension will be removed from Firefox. A conformance test was just added which enforces that all WebGL 1.0 extensions promoted into core are not exposed in WebGL 2.0 contexts.

 

  Would be good to list the depth combos on the WebGL 2 page - there are color format/type/internalFormats listed for everything else.

Which tables would you like to see expanded? The ones for texImage2D in https://www.khronos.org/registry/webgl/specs/latest/2.0/#3.7.6 ?

Thanks,

-Ken

[Alecazam]

> We could consider relaxing this requirement. public_webgl at khronos.org would be a better place to discuss it.

I think that would help people emulate glTexStorage with WebGL 1.  You just allocate all of the bitmamps and then you upload to them later just like texStorage.  The only issue is that I'm not sure how that fits with immutable content flag in DX11 though. I thought you had to upload the data as they're allocated, which is different than texStorage's size immutability.  That seems like the one drawaback to texStorage is that you have no way to pass the content at creation, but maybe the drivers never optimized for that anyhow.

> Right, understood. You could delete and reallocate, which the driver's probably doing internally anyway. (But you're probably not using it with compressed textures if it's a render target.)

Yes, that would be one approach.  Not sure if that invalidates handles to those textures that you might be referencing in shaders, but that was one advantage of resizing with gl.texImage2D.

> Which tables would you like to see expanded? The ones for texImage2D in https://www.khronos.org/registry/webgl/specs/latest/2.0/#3.7.6 ?

I think it would be good to list all of the new depth formats there.  Also DXT/PVRTC/ETC extensions could go there too.  I know it's redundant with the spec, but it's useful for just being able to reference in one place.  

One thing I wanted to try to implement was GPU DXT compression, but I'm assuming WebGL2 can't copy between a RGBA32UI texture with the bits, and a DXT1/DXT5 texture.   Compressed textures really suffered due to mobile and DXT lawsuits.  I think there's still not only a few PVRTC encoders in the wild.   Hoping the new formats are better received, but there was a lot of great tech put into DXT normal maps.