[Mesa-dev] [PATCH 1/2] RFC i965: Bypass a couple of libraries for syscall on x84_64

[Chad Versace]

On Tue 20 Jun 2017, Eric Engestrom wrote:
> On Tuesday, 2017-06-20 09:56:25 -0700, Chad Versace wrote:
> > On Tue 20 Jun 2017, Dave Airlie wrote:
> > 
> > > I'm not sure why avoiding drmIoctl is even a thing, there are plenty
> > > of huge optimisation opportunities, this just seems like a feel good
> > > pointless microptimisation.
> > 
> > There is very little usage of libdrm remaining in i965. If the last bit
> > were dropped, then I believe Chromium OS would no longer have to
> > maintain an Android-fork of libdrm for its Android container.
> 
> Why the fork? Are the changes incompatible with upstream libdrm?

It's a little fork with only a handful of patches. Most changes get
upstreamed. And I'm not the person adding patches to it; that's mostly
krh, Sean Paul, Nicholas Boichat, and Tomasz Figa.

https://chromium.googlesource.com/chromiumos/third_party/libdrm

I should have been clearer. Maintaining the *code* of the libdrm fork is
not the burden I complain about. It's only a handful os patches, after
all.  The maintenance burden I want to remove is maintaining the libdrm
*build* for Chromium OS's Android container.

Each project that we must build for Android's vendor image adds
a small maintenance burden to the large Android maintenance heap. The
burden doesn't lie in the libdrm repo itself; it lies in the tools and
scripts that support the vendor image's construction and its
dependencies.

I'm not claiming that Mesa or i965 should drop libdrm just because it
makes Google's little Android project a little easier to maintain. But,
since i965 is already so close to dropping libdrm, it would be
a nice-to-have.