glamor woes with nouveau

[Eric Anholt]

Olivier Fourdan <fourdan at gmail.com> writes:

> Hi all,
>
> I am trying to investigate an issue with Xwayland that affects pixmap
> rendering only some hardware with nouveau (basically, older hardware).
>
> Initally, I started looking into this because of reported black icons in
> gtk2 (X11/Xwayland) apps in GNOME and RH bugzilla, and discovered that one
> possible common factor is the use on nouveau:
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=1411447
>   https://bugzilla.gnome.org/show_bug.cgi?id=776255
>
> While trying to reproduce, I got a much worse problem where sometimes, the
> entire window would appear completely garbled.
>
> I initially thought of an issue in meda DRI driver, so I filed bug 99400
> for this, but I am now wondering if this could be an issue with glamor
> instead:
>
>   https://bugs.freedesktop.org/show_bug.cgi?id=99400
>
> Disabling glamor in Xwayland makes the problem go away, whereas Mesa with
> debug enabled doesn't seem to complain much
>
> Running Xwayland with GLAMOR_DEBUG=3 shows a few messages, most noticeably:
>
>   glamor_composite_choose_shader: Unsupported source picture format.
>     glamor_composite_with_shader: glamor_composite_choose_shader failed
>                 glamor_composite: from picts 0x25c8050:0x267ff60 48x48 /
> 0x25c3940:0x267ff60 48 x 48 (f,f)  to pict 0x2586890:0x2606e30 523x300 (f)
>
> 523x300 would match the size of the window where the entire background is
> (apparently) random.
>
> When the errors occur, we would end up in the fallback code
> of glamor_composite() in glamor/glamor_render.c
>
> But then I tried the same on intel hardware an get the exact same glamor
> messages, and yet the rendering is fine on intel, so I am a bit confused,
> could that be an issue with the fallback code in  glamor_composite() or is
> it that the source pixmap being copied is actually garbled?

It sounds like nouveau is failing at the getteximage/texsubimage cycle
in the fallback path.  X sometimes finds bugs in Mesa than our testcases
miss, because it frequently reads/writes subsets of a texture.  In
comparison, testcases tend to use solid colors, window system
renderbuffers instead of textures, and the whole renderbuffer instead of
a subset.

I'd recommend getting an apitrace of the rendering under Xephyr -glamor,
if possible.   Then you can use apitrace to dump images of each draw
call on both intel and nouveau, and identify which draw call/texture
upload was the one that failed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170118/b6d42de3/attachment.sig>