On 07/14/2015 05:26 PM, Ilia Mirkin wrote:
On Mon, Jul 13, 2015 at 11:43 PM, Mario Kleiner
<[email protected]> 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 <[email protected]>
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
_______________________________________________
Nouveau mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/nouveau
