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.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