Bug 73282 - [UXA] Rendering to screen-sized pbuffer affects actual screen
Summary: [UXA] Rendering to screen-sized pbuffer affects actual screen
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2014-01-04 18:05 UTC by Alexander Monakov
Modified: 2014-01-06 14:43 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

reproducer (1.68 KB, text/plain)
2014-01-04 18:05 UTC, Alexander Monakov
no flags Details

Description Alexander Monakov 2014-01-04 18:05:18 UTC
Created attachment 91488 [details]

The attached testcase fills a GLX Pbuffer with 0x80 gray.  It never creates a window and thus should not affect the screen.

However, passing actual screen dimensions in arguments:

    ./a.out 1920 1080

causes the screen to become gray (as if the pbuffer's contents became visible).  It also "works" to pass actual screen width and a fraction of actual height, in which case the top fraction of the screen becomes gray.  Passing 4096 4096 in my case caused the test to be killed with "bus error".  The window manager (xfwm4, fluxbox) becomes non-functional after triggering the issue.

This is reproducible on IVB with UXA, but not SNA.

Is UXA, um, somehow misallocating buffers for the pbuffer or swapping Mesa's offscreen buffers onscreen?  I'd try to debug it myself, but I have no idea how to approach it.  Please let me know if additional info is required.
Comment 1 Chris Wilson 2014-01-06 14:19:21 UTC
Do you also see a SIGSEGV (gen7_update_renderbuffer_surface, gen7_wm_surface_state.c:509)?

Anyway this is rather weird.
Comment 2 Chris Wilson 2014-01-06 14:43:57 UTC
commit 28810d5b367942c96acbc696f27105259422a0d1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jan 6 14:26:38 2014 +0000

    uxa/dri: Pixmap are offscreen and not attached to any display
    As the code current assumes that pixmaps are located at screen origin
    (0,0), it assumes that they are all on the first CRTC. However, since
    they are offscreen, this leads to such complications as attempting to
    emit vsync swapbuffers, and even worse attempting to swap a GLXPixmap
    onto the scanout following a DRI2SwapBuffers.
    Reported-by: Alexander Monakov <amonakov@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73282
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.