896287 - [Linux] nvidia driver 325.08 and above w/ layers acceleration fails with "ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes)"

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[John Schoenick [:johns]]

After updating to the 325.08 driver, we fail on startup with this error whenever layers acceleration is enabled

> ###!!! ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes); 6 requests ago: file /mnt/N/moz/moz-git-build-refox/toolkit/xre/nsX11ErrorHandler.cpp, line 157
> ###!!! ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes); 6 requests ago: file /mnt/N/moz/moz-git-build-refox/toolkit/xre/nsX11ErrorHandler.cpp, line 157
> 
> Program received signal SIGSEGV, Segmentation fault.
> mozalloc_abort (msg=<optimized out>) at /mnt/N/moz/moz-git-build-refox/memory/mozalloc/mozalloc_abort.cpp:30
> 30          MOZ_CRASH();

It's likely that this is due to this change in the 325.08 notes[1]

> Generate a BadMatch error when applications attempt to create GLX pixmaps using 
> glXCreatePixmap() or glXCreateGLXPixmapWithConfigSGIX() and the pixmap's depth doesn't 
> match that of the specified GLXFBConfig.

[1] https://devtalk.nvidia.com/default/topic/549155/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-325-08-beta-/

Comment 1

[Chris Dalton]

I've found that we only get BadMatch for 32-bit RGBA surfaces.

In GLContextGLX::CreateTextureImage if I force it to always use 'imageFormat = gfxASurface::ImageFormatRGB24', I don't get a BadMatch anymore.

Comment 2

[Karl Tomlinson (:karlt)]

