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