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

[Marek Olšák]

On Mon, Jul 3, 2017 at 5:58 AM, Michel Dänzer <michel at daenzer.net> wrote:
> 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.

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