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

[Marek Olšák]

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?

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