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 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 <[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. -ilia _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
