[PATCH 1/2] glamor: add support for allocating linear buffers

[Emil Velikov]

On 19 June 2015 at 02:12, Dave Airlie <airlied at gmail.com> wrote:
> On 19 June 2015 at 02:02, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 15 June 2015 at 05:08, Michel Dänzer <michel at daenzer.net> wrote:
>>> On 12.06.2015 08:48, Dave Airlie wrote:
>>>> We need this for doing USB offload scenarios using glamor
>>>> and modesetting driver.
>>>>
>>>> unfortunately only gbm in mesa 10.6 has support for the
>>>> linear API.
>>>>
>>>> Signed-off-by: Dave Airlie <airlied at redhat.com>
>>>> ---
>>>>  configure.ac                  |  5 +++++
>>>>  glamor/glamor.h               |  3 ++-
>>>>  glamor/glamor_egl.c           |  5 ++++-
>>>>  glamor/glamor_egl_stubs.c     |  2 +-
>>>>  glamor/glamor_fbo.c           | 10 +++++-----
>>>>  hw/xwayland/xwayland-glamor.c |  2 +-
>>>>  include/dix-config.h.in       |  3 +++
>>>>  7 files changed, 21 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/configure.ac b/configure.ac
>>>> index f760730..d0908e5 100644
>>>> --- a/configure.ac
>>>> +++ b/configure.ac
>>>> @@ -2105,6 +2105,11 @@ if test "x$GLAMOR" = xyes; then
>>>>       if test "x$GBM" = xyes; then
>>>>               AC_DEFINE(GLAMOR_HAS_GBM, 1,
>>>>                         [Build glamor with GBM-based EGL support])
>>>> +             PKG_CHECK_MODULES(GBM_HAS_LINEAR, "gbm >= 10.6.0", [GBM_HAS_LINEAR=yes], [GBM_HAS_LINEAR=no])
>>>> +             if test "x$GBM_HAS_LINEAR" = xyes; then
>>>> +                     AC_DEFINE(GLAMOR_HAS_GBM_LINEAR,  1,
>>>> +                       [Build glamor/gbm has linear support])
>>>> +             fi
>>>
>>> It would be better to use AC_CHECK_DECL for this, as is done in
>>> xf86-video-amdgpu. That way it does the right thing even if somebody
>>> backports GBM_BO_USE_LINEAR to an older version of Mesa.
>>>
>> Fwiw I second this suggestion. As we know GBM is an API and others may
>> provide alternative implementation of it (for example CrOS has
>> minigbm). Imho using the mesa version in (m)any of the pc files is a
>> bug, which should be addressed, rather than relied upon.
>>
>
> I'll change it because I prefer the suggestion,
>
> but GBM is both an API and an ABI,
Agreed.

> so really the pc.in represents
> the API version,
What I'm saying is: considering the API/ABI changes introduced in the
library, it seems wrong to have used the mesa version inside gbm.pc.
Either way the deed is done, and there isn't much we can do about it.

> so any compatible API should use the mesa version
> in its gbm.pc file until such time as someone splits the gbm API
> out into a separate project,
Considering the tight integration (dare I say it "hidden, unversioned
and unchecked" ABI) between libEGL and libgbm, this might be a bit of
a pain to achieve and/or maintain.

> at which point you'd want to continue
> the versioning from the mesa point to avoid epochs. So I don't
> take your argument, the API version is what we ship in the gbm.pc
> file, compatible implementations should make the same API changes
> in their same versions.
>
Other companies may use different versionning schemes (YYYY/MM/DD) and
which they cannot shift away from for whatever reason. Based on that
(plus the libEGL <> libgbm ABI mentioned above) sticking with "use
mesa's version" seems a bit impossible/narrow minded imho. I think we
can all agree things are less than perfect and checking the version in
the pc file is not a good idea.

> Now the problem I don't solve here, is how to know if the GBM
> ABI supports passing the linear flag in, since we don't bump
> the library version often, and I've no idea if there is any nice
> way to make it discoverable.
>
I believe it's the packager's responsibility to ensure that the
runtime library version is the same or greater than the build time
one. Some projects have section "for packagers" in their release
notes, to prevent/minimise slip-ups in the dependency
handling/tracking.

Cheers,
Emil