986871 - WebGL GL_MAX_TEXTURE_SIZE <= 4096 on Mac (Win?) card supports 16K

Status: RESOLVED WORKSFORME

(Core :: Graphics: CanvasWebGL, defect)

Description

[Alecazam]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.146 Safari/537.36

Steps to reproduce:

On a new PowerMac Pro with the latest video card (NVIDIA GeForce GT 750M 2048 MB), Firefox is still limiting the 2D texture size (for rendering and texturing) to 4K pixels on a side, even though the actual limit is 16K.   However, Firefox sends back 16K for the cube map limit, which is a lot more memory than the 2D limit.  

These limits should either be the same (4K), but I'd prefer to see the limits go to what the hardware is capable of handling.  Chrome passes through the 16K limit on everything.  Firefox is limiting supersampling and displaying large imagery on Retina-capable machines and use of high-def and multi-headed output with this 4K limit, and that requires more complex tiled rendering and texture sampling.


WebGL 1.0.

GL_MAX_RENDERBUFFER_SIZE        = 4k
GL_MAX_TEXTURE_SIZE                 = 4k
GL_MAX_CUBE_MAP_TEXTURE_SIZE = 16k


https://bug737182.bugzilla.mozilla.org/attachment.cgi?id=609343


Actual results:

See above.


Expected results:

WebGL needs to stop filtering caps from the HW, and provide many more texture formats and extensions.  Every browser is reporting different caps (texture sizes, different line/point size caps) and this makes apps have to fallback to the lowest common denominator which native apps don't have to.  This prevents WebGL apps from competing with native GL usage on desktop and mobile.

Comment 1

[Alecazam]

I wonder if this is related to machines like the Mac laptops that have an Intel GPU and Nvidia GPU.  It looked like the link below had added 4K limits for Intel hardware to work around texture corruption.

https://bug737182.bugzilla.mozilla.org/attachment.cgi?id=609343

It may be worth looking at the Firefox GPU identification, and making sure that it's properly detecting the GPU in use.

Comment 2

[Alecazam]

It looks like clamping is coming from the following source from Firefox Nightly in GLContext.cpp.  OSX textures/renderbuffers/cubes are all getting clamped to some odd sizes.  I don't see any OS version check on Intel, and OSX >= 10.8 is limited to 8191 on Nvidia or 4096 for prior OS versions.  The latter might as well be 4096, since it's not a power of 2.  It would be nice to lift where/when possible.   Note that a 16K x 16K x 4 bpp image is almost 1GB of VRAM, but you could still have long tables that were 16K x 16 pixels on capable hardware.


/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/* vim: set ts=8 sts=4 et sw=4 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

#ifdef XP_MACOSX
        if (mWorkAroundDriverBugs) {
            if (mVendor == GLVendor::Intel) {
                // see bug 737182 for 2D textures, bug 684882 for cube map textures.
                mMaxTextureSize        = std::min(mMaxTextureSize,        4096);
                mMaxCubeMapTextureSize = std::min(mMaxCubeMapTextureSize, 512);
                // for good measure, we align renderbuffers on what we do for 2D textures
                mMaxRenderbufferSize   = std::min(mMaxRenderbufferSize,   4096);
                mNeedsTextureSizeChecks = true;
            } else if (mVendor == GLVendor::NVIDIA) {
                if (nsCocoaFeatures::OnMountainLionOrLater()) {
                    // See bug 879656.  8192 fails, 8191 works.
                    mMaxTextureSize = std::min(mMaxTextureSize, 8191);
                    mMaxRenderbufferSize = std::min(mMaxRenderbufferSize, 8191);
                }
                else {
                    // See bug 877949.
                    mMaxTextureSize = std::min(mMaxTextureSize, 4096);
                    mMaxRenderbufferSize = std::min(mMaxRenderbufferSize, 4096);
                }

                // Part of the bug 879656, but it also doesn't hurt the 877949
                mNeedsTextureSizeChecks = true;
            }
        }
#endif

Comment 3

[drewjpotter]

I can confirm this bug which affects Firefox on OS X. The following WebGL demo does not load properly:

https://www.blend4web.com/apps/webplayer/webplayer.html?load=../../assets/interactivity/solar_system/solar_system_en.json&v=20150326165850

The problem is the background texture does not load.

I am using Firefox version: 36.0.4
I am using OS X version: 10.10.2

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

Agreed, this is a pain, but bug 879656 is a security bug that shows up when we allow textures 8192 or higher (https://bugzilla.mozilla.org/show_bug.cgi?id=879656#c19), and we can't have those.

For the demo from comment 3, can you screengrab the result you get?

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: 30 Mar 2015 nightly, OS X 10.9.5

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to drewjpotter from comment #3)
> I can confirm this bug which affects Firefox on OS X. The following WebGL
> demo does not load properly:
> 
> https://www.blend4web.com/apps/webplayer/webplayer.html?load=../../assets/
> interactivity/solar_system/solar_system_en.json&v=20150326165850
> 
> The problem is the background texture does not load.
> 
> I am using Firefox version: 36.0.4
> I am using OS X version: 10.10.2

Could you check on the latest nightly release?  I attached my result, I think I get the background, but I'm not sure what we're looking for, but I'm on version 40, and OS X 10.9.5 so there is enough of a difference.

Comment 7

[drewjpotter]

Attachment: solar_system.png WebGL demo which does not run correctly, missing the galaxy background texture.

Here is the screenshot of the Nightly Firefox not rendering the background galaxy properly.

Comment 8

[drewjpotter]

(In reply to Milan Sreckovic [:milan] from comment #6)
> (In reply to drewjpotter from comment #3)
> > I can confirm this bug which affects Firefox on OS X. The following WebGL
> > demo does not load properly:
> > 
> > https://www.blend4web.com/apps/webplayer/webplayer.html?load=../../assets/
> > interactivity/solar_system/solar_system_en.json&v=20150326165850
> > 
> > The problem is the background texture does not load.
> > 
> > I am using Firefox version: 36.0.4
> > I am using OS X version: 10.10.2
> 
> Could you check on the latest nightly release?  I attached my result, I
> think I get the background, but I'm not sure what we're looking for, but I'm
> on version 40, and OS X 10.9.5 so there is enough of a difference.

I have attached an image showing the problem running in the latest nightly. Is it only Intel graphics on OS X  which fails to run it properly?

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

What's the content of the graphics section from about:support?

Comment 10

[drewjpotter]

about:support

Graphics
Asynchronous Pan/Zoom	none
Device ID	0x a2e
GPU Accelerated Windows	1/1 OpenGL (OMTC)
Vendor ID	0x8086
WebGL Renderer	Intel Inc. -- Intel Iris OpenGL Engine
windowLayerManagerRemote	true
AzureCanvasBackend	quartz
AzureContentBackend	quartz
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

Comment 11

[drewjpotter]

By the way... it runs fine in Safari so it is just Firefox which has this issue.

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to drewjpotter from comment #8)
> 
> I have attached an image showing the problem running in the latest nightly.
> Is it only Intel graphics on OS X  which fails to run it properly?

Yes, I would say so.  Probably worth a separate bug, because your issue stems from the 512 limit on the cube maps for Intel, while this bug was focusing on the limits on other textures on Nvidia.  If you do create another bug, please CC me on it.

Comment 13

[drewjpotter]

(In reply to Milan Sreckovic [:milan] from comment #12)
> (In reply to drewjpotter from comment #8)
> > 
> > I have attached an image showing the problem running in the latest nightly.
> > Is it only Intel graphics on OS X  which fails to run it properly?
> 
> Yes, I would say so.  Probably worth a separate bug, because your issue
> stems from the 512 limit on the cube maps for Intel, while this bug was
> focusing on the limits on other textures on Nvidia.  If you do create
> another bug, please CC me on it.

I don't know how to CC you in but here is the link to the bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1149808

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

Is this still a problem?  It works for me.

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

Just to be clear - we still have hardcoded limits on the texture sizes.  For Nvidia, for example, on later OS X versions, we still limit to 8191 due to bug 879656 (unless gfx.work-around-graphics-bugs is set to false.)

Comment 16

[marcot]

on my MBP with Nvidia and Firefox 50, GL_MAX_TEXTURE_SIZE is still 4k.