On Mon, Jul 3, 2017 at 5:58 AM, Michel Dänzer <[email protected]> wrote: > 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.
Yes, Gallium and i965 allocate depth/stencil and MSAA buffers privately by looking at what the visual wants. DRI2 is not involved. I think other classic drivers still allocate depth/stencil through DRI2. Marek _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
