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

Ilia Mirkin imirkin at alum.mit.edu
Tue Jul 14 08:26:02 PDT 2015


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
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.

>
> 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).

>
> 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.

  -ilia


More information about the Nouveau mailing list