[Nouveau] "enable dri3 support without glamor" causes gnome-shell regression on nv4x

[Hans de Goede]

Hi,

On 03-08-15 17:36, Ilia Mirkin wrote:
> On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede <hdegoede at redhat.com> wrote:
>> Hi,
>>
>> On 30-07-15 16:09, Ilia Mirkin wrote:
>>>
>>> FWIW this is a fail on nv50+ as well. See for example
>>> https://bugs.freedesktop.org/show_bug.cgi?id=91445
>>>
>>> My suspicion is that this is due to the lack of PUSH_KICK in the *Done
>>> exa handlers -- works fine with DRI2, but DRI3 has no synchronization
>>> and so the commands never get flushed out. Easily verified by sticking
>>> PUSH_KICK's everywhere.
>>
>>
>> I do not believe that that is the problem, in my case it clearly
>> seems to be a pitch / swizzle problem rather then a synchronizarion
>> problem, here is what my desktop with gnome shell looks like when
>> using DRI2:
>>
>> https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-good.jpg
>>
>> And this is what it looks like when using DRI3:
>>
>> https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-bad.jpg
>>
>> The DRI2 screenshot is made with Mario's 2 patches on top of
>> current master:
>>
>> http://lists.freedesktop.org/archives/nouveau/2015-July/021740.html
>> http://lists.freedesktop.org/archives/nouveau/2015-July/021741.html
>>
>> And then adding Option "DRI" "2" to xorg.conf.
>
> His patches should have defaulted it to DRI 2 I think, so this is
> unnecessary. In fact you should have had to say "DRI" "3" to get DRI3
> with his patches.
>   --
>>
>> I've also tried disabling EXA using Option "AccelMethod" "none",
>> but that seems to also automatically disable all DRI, leading to
>> software rendering.
>>
>> I discussed this with Ben this morning and he suggested that this
>> is likely a Mesa issue since with DRI3 mesa rather then the ddx
>> allocs the surfaces. I've tried disabling swizzling in the
>> mesa code by forcing nv30_miptree_create() to always take
>> the code path for linear textures, but that leads to the exact
>> same result as before that change.
>
> Ah yes. Very different problem indeed. I actually suspect it has to do
> with swizzling. Look at the white pattern of the moon -- it's all in a
> line. That means that it expected some locality and instead it got
> drawn all on a line. If it were merely a stride problem, I'd expect to
> see strips of the moon below and offset from one another.
>
> So... take a look at nv30_miptree_from_handle -- I wonder if it can
> now receive swizzled textures where it couldn't before.

Ok, that does go in the direction I am expecting the problem to be,
but I'm afraid I'm going to need a bit more guidance, what exactly
am I looking for in that function / which "knobs" should I try to
vary / play with to maybe fix this ?

Regards,

Hans