[Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

Chris Wilson chris at chris-wilson.co.uk
Thu Jul 14 20:03:48 UTC 2016


On Thu, Jul 14, 2016 at 07:54:59PM +0100, Emil Velikov wrote:
> On 14 July 2016 at 17:49, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Thu, Jul 14, 2016 at 05:29:55PM +0100, Emil Velikov wrote:
> >> Hi Marius,
> >>
> >> Just double-checking - this is an i-g-t patch, isn't it ?
> >>
> >> On 14 July 2016 at 11:39, Marius Vlad <marius.c.vlad at intel.com> wrote:
> >> > Required by commit 2603b98ca (aubdump: Support softpin bos).
> >> >
> >> > Signed-off-by: Marius Vlad <marius.c.vlad at intel.com>
> >> > CC: Kristian Høgsberg Kristensen <kristian.h.kristensen at intel.com>
> >> > ---
> >> >  configure.ac | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/configure.ac b/configure.ac
> >> > index f05bcb0..ade9756 100644
> >> > --- a/configure.ac
> >> > +++ b/configure.ac
> >> > @@ -119,7 +119,7 @@ if test "x$GCC" = "xyes"; then
> >> >  fi
> >> >  AC_SUBST(ASSEMBLER_WARN_CFLAGS)
> >> >
> >> > -PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.64 libdrm])
> >> > +PKG_CHECK_MODULES(DRM, [libdrm_intel >= 2.4.68 libdrm])
> >> Yes please. As you do that one can nuke most/all the "define LOCAL_"
> >> and "struct local_" (in lib/ioctl_wrappers.h)
> >> and replace with with the official symbols. A very nice plus imho ;-)
> >
> > Please don't. It makes running on older installations even more
> > cumbersome.
> Slightly confused here: are you against the libdrm_intel bump, or the
> removal of the local symbols ?

Local symbols. They save a lot of time if you can just get the test you
need compiling and not worry about dependencies. One of the basic
tenents is that we drop a new kernel into an old userspace and expect to
have not broken anything. Being lazy, for smoke testing I just build
in situ.

> Admittedly sometimes distros don't bother/refuse to update libdrm
> which could be an issue in the former case. Although if the package
> (with all the definitions) is compulsory, how would that cause an
> issue ?

The package may not even exist when testing on v.old distro images.
It is mostly a major of convenience, but since the work is already done
to be independent, removing causes more work.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list