[Mesa-dev] Why are we using server-side GLX fbconfigs?

[Michel Dänzer]

On 01/07/17 02:16 AM, Kristian Høgsberg wrote:
> On Fri, Jun 30, 2017 at 2:49 AM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
>> On 06/29/2017 07:30 PM, Kristian Høgsberg wrote:
>>> On Thu, Jun 29, 2017 at 7:36 AM, Thomas Hellstrom <thellstrom at vmware.com>
>>> 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