[Nouveau] [PATCH] Add Option "DRI3" to allow to disable DRI3 under EXA.

[Mario Kleiner]

On 07/14/2015 05:26 PM, Ilia Mirkin wrote:
> On Mon, Jul 13, 2015 at 11:43 PM, Mario Kleiner
> <mario.kleiner.de at gmail.com> wrote:
>> On 07/07/2015 09:51 PM, Ilia Mirkin wrote:
>>>
>>> Lastly, from some discussions with ajax on IRC, it appears that DRI3
>>> is half-baked at best wrt sync between server and client. I think we
>>> should just disable it by default for now, until issues are ironed
>>> out. (Rather than what this patch has, which is default-on for Xorg >
>>> some version.)
>>
>>
>> What are the remaining known trouble spots wrt. sync? It seems to work
>> pretty well at least for single gpu + unredirected fullscreen windows (==
>> kms page flipping can be used for Presents. That's the use case i usually
>> test very obsessively, as it matters very much for my type of applications,
>> but other than that i only lightly "test" it via regular desktop use, so
>> maybe that's were problems remain?
>
> Adam is the one who actually understands it... I was just asking
> questions and the answer was "that's broken". A user was using DRI3
> with EXA (nouveau DDX), and was seeing render fail in the form of
> stale things on the screen. The nouveau DDX does a lot of "implicit"
> sync stuff... it just emits commands into a pushbuf without kicking
> it. However the libdrm code has cleverness to kick out any pushbufs if
> you do a nouveau_bo_wait and that bo has been referenced.
>
> HOWEVER if you have a pixmap and you share it using the fd thing, and
> another process makes a (shared) bo out of it, and then does a
> nouveau_bo_wait, that in no way will cause the DDX to kick its
> pushbuf. Apparently there's some sort of sync thing that's supposed to

Although then i'd expect the other process to hang in nouveau_bo_wait? 
There probably isn't a specific fdo bug for this?

> happen, but that's entirely unimplemented for DRI3. Unfortunately I
> can't provide more details than that, as my knowledge of X internals
> is quite limited. Some sort of DRI drawable or GLX drawable or ...
> something.
>
> I have no proof that this is the cause of the issue the user was
> seeing, in fact it's just as likely to be something else. However this
> seems like a pretty significant issue to me.
>

Ok, thanks for the explanation. But would this problem then be limited 
to exa + nouveau? glamor uses opengl and thereby mesa's and i think mesa 
gets sync right afaik, at least in the glx/dri3 backend. Didn't look at 
egl backend though. At least i didn't see any such corruption?

I'll change the patch to default to DRI 2 then for exa, and glamor will 
ignore the DRI parameter anyway and stick to DRI3.

>>
>> We can disable it by default on exa - intel and amd/radeon drivers also
>> disable by default. However, on gpus >= maxwell only glamor accel is
>> supported and glamor on nouveau is either dri3/present or no hw accel at all
>> afaics.
>
> You probably saw my patches to just remove glamor from nouveau :) That
> integration doesn't support DRI2, which in turn means no core contexts
> (due to lack of GLX_ARB_create_context_profile), and a slew of other
> issues. Seemed easier to just tell people to go use modesetting, which
> gets all of these things right(er).
>

Hm, a total removal would at least make me and my users rather unhappy 
atm., as without glamor no hw accel at all on >= maxwell. modesetting 
and nouveau are not on par feature-wise atm. E.g., modesetting as of the 
next xorg 1.18 server only provides pageflipping via dri3/present and 
without pageflipping it is game over for many of my use cases on 
nouveau-kms. Also modesetting currently completely lacks ZaphodHeads 
support. Without ZaphodHeads i can't have a page-flipped fullscreen 
window on one subset of outputs and a regular desktop on another subset, 
something that is needed for neuroscience/medical/vr applications.

So i'd rather like to preserve the choice of glamor.

What makes glamor + dri2 difficult to support in nouveau vs. other drivers?

>>
>> Btw. there are also a few patches made by Chris Wilson floating on the
>> mailing list since around january, some are reviewed and tested by myself,
>> but not included in xorg master. Might be good for people to have a look at
>> them and maybe get them into xorg 1.18?
>
> I would not oppose the reviewing of Chris's patches ;) However I'm in
> no position to evaluate them myself.
>
>>
>>>
>>> On Sat, Jul 4, 2015 at 3:03 PM, Emil Velikov <emil.l.velikov at gmail.com>
>>> wrote:
>>>>
>>>> The DRI option with the intel ddx can be used to indicate the following
>>>>    - whether dri is disabled
>>>>    - the dri "version" - dri1, dri2, dri3
>>>>    - the dri module name - doo_dri.so bar_dri.so
>>>>
>>>> I'm not sure how exactly it's supposed to work/works, and I believe
>>>> most of that is due to legacy reasons. I'm just saying let's not do
>>>> the whole thing - just the dri "version" would be great (as you
>>>> suggested).
>>
>>
>> I can change that to allow selection between "2" and "3" - at least for exa,
>> on glamor the parameter "2" would either need to get ignored or it would
>> completely disable hw acceleration. I went for consistency with the ati ddx
>> because i found the intel variant too confusing. I think it changed multiple
>> times during the last year.
>
> Bleargh. The ati ddx option name is much newer. Has it seen a release
> yet? It'd be really nice to get all the DDX's to just agree on
> something, instead of having different-but-similar options which
> confuse everyone.
>

No release tagged yet, so one could still change it.

-mario

>    -ilia
>