On 01/07/17 02:16 AM, Kristian Høgsberg wrote: > On Fri, Jun 30, 2017 at 2:49 AM, Thomas Hellstrom <[email protected]> > wrote: >> On 06/29/2017 07:30 PM, Kristian Høgsberg wrote: >>> On Thu, Jun 29, 2017 at 7:36 AM, Thomas Hellstrom <[email protected]> >>> wrote: >>>> >>>> Hi! >>>> >>>> I was spending some time going through the GLX code to try to fix up the >>>> GLX_OML_swap_method extension implementation. >>>> >>>> I then stumbled across the fact that when we, for direct rendering >>>> connections, construct the list of fbconfigs, we start out with the >>>> server >>>> provided fbconfigs from the AIGLX driver and then try to match each >>>> fbconfig >>>> with a corresponding client driver driconfig. Effectively making us use >>>> the >>>> intersection of the server AIGLX capabilities and the client Direct >>>> rendering capabilities. >>>> >>>> Wouldn't it be more correct, or at least "better" if we, for direct >>>> rendering, took a list of client driver driconfigs, matched each with a >>>> server provided visual and if we have a match, built an fbconfig from >>>> that >>>> driconfig? That would make us essentialy exposing all client driver >>>> capabilities regardless of what the server is using, as long as we have a >>>> matching visual? >>>> >>>> Any insights into this would be greatly appreciated. >>> >>> I'm largely to blame for that. Historically it was part me trying to >>> keep things working they did before as well as having to pay more >>> attention to server side configs as DRI2 tried to share aux buffers >>> (not just color) between clients. I think mesa today only shares color >>> buffers with DRI2 and DRI3 is obviously fine, so what you're proposing >>> sounds like a nice simplification of the code as well as something >>> that might expose more configs to the client. >>> >>> Kristian >> >> >> OK. Thanks Kristian. >> >> FWIW, from what I can tell, dri3 only shares the real front. Has dri2 been >> modified to also allocate local buffers? > > No, DRI2 still uses DRI2GetBuffers or DRI2GetBuffersWithFormat to ask > the X server to allocate buffers, which then shares the buffers with > the client by sending the gem name back in the reply.
True for the back and fake front buffers, but Mesa no longer uses this mechanism for other (mostly depth/stencil) buffers. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
