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

[Marek Olšák]

Sure. Can you give me a git link and a branch name?

Marek

On Tue, Jun 17, 2014 at 11:06 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 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
>