WebGL and MSAA

[Alecazam]

There's no easy way that I see in WebGL 1.0 to emulate MSAA offscreen renderbuffers or textures.  These are supported on iOS and on desktop platforms that drive WebGL underneath.  This coupled with the artificial 4K texture limit on textures in Firefox also makes supersampling much more difficult (requiring tiled renders of 2K or less on a system with 16K textures).  I'm all for WebGL 2.0, but I hope these limitation in 1.0 are addressed with extensions and browswer updates.

[Jeff Dash]

Any artificial limit on texture size in Firefox is there for a reason, generally security related, and cannot generally be safely lifted. We don't strictly limit to 4k without reason. We can only lift these restrictions if we can confirm that newer drivers have repaired the issues.

WebGL 2 supports msaa directly, though.

On Mar 22, 2014 2:57 PM, "Alecazam" <al...@figma.com> wrote:

There's no easy way that I see in WebGL 1.0 to emulate MSAA offscreen renderbuffers or textures.  These are supported on iOS and on desktop platforms that drive WebGL underneath.  This coupled with the artificial 4K texture limit on textures in Firefox also makes supersampling much more difficult (requiring tiled renders of 2K or less on a system with 16K textures).  I'm all for WebGL 2.0, but I hope these limitation in 1.0 are addressed with extensions and browswer updates.

--
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.

[Alecazam]

Thanks for the info.  I still see an issue here, considering this is a brand new and capable video card, but it is hobbled by this artificial limit.  Chrome doesn't have the same limit, and must have the same security considerations.  If the limit is an issue, then shouldn't cube maps (which have 6x the memory) also be limited to 4K?   

See my other post about the issues of offscreen MSAA and WebGL 1.  I'm very interested in seeing a working WebGL 2 spec that isn't just WebGL 1 + existing extensions.   ES2/WebGL2 also has texture arrays and other memory hungry allocations.

[Jeff Dash]

It's possible that the issue we were having in the past has been confirmed fixed by the Chrome guys, but that we haven't retested this for Firefox. Can you file a bug for this?

We have a WebGL 2 draft spec, I believe, which you can look over. It's basically ES3, with a few exceptions.

-Jeff

[Alecazam]

I reported it here.  https://bugzilla.mozilla.org/show_bug.cgi?id=986871

I've already seen the WebGL 2 spec, but the initial impl at the time was basically basically just WebGL 1.0 with MRT and SRGB as I recall.  ES3 has a number of new calls and texture formats.  WebGL 1.0 would be enough for most if it would just expose more texture formats of the native GL/DX/ES impl.  The new calls of WebGL 2.0 are nice, but not essential.

[Alecazam]

I should clarify on that last statement, that the MSAA calls (textures) and texture arrays and formal instancing are really needed in WebGL 2/ES3.  I'm surprised that compute/hull/geometry shaders are left out, but maybe those will also appear as extensions.   I just feel like WebGL 1.0 with extensions actually implemented (SRGB, MRT, uint index, etc) can go pretty far on it's own to satisfying most developer needs.  WebGL adopting ancient mobile limits imposed by ES when running on a desktop platform seems like a disservice to the underlying hardware and to the API.

 

[Zhenyao Mo]

Honestly I am a little bit nervous that twice this week we heard
people mentioning Firefix has this texture max size virtual limit and
chrome doesn't. To the best of my knowledge, chrome should have too.

Can you provide the about:gpu page from the machine that chrome has no
limit and Firefox does? It might be a bug on our side.

Mo

[Alecazam]

Firefox 28.0

User Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0

Device ID            0x fe9

GPU Accelerated Windows 1/1 OpenGL (OMTC)

Vendor ID 0x10de

WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce GT 750M OpenGL Engine

windowLayerManagerRemote true

AzureCanvasBackend quartz

AzureContentBackend quartz

AzureFallbackCanvasBackend none

AzureSkiaAccelerated 0

tex2DSizeMax = 4096

texCubeSizeMax = 16384   <- what it should be for all texture types

tex2DRenderBufferSizeMax = 4096

-----------------------

Chome seems fine:

Chrome 33.0

tex2DSizeMax = 16384 

texCubeSizeMax = 16384 

tex2DRenderBufferSizeMax = 16384

Version Information

Data exported	3/27/2014 4:29:18 PM
Chrome version	Chrome/33.0.1750.152
Operating system	Mac OS X 10.9.2
Software rendering list version	6.21
Driver bug list version	3.10
ANGLE revision	2451
2D graphics backend	Skia
Command Line Args	Chrome.app/Contents/MacOS/Google Chrome --flag-switches-begin --enable-devtools-experiments --flag-switches-end

Driver Information

Initialization time	13
Sandboxed	false
GPU0	VENDOR = 0x10de, DEVICE= 0x0fe9
GPU1	VENDOR = 0x8086, DEVICE= 0x0d26
Optimus	true
AMD switchable	false
Driver vendor
Driver version	8.24.9 310.40.25f01
Driver date
Pixel shader version	1.20
Vertex shader version	1.20
Machine model	MacBookPro 11.3
GL version	2.1
GL_VENDOR	NVIDIA Corporation
GL_RENDERER	NVIDIA GeForce GT 750M OpenGL Engine
GL_VERSION	2.1 NVIDIA-8.24.9 310.40.25f01

[Zhenyao Mo]

OK, so chrome's behavior is as expected. We only need to limit tex max size on AMD and Intel GPUs.  What you have here is dual GPUs, and in Chrome WebGL only runs on discrete GPU, which is NVIDIA, no need to limit the tex max size.

Thanks for the information.

[Alecazam]

That's what I surmised in the bug report, but glad that you identified it for sure.  This would be an issue for the 2010/12/13 MacBook Pros.  It would be good to avoid the tex limit on Intel given it's prevalence on the Mac air and newer Pros (given that whatever security/texture corruption issue is fixed).