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

[Emil Velikov]

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
>