On 17/06/14 22:09, Marek Olšák wrote:
> Sure. Can you give me a git link and a branch name?
>
Great, branch static-or-shared-pipe-drivers-v2 at
https://github.com/evelikov/Mesa/
Thanks
Emil
> Marek
>
> On Tue, Jun 17, 2014 at 11:06 PM, Emil Velikov <emil.l.veli...@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.veli...@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.veli...@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.veli...@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@lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