(In reply to John Schoenick [:johns] from comment #0)
> It's likely that this is due to this change in the 325.08 notes[1]
> 
> > Generate a BadMatch error when applications attempt to create GLX pixmaps using 
> > glXCreatePixmap() or glXCreateGLXPixmapWithConfigSGIX() and the pixmap's depth doesn't 
> > match that of the specified GLXFBConfig.
> 
> [1]
> https://devtalk.nvidia.com/default/topic/549155/unix-graphics-announcements-
> and-news/linux-solaris-and-freebsd-driver-325-08-beta-/

Yes.  That's unfortunate because fbConfigs don't really have depths - they have a buffer_size.  From "GLXPixmaps are supported for visuals whose GLX_BUFFER_SIZE
is one of the pixmap depths supported by the X server" [2], the pixmap depths would be expected to match the buffer_size, but NVIDIA drivers do not provide any buffer_size = 24 fbconfigs for use with pixmaps without alpha bits (bug 779786 comment 3).

Visuals have a depth, but visuals don't usually include alpha bits in the depth.
Only the visual(s) from the Composite extension includes the alpha bits in the depth.

[2] http://www.opengl.org/sdk/docs/man2/xhtml/glXChooseVisual.xml

Perhaps this change won't propagate from beta to release versions?

Comment 3

[Dmitry]

I have same issue on Gentoo. Error messages:

> ###!!! ABORT: X_GLXDestroyPixmap: GLXBadPixmap; 4 requests ago: file /home/tmp/portage/www-client/firefox-22.0/work/mozilla-release/toolkit/xre/nsX11ErrorHandler.cpp, line 157
> ###!!! ABORT: X_GLXDestroyPixmap: GLXBadPixmap; 4 requests ago: file /home/tmp/portage/www-client/firefox-22.0/work/mozilla-release/toolkit/xre/nsX11ErrorHandler.cpp, line 157

or

> ###!!! ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes); 57 requests ago: file /home/tmp/portage/www-client/firefox-22.0/work/mozilla-release/toolkit/xre/nsX11ErrorHandler.cpp, line 157
> ###!!! ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes); 57 requests ago: file /home/tmp/portage/www-client/firefox-22.0/work/mozilla-release/toolkit/xre/nsX11ErrorHandler.cpp, line 157

Comment 4

[Joseph Yasi]

The change has propagated to the release version. The 325.15 driver was just released and has the same issue.

Comment 5

[fabrixx2]

I've upgraded to nvidia 325.15 and have this issue on Firefox 24a2 64bit (Linux Debian testing)

To run firefox again i re-edited prefs.js

Comment 6

[Karl Tomlinson (:karlt)]

Is someone able to run the modified glxinfo in bug 779786 comment 2, please, and attach the output here?

Comment 7

[John Schoenick [:johns]]

Attachment: Output from karlt's modified glxinfo - nvidia 325.08

This is from the 325.08 beta driver, I can update this with the 325.15 output later today

Comment 8

[Joseph Yasi]

Attachment: Output from karlt's modified glxinfo - nvidia 325.15

Here is the output against 325.15.

Comment 9

[Joseph Yasi]

Attachment: firefox-glxcreatepixmap-gdb-crash.txt

I did some debugging with gdb, and the crash is happening with the pixmap format->depth != depth for the visual. It happens for format->depth = 32 and depth = 24 in GLXLibrary::CreatePixmap(gfxASurface*). It looks like this check: if (depth != format->depth && depth != format->depth - alphaSize) doesn't work anymore with nvidia. I'm going to try dropping the 2nd test and seeing if the crash goes away.

Comment 10

[Joseph Yasi]

If I change
if (depth != format->depth && depth != format->depth - alphaSize) {
to
if (depth != format->depth) {
in GLContextProviderGLX.cpp it fixes the problem on my nvidia cards. There are also a ton of depth 32 visuals in that glxinfo output for this card. However, this isn't the case on a machine I have with an Intel card, and changing this test cause a bunch of black boxes in layers when using layers acceleration.

Comment 11

[Joseph Yasi]

Attachment: fix-layers-on-nvidia-325.patch

I have a hack that fixes the problem on NVIDIA. It adds a GLX server version check for NVIDIA Corporation. If it's NVIDIA, it only checks format->depth == depth, otherwise it checks for either format->depth == depth or format->depth - alphaSize == depth.

Comment 12

[Karl Tomlinson (:karlt)]

Thanks very much, Joseph.

That may be as good as we can do.  Are you able to compile and run the glxinfo program on your machine with Intel card, please?  I would have expected (depth != format->depth) to either fail to find a suitable fbconfig, or work properly.
Black boxes were not expected.

Comment 13

[Joseph Yasi]

Attachment: glxinfo_intel_ivb.txt

Output from karlt's modified glxinfo - Intel Ivy Bridge

Comment 14

[Joseph Yasi]

The black boxes issue is weird. It's only for a few small layers. The status message at the bottom always shows as black. It might be a Mesa issue.

Comment 15

[Karl Tomlinson (:karlt)]

Oh, GLContextGLX::CreateTextureImage() won't recover from failing to find an fbconfig, and so that would explain the black boxes.

It's probably failing to find an fbconfig because the fbconfig corresponding to the Composite 32-bit visual is double buffered, and a single-buffered fbconfig is requested here.

I don't know whether it really needs to be single buffered, but the NVIDIA specific workaround seems the right thing to do here.

Comment 16

[Joseph Yasi]

Attachment: fix-layers-on-nvidia-325.patch

Proper mercurial patch against mozilla-beta

Comment 17

[Daniel Jonsson]

I'm getting the same error when launching Firefox OS Simulator. My setup: Firefox 23.0.1, Manjaro 64-bit, Nvidia 325.15 driver.

Comment 18

[Joseph Yasi]

Could someone commit my patch? Thanks.

Comment 19

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

Comment on attachment 787330 [details] [diff] [review]
fix-layers-on-nvidia-325.patch

Joseph, since you're asking for a commit, I'm assuming you wanted the patch reviewed, so I'll ask for the review for you.

Comment 20

[Benoit Jacob [:bjacob] (mostly away)]

Comment on attachment 787330 [details] [diff] [review]
fix-layers-on-nvidia-325.patch

Note:
 1) the commit message still has r=karlt
 2) in fact, karlt _is_ a better reviewer than me for this code. But the above discussion suggests that he already looked and approved of this change.

Comment 21

[Benoit Jacob [:bjacob] (mostly away)]

Oh yes, an obsoleted attachment here has r+ from karlt.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1346fc77965a

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1346fc77965a

Comment 24

[Daniel Jonsson]

The Firefox OS Simulator still crashes on startup in Firefox Nightly 26.0a1 (2013-08-26).

Comment 25

[fabrixx2]

I compiled Firefox 26a1 on Debian and i have fixed
I have installed also 319.49

Comment 26

[Joseph Yasi]

Can we get this patch applied in mozilla-beta and mozilla-aurora, too? I've been using it with the beta for a while.

Comment 27

[Karl Tomlinson (:karlt)]

I don't think this is the kind of change that would be accepted for aurora or beta, sorry.