[Mesa-dev] Static/shared pipe-drivers (was megadriver/pipe-loader-to-all)

[Emil Velikov]

On 17/06/14 21:30, Marek Olšák wrote:
> Sorry if this is a stupid question, but are you only talking about
> gallium-gbm? What is the purpose of the gbm state tracker and how is
> it different from the default one in src/gbm?
> 
The whole of these series (in the various forms that have been on the list)
target exclusively the gallium targets.

Don't ask me about specifics but the overall picture is:
There are a couple of loaders (src/egl and src/gbm) each of which has two
_backends_ - dri (src/{egl,gbm}/backends/dri) and gallium
(src/gallium/statetracker). The former works with the *_dri.so modules while
the latter strips down layers of abstractions we have and works directly with
gallium. The dri backends are built into their loaders, while the gallium ones
are separate modules.
One can use egl_dri + gbm_dri or gallium_egl + gallium_gbm.

Would you feel like chipping in and/or testing the radeon patches ?

Emil
> Thanks,
> 
> Marek
> 
> On Tue, Jun 17, 2014 at 10:25 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 17/06/14 20:25, Ilia Mirkin wrote:
>>> On Tue, Jun 17, 2014 at 3:05 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> On 17/06/14 19:39, Ilia Mirkin wrote:
>>>>> On Thu, Jun 12, 2014 at 3:56 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> These patches add support for building (grouping) the various targets per
>>>>>> API, meaning that only one library will be created  for e.g. vdpau
>>>>>> (libvdpau_gallium) with individual ones (libvdpau_r600) being a hardlink
>>>>>> to it.
>>>>>>
>>>>>> This allows us to have substantial space savings as the API(state-tracker)
>>>>>> is available only once. Additionally it adds support for shared
>>>>>> pipe-drivers via a _unstable_ interface, which saves us the duplication
>>>>>> across X APIs.
>>>>>
>>>>> Given that this is an unstable API, how do you handle versioning? What
>>>>> will happen when people (invariably) mix & match?
>>>>>
>>>> Thanks for asking.
>>>>
>>>> Perhaps I should mention here as well that the xa, gbm and opencl targets
>>>> currently use it. This series converts the former to to "static" by default.
>>>> If one wants to use "shared pipe-drivers" they need to edit the configure
>>>> script :)
>>>>
>>>> Once all the mayhem is done, a few explicit notes will be added to the
>>>> documentation/release notes.
>>>>
>>>> About mix and match:
>>>> The api has not changed since the addition of configuration function (commit
>>>> ec7d5b8c021 ~2011) and the introduction of pipe-loader (commit 317be33d732
>>>> ~2011). Not sure about future changes though.
>>>> The series will make things that are already broken more obvious, rather than
>>>> "introducing" the issue.
>>>
>>> Well, the API is not just the list of functions, but also how they're
>>> used and what their arguments mean. For example I recently introduced
>>> pipe_context->clear_buffer, which in turn would have shifted a bunch
>>> of functions down. A state tracker with one idea of pipe_context
>>> layout and a driver with a different idea would lead to a general lack
>>> of happiness. I'm sure there are other similar situatoins. (Or perhaps
>>> I'm misunderstanding the level at which these things are split up.)
>>>
>>> I guess what I was alluding to in a passive-aggressive way was that
>>> versioning should be handled... somehow. Not sure if versions have to
>>> be numeric, but if not, throwing the git commit into the SONAME would
>>> suffice, for example.
>>>
>> How do you propose we retrofit the existing problem that xa, gbm and opencl
>> expose ?
>> Perhaps I should re-iterate - by default I'm removing the issue. People that
>> know what they are doing (manually edit configure.ac) get to pick the pieces
>> themselves.
>>
>>> I'm just concerned this will lead to very strange issues that will be
>>> difficult to diagnose.
>>>
>> Simple idea that just came to mind: add a compile + runtime note: "You're
>> using an unstable and unsupported..." when the pipe-drivers are used.
>>
>> IMHO you're worrying too much, considering the current users and the number of
>> issues that is has caused so far. Or can it be that I'm overly optimistic ?
>>
>> Either way the above suggestion (apart from the "force static" code in
>> configure, and "don't do it" documentation) sounds reasonable imho.
>>
>> -Emil
>>>   -ilia
>>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev