On Tue, Jul 14, 2015 at 3:00 PM, Mario Kleiner <mario.kleiner...@gmail.com> wrote: > On 07/14/2015 05:26 PM, Ilia Mirkin wrote: >> >> On Mon, Jul 13, 2015 at 11:43 PM, Mario Kleiner >> <mario.kleiner...@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?
No, because it's blissfully unaware of the fact that there's anything to wait on for the bo (since it hasn't been kicked out by the process and submitted to the kernel), and thus decides that the bo is ready to use. > >> 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. TBH I have no idea how glamor works. Presumably it may have similar issues, but perhaps it just sync's left and right so the problems remain unseen. There's a "block handler" or something like that which tends to flush things (in nouveau as well IIRC). Although that just flushes out dirty pixmaps, not sure what causes something to get onto the dirty pixmap list. That might still end up not flushing pending commands out. > >>> >>> 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? Lack of having been done, and a lack of desire by all parties involved to do it. As-is the glamor integration is, unfortunately, quite broken. I have an EXA impl for maxwell in the works, although I haven't made progress on it in months. It's missing some sort of nouveau_scratch_data() style call to make a temp bo to put coordinates in so that we can do draws on the 3d engine. I highly suggest lobbying for these features in modesetting though, I've heard of plans (that I highly disapprove of, at least for nouveau, although my say in the matter may be limited) of killing off DDX support for any glamor-capable hw. >>> 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. I'd *really* like at least some attempt to reconcile these things among the DDX's. -ilia _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
