All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emil Velikov <emil.l.velikov@gmail.com>
To: John Stultz <john.stultz@linaro.org>
Cc: Sean Paul <seanpaul@google.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Tomasz Figa <tfiga@google.com>,
	Marissa Wall <marissaw@google.com>,
	Chih-Wei Huang <cwhuang@linux.org.tw>,
	Dan Willemsen <dwillemsen@google.com>
Subject: Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86
Date: Wed, 31 Jan 2018 16:01:01 +0000	[thread overview]
Message-ID: <CACvgo52toBmNYgw+fev6WhL0rKr04r8QQKAautJQgYs9-xLG=A@mail.gmail.com> (raw)
In-Reply-To: <CALAqxLX5c-b9R5NOVkPvoCJaDXt=A8WmeBwPs+G+pxkVAxJqPw@mail.gmail.com>

On 30 January 2018 at 05:42, John Stultz <john.stultz@linaro.org> wrote:
> On Fri, Jan 26, 2018 at 10:33 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> Hi all,
>>
>> Couple of ideas/notes,
>>
>> On 10 January 2018 at 20:36, Rob Herring <robh@kernel.org> wrote:
>>> On Wed, Jan 10, 2018 at 1:09 PM, John Stultz <john.stultz@linaro.org> wrote:
>>>> On Wed, Jan 10, 2018 at 5:48 AM, Rob Herring <robh@kernel.org> wrote:
>>>>> On Tue, Jan 9, 2018 at 11:25 PM, John Stultz <john.stultz@linaro.org> wrote:
>>>>>> When building AOSP after updating libdrm project to the
>>>>>> freedesktop/master branch, I've seen the following build errors:
>>>>>>
>>>>>> external/libdrm/intel/Android.mk: error: libdrm_intel
>>>>>
>>>>> This is only needed for i915 (not i965) now BTW. I'm not sure at what
>>>>> point we stop caring about i915.
>> If you're using any other Intel components - say Beignet or the va
>> driver, I think those still use libdrm_intel.
>>
>> An alternative solution IMHO, is to drop/tweak the API to not bother
>> libpciaccess.
>> I have some ancient cleanup/rework branch
>>
>> https://github.com/evelikov/libdrm/commits/intel-remove-legacy
>
> I'm not opposed to this, but I'm really not familiar with intel use
> cases and what would be ok or not there.
>
>
The unfortunate part is that people familiar don't have to
time/interest to weight in :-(
I might give it another try, one of these days. Unless someone beats me to it.

>>>>>> (SHARED_LIBRARIES android-arm64) missing libpciaccess
>>>>>> (SHARED_LIBRARIES android-arm64) You can set
>>>>>> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
>>>>>> intentional, but that may defer real problems until later in the
>>>>>> build.
>>>>>>
>>>>>> Using ALLOW_MISSING_DEPENDENCIES=true when building allows
>>>>>> things to function properly, but is not ideal.
>>>>>>
>>>>>> So basically, while I'm not including the libdrm_intel package
>>>>>> into the build, just the fact that the Android.mk file references
>>>>>> libpciaccess which isn't a repo included in AOSP causes the build
>>>>>> failure.
>>>>>>
>>>>>> So it seems we need some sort of conditional filter in the
>>>>>> Android.mk to skip over it if we're not building for intel.
>>>>>>
>>>>>> This is my initial attempt at solving this.
>>>>>>
>>>>>> Feedback would be greatly appreciated!
>>>>>>
>>>>>> I note that in the AOSP version of libdrm, the reference to
>>>>>> libpciaccess has been removed. See:
>>>>>>  https://android.googlesource.com/platform/external/libdrm/+/f6a1130dffae8de9ddd0c379066daf1df27fc8af%5E%21/
>>>>>> So I wonder if it make sense to instead remove this upstream as
>>>>>> well?
>>>>>
>>>>> Only if we drop i915.
>>>>
>>>> To be more precise, drop i915 for Android builds (I'm not suggesting
>>>> dropping it elsewhere, just for the Android.mk). I'm really not sure
>>>> which devices might be affected. Anyone able to point me to someone in
>>>> Intel who would know?
>>>
>>> The android-x86 folks would be the ones to ask. I added Chih-Wei.
>>>
>> A really silly question - how are you triggering any of this if you're
>> building on !x86?
>> Is that because the GPU driver is not selected thus you we fall-back
>> to "build all"?
>
> I think its mostly due the fact we're using the toplevel Android.mk
> which includes all Android.mk files in subdirectories.
>
That does not matter. Unless otherwise stated the objects are optional.
Thus they should not be build, unless...

Android changed the policy or you're somehow building stuff that's not required?

>> If so, it might be better to change things to:
>>  - error out if none selected
>>  - allow one to select "all", "x86", "arm" and similar groups thus
>> only the things that can build are build
>> eg. RobH had fun with x86 intrinsics while building the intel Vulkan
>> driver on ARM
>
> I'm not sure quite how to select a gpu driver with the Android build
> system, other then specifying it via a build variable, which is in
> effect what I'm trying to do with this patch.
>
> Other ideas?
>
Based on your input seems like it's not set (grep for
BOARD_GPU_DRIVERS), which results in "everything" being build.
Thus optional libraries (like libdrm_intel) are pulled causing the problem.

My earlier suggestion doesn't sound too crazy, although I'd check with
RobH and the Android-x86 people.
It might require one line change to the device manifest ;-)

Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-01-31 16:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10  5:25 [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86 John Stultz
2018-01-10 13:48 ` Rob Herring
2018-01-10 19:09   ` John Stultz
2018-01-10 20:36     ` Rob Herring
2018-01-26 18:33       ` Emil Velikov
2018-01-30  5:42         ` John Stultz
2018-01-31 16:01           ` Emil Velikov [this message]
2018-01-31 18:46             ` John Stultz
2018-02-01 14:59               ` Rob Herring
2018-02-05 15:13                 ` Emil Velikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACvgo52toBmNYgw+fev6WhL0rKr04r8QQKAautJQgYs9-xLG=A@mail.gmail.com' \
    --to=emil.l.velikov@gmail.com \
    --cc=cwhuang@linux.org.tw \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dwillemsen@google.com \
    --cc=john.stultz@linaro.org \
    --cc=marissaw@google.com \
    --cc=seanpaul@google.com \
    --cc=tfiga@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.