On 5/8/17, Emil Velikov <[email protected]> wrote: > Having a look at Xlib might be good indeed. > > Then again, the solution you've proposed looks perfectly reasonable, > IMHO. It handles the problem _now_ and should also work when/if we > address Xlib. > I'll take another look today/tomorrow, but I think the series is > perfectly fine to land as-is. > > Thanks > Emil
Hello Emil, Yes you're right. And potentially it can be back-ported to stable branch. Besides it would allow to know which applications aren't X thread safe. And potentially app owners can fix the issue too. By the way, I don't have commit access so feel free to push the series :) On 5/8/17, Eric Anholt <[email protected]> wrote: > gregory hainaut <[email protected]> writes: > >> On Fri, 5 May 2017 17:45:01 +0200 >> Axel Davy <[email protected]> wrote: >> >>> Hi, >>> >>> There should be very few X11 calls while rendering (basically only at >>> the beginning or end of a frame). >>> >>> Why not just always run these calls in the main thread (and wait for >>> glthread work to finish) ? >>> >>> That's basically what we do for gallium nine. >>> >>> Yours, >>> >>> Axel >> >> Hello Axel, >> >> Yes it is another possibility. It would requires to track gl calls that >> end up in X11. >> I'm not sure if there is an easy way to list all those gl functions. There >> are at least the >> draw calls and maybe the clear operations. Besides I'm afraid that we will >> need to handle >> various corner cases of the OpenGL API. It is doable but likely more >> complicated. > > General GL calls (draws, clears) won't call X11 except for DRI2's > GetBuffers. If you're in DRI3, I believe you won't need to worry about > that at all. > > I think this patch is a good start, though. > Hello Eric, Indeed I saw this behavior on Nouveau. I got a crash on GetBuffersWithFormat on DRI2 but it was fine on DRI3. I still kept the check on GLX/DRI3 because I don't know if we have a strong guarantee that X11 is never used. Cheers, Gregory _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
