Closed Bug 896287 Opened 7 years ago Closed 7 years ago

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

Categories

(Core :: Graphics, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla26

People

(Reporter: johns, Assigned: joe.yasi)

Details

Attachments

(5 files, 1 obsolete file)

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-/
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.
(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?
Summary: [Linux] nvidia 325.08 driver w/ layers acceleration fails with "ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes)" → [Linux] nvidia 325.08 beta driver w/ layers acceleration fails with "ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes)"
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
The change has propagated to the release version. The 325.15 driver was just released and has the same issue.
Summary: [Linux] nvidia 325.08 beta driver w/ layers acceleration fails with "ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes)" → [Linux] nvidia driver 325.08 and above w/ layers acceleration fails with "ABORT: X_GLXCreatePixmap: BadMatch (invalid parameter attributes)"
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
Is someone able to run the modified glxinfo in bug 779786 comment 2, please, and attach the output here?
This is from the 325.08 beta driver, I can update this with the 325.15 output later today
Here is the output against 325.15.
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.
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.
Attached patch fix-layers-on-nvidia-325.patch (obsolete) — Splinter Review
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.
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.
Attached file glxinfo_intel_ivb.txt
Output from karlt's modified glxinfo - Intel Ivy Bridge
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.
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.
Attachment #787306 - Flags: review+
Proper mercurial patch against mozilla-beta
Attachment #787306 - Attachment is obsolete: true
I'm getting the same error when launching Firefox OS Simulator. My setup: Firefox 23.0.1, Manjaro 64-bit, Nvidia 325.15 driver.
Could someone commit my patch? Thanks.
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.
Attachment #787330 - Flags: review?(bjacob)
Attachment #787330 - Flags: review?(bjacob) → review+
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.
Attachment #787330 - Flags: checkin?
Oh yes, an obsoleted attachment here has r+ from karlt.
Attachment #787330 - Flags: checkin? → checkin+
https://hg.mozilla.org/mozilla-central/rev/1346fc77965a
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
The Firefox OS Simulator still crashes on startup in Firefox Nightly 26.0a1 (2013-08-26).
I compiled Firefox 26a1 on Debian and i have fixed
I have installed also 319.49
Can we get this patch applied in mozilla-beta and mozilla-aurora, too? I've been using it with the beta for a while.
I don't think this is the kind of change that would be accepted for aurora or beta, sorry.
You need to log in before you can comment on or make changes to this bug.