[Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

Rob Herring robh at kernel.org
Mon May 22 23:56:45 UTC 2017


On Mon, May 22, 2017 at 5:47 PM, Mike Lothian <mike at fireburn.co.uk> wrote:
> I'm quite sure on Gentoo lib points to lib64 and we have a lib32

I'm talking about Android.

>
> On Mon, 22 May 2017 at 22:46 Rob Herring <robh at kernel.org> wrote:
>>
>> On Mon, May 22, 2017 at 9:16 AM, Emil Velikov <emil.l.velikov at gmail.com>
>> wrote:
>> > On 20 May 2017 at 01:16, Rob Herring <robh at kernel.org> wrote:
>> >> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov
>> >> <emil.l.velikov at gmail.com> wrote:
>> >>> On 18 May 2017 at 23:01, Rob Herring <robh at kernel.org> wrote:
>> >>>> On Thu, May 18, 2017 at 5:25 AM, Emil Velikov
>> >>>> <emil.l.velikov at gmail.com> wrote:
>> >>>>> On 18 May 2017 at 05:10, Chih-Wei Huang <cwhuang at android-x86.org>
>> >>>>> wrote:
>> >>>>>> 2017-05-18 12:01 GMT+08:00 Xu, Randy <randy.xu at intel.com>:
>> >>>>>>>
>> >>>>>>>> -----Original Message-----
>> >>>>>>>> From: Palli, Tapani
>> >>>>>>>> >
>> >>>>>>>> > It's just applied. Isn't it?
>> >>>>>>>> > Yesterday without this patch
>> >>>>>>>> > the color format is mismatch apparently.
>> >>>>>>>>
>> >>>>>>>> Yeah we do need this. TBH I don't quite understand why but will
>> >>>>>>>> try to figure
>> >>>>>>>> it out. I remember we used to have a patch in Surfaceflinger at
>> >>>>>>>> one point
>> >>>>>>>> because visual was hardcoded there and this might be related.
>> >>>>>>>>
>> >>>>>>>> // Tapani
>> >>>>>>>
>> >>>>>>> Sorry, that's for different issue, I mix it with RGB565 blending
>> >>>>>>> one.
>> >>>>>>> This patch is required because some Android GLES test apps, like
>> >>>>>>> gl2_basic, need to create RGBA8888 surface.
>> >>>>>>
>> >>>>>> Indeed it is.
>> >>>>>>
>> >>>>>> As Emil pointed out, the patch was merged before
>> >>>>>> but reverted later since it broke desktop.
>> >>>>>>
>> >>>>>> So what's the current upstreaming plan?
>> >>>>>>
>> >>>>> No idea about a plan, but how you can fix it once and for all:
>> >>>>>
>> >>>>> Extend the loader extension(s) to have a get_caps() callback,
>> >>>>> analogous to __DRIimageExtension::getCapabilities.
>> >>>>> Then the DRI module will query [the loader] and advertise the
>> >>>>> RGBX/RGBA visuals when possible.
>> >>>>
>> >>>> Could we do something compile time instead to enable just for
>> >>>> Android?
>> >>>> Seems like a lot of complexity when the platform needing these pixel
>> >>>> formats doesn't need the backwards compatibility. Or maybe there are
>> >>>> other things needing this interface?
>> >>>>
>> >>> Having a short/mid term ifdef ANDROID is perfectly fine.
>> >>>
>> >>> Can we address some of the existing ones before/alongside the newly
>> >>> added ones?
>> >>> Afacit the nouveau bits are no longer applicable.
>> >>
>> >> Yeah. I don't explicitly warn for KK or less, but will add that and fix
>> >> these.
>> >>
>> >>> While for the
>> >>> gbm/egl 'use "gallium_dri.so"' one can either use your latest build
>> >>> rework or MESA_LOADER_DRIVER_OVERRIDE.
>> >>
>> >> How does the build rework help? My only reservation with using an env
>> >> var is generally Android things don't rely on them and it would break
>> >> working systems. I'm not even completely certain I can set env vars
>> >> globally. It would be nice if the build system could set defaults for
>> >> env vars we could use.
>> >>
>> > IIRC with the rework you have the dri driver names are known as we
>> > reach targets/dri/Android.mk
>>
>> Not really because we have things like freedreno -> msm and virgl ->
>> virtio_gpu, but having a variable like TARGET_DRIVERS is simple
>> enough.
>>
>> > Thus one can reuse them to create the separate drivers
>> >   - be that one blob + {sym,hard}links as we do in autotools/scons, or
>> >  - completely separate drivers like i965 and other classic drivers.
>>
>> Got it. Symlinks are really easy in master:
>>
>> LOCAL_MODULE_SYMLINKS := $(foreach d, $(GALLIUM_TARGET_DRIVERS),
>> $(d)_dri.so)
>>
>> However, that only works in master. There is LOCAL_POST_INSTALL_CMD,
>> but it doesn't support multilib, so we need something like this:
>>
>> LOCAL_POST_INSTALL_CMD := \
>> $(foreach l, lib lib64, \
>>  mkdir -p $(TARGET_OUT_SHARED_LIBRARIES)/$(l)/$(MESA_DRI_MODULE_REL_PATH);
>> \
>>  $(foreach d, $(GALLIUM_TARGET_DRIVERS), ln -sf gallium_dri.so
>> $(TARGET_OUT)/$(l)/$(MESA_DRI_MODULE_REL_PATH)/$(d)_dri.so;) \
>> )
>>
>> This will install broken links when we're not on a multilib build. A
>> bit ugly, but should be harmless.
>>
>> Rob
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list