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

[Rob Herring]

On Mon, May 22, 2017 at 5:47 PM, Mike Lothian  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  wrote:
>>
>> On Mon, May 22, 2017 at 9:16 AM, Emil Velikov 
>> wrote:
>> > On 20 May 2017 at 01:16, Rob Herring  wrote:
>> >> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov
>> >>  wrote:
>> >>> On 18 May 2017 at 23:01, Rob Herring  wrote:
>>  On Thu, May 18, 2017 at 5:25 AM, Emil Velikov
>>   wrote:
>> > On 18 May 2017 at 05:10, Chih-Wei Huang 
>> > wrote:
>> >> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>> >>>
>>  -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 RGBA 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@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Mike Lothian]

I'm quite sure on Gentoo lib points to lib64 and we have a lib32

On Mon, 22 May 2017 at 22:46 Rob Herring  wrote:

> On Mon, May 22, 2017 at 9:16 AM, Emil Velikov 
> wrote:
> > On 20 May 2017 at 01:16, Rob Herring  wrote:
> >> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> >>> On 18 May 2017 at 23:01, Rob Herring  wrote:
>  On Thu, May 18, 2017 at 5:25 AM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> > On 18 May 2017 at 05:10, Chih-Wei Huang 
> wrote:
> >> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
> >>>
>  -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 RGBA 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Rob Herring]

On Mon, May 22, 2017 at 9:16 AM, Emil Velikov  wrote:
> On 20 May 2017 at 01:16, Rob Herring  wrote:
>> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov  
>> wrote:
>>> On 18 May 2017 at 23:01, Rob Herring  wrote:
 On Thu, May 18, 2017 at 5:25 AM, Emil Velikov  
 wrote:
> On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
>> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>>>
 -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 RGBA 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 20 May 2017 at 01:16, Rob Herring  wrote:
> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov  
> wrote:
>> On 18 May 2017 at 23:01, Rob Herring  wrote:
>>> On Thu, May 18, 2017 at 5:25 AM, Emil Velikov  
>>> wrote:
 On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>>
>>> -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 RGBA 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
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.

On the envvar side - it is meant as a workaround. It's not something
we want to set by the build.
Android-x86 already sets some at boot time, so it should be possible
to add one there.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Rob Herring]

On Fri, May 19, 2017 at 12:57 PM, Emil Velikov  wrote:
> On 18 May 2017 at 23:01, Rob Herring  wrote:
>> On Thu, May 18, 2017 at 5:25 AM, Emil Velikov  
>> wrote:
>>> On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>
>> -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 RGBA 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.

Rob
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 18 May 2017 at 23:01, Rob Herring  wrote:
> On Thu, May 18, 2017 at 5:25 AM, Emil Velikov  
> wrote:
>> On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
>>> 2017-05-18 12:01 GMT+08:00 Xu, Randy :

> -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 RGBA 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. While for the
gbm/egl 'use "gallium_dri.so"' one can either use your latest build
rework or MESA_LOADER_DRIVER_OVERRIDE.

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Tapani Pälli]

On 05/19/2017 04:19 AM, Xu, Randy wrote:

-Original Message-
From: Rob Herring [mailto:r...@kernel.org]
Sent: Friday, May 19, 2017 6:01 AM
To: Emil Velikov 
Cc: Chih-Wei Huang ; ML mesa-dev ; Xu, Randy 
Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
configure and reorder the list

On Thu, May 18, 2017 at 5:25 AM, Emil Velikov 
wrote:

On 18 May 2017 at 05:10, Chih-Wei Huang 

wrote:

2017-05-18 12:01 GMT+08:00 Xu, Randy :



-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 RGBA 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?


I also wish that, can we use macro, like "#if ANDROID" ?
It's not necessary to enable these two visuals for all platform, but it's 
really important for Android.


IMO we should fix Android instead, there is no reason why it would 
*require* these formats.


// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Xu, Randy]

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Friday, May 19, 2017 6:01 AM
> To: Emil Velikov 
> Cc: Chih-Wei Huang ; ML mesa-dev  d...@lists.freedesktop.org>; Xu, Randy 
> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
> configure and reorder the list
> 
> On Thu, May 18, 2017 at 5:25 AM, Emil Velikov 
> wrote:
> > On 18 May 2017 at 05:10, Chih-Wei Huang 
> wrote:
> >> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
> >>>
>  -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 RGBA 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?

I also wish that, can we use macro, like "#if ANDROID" ?
It's not necessary to enable these two visuals for all platform, but it's 
really important for Android.

> 
> Rob
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Rob Herring]

On Thu, May 18, 2017 at 5:25 AM, Emil Velikov  wrote:
> On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
>> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>>>
 -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 RGBA 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?

Rob
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Mike Lothian]

Can you make sure whatever you do it's well tested

I shudder every time I see such requests as it nearly always seems to cause
breakage for me

On Thu, 18 May 2017 at 11:25 Emil Velikov  wrote:

> On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
> > 2017-05-18 12:01 GMT+08:00 Xu, Randy :
> >>
> >>> -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 RGBA 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.
>
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
>>
>>> -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 RGBA 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.

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Tapani Pälli]

On 05/18/2017 07:10 AM, Chih-Wei Huang wrote:

2017-05-18 12:01 GMT+08:00 Xu, Randy :

-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 RGBA 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?



I believe this visual is not supported by our driver properly, as 
example the angeles demo (one of those 'native test apps') has a lot of 
rendering artifacts so at least for now this will be only in Android tree.



// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Chih-Wei Huang]

2017-05-18 12:01 GMT+08:00 Xu, Randy :
>
>> -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 RGBA 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?


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Xu, Randy]

> -Original Message-
> From: Palli, Tapani
> Sent: Thursday, May 18, 2017 11:51 AM
> To: Chih-Wei Huang ; Xu, Randy
> 
> Cc: ML mesa-dev ; Emil Velikov
> 
> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
> configure and reorder the list
> 
> On 05/18/2017 06:41 AM, Chih-Wei Huang wrote:
> > 2017-05-18 11:26 GMT+08:00 Xu, Randy :
> >>> -Original Message-
> >>> From: Chih-Wei Huang [mailto:cwhu...@android-x86.org]
> >>> Sent: Thursday, May 18, 2017 11:04 AM
> >>> To: Xu, Randy 
> >>> Cc: Emil Velikov ; ML mesa-dev  >>> d...@lists.freedesktop.org>
> >>> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to
> >>> EGL configure and reorder the list
> >>>
> >>> 2017-05-12 12:04 GMT+08:00 Xu, Randy :
>  Thanks, Emil
> 
>  dEQP has patch to exclude 565 blend cases (commit named "Exclude
> >>> RGB565 blending cases from the must-pass"), so we don’t need any
> >>> patches now.
> >>>
> >>> Hi Randy, Tapani,
> >>> I think we still need a patch. Right?
> >>> I see the similar patch is still applied to Android-IA codebase.
> >> Which patch do you means? As Google has excluded the RGB565 for
> >> blending test, we don’t need patch Mesa
> > This one:
> > https://github.com/android-ia/external-
> mesa/commit/72d5e389c6adfbca8ec
> > 18885c93191dc62c78c82
> >
> > 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 RGBA surface.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Tapani Pälli]

On 05/18/2017 06:41 AM, Chih-Wei Huang wrote:

2017-05-18 11:26 GMT+08:00 Xu, Randy :

-Original Message-
From: Chih-Wei Huang [mailto:cwhu...@android-x86.org]
Sent: Thursday, May 18, 2017 11:04 AM
To: Xu, Randy 
Cc: Emil Velikov ; ML mesa-dev 
Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
configure and reorder the list

2017-05-12 12:04 GMT+08:00 Xu, Randy :

Thanks, Emil

dEQP has patch to exclude 565 blend cases (commit named "Exclude

RGB565 blending cases from the must-pass"), so we don’t need any patches
now.

Hi Randy, Tapani,
I think we still need a patch. Right?
I see the similar patch is still applied to Android-IA codebase.

Which patch do you means? As Google has excluded the RGB565 for blending test, 
we don’t need patch Mesa

This one:
https://github.com/android-ia/external-mesa/commit/72d5e389c6adfbca8ec18885c93191dc62c78c82

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

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Chih-Wei Huang]

2017-05-18 11:26 GMT+08:00 Xu, Randy :
>
>> -Original Message-
>> From: Chih-Wei Huang [mailto:cwhu...@android-x86.org]
>> Sent: Thursday, May 18, 2017 11:04 AM
>> To: Xu, Randy 
>> Cc: Emil Velikov ; ML mesa-dev > d...@lists.freedesktop.org>
>> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
>> configure and reorder the list
>>
>> 2017-05-12 12:04 GMT+08:00 Xu, Randy :
>> > Thanks, Emil
>> >
>> > dEQP has patch to exclude 565 blend cases (commit named "Exclude
>> RGB565 blending cases from the must-pass"), so we don’t need any patches
>> now.
>>
>> Hi Randy, Tapani,
>> I think we still need a patch. Right?
>> I see the similar patch is still applied to Android-IA codebase.
>
> Which patch do you means? As Google has excluded the RGB565 for blending 
> test, we don’t need patch Mesa

This one:
https://github.com/android-ia/external-mesa/commit/72d5e389c6adfbca8ec18885c93191dc62c78c82

It's just applied. Isn't it?
Yesterday without this patch
the color format is mismatch apparently.


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Xu, Randy]

> -Original Message-
> From: Chih-Wei Huang [mailto:cwhu...@android-x86.org]
> Sent: Thursday, May 18, 2017 11:04 AM
> To: Xu, Randy 
> Cc: Emil Velikov ; ML mesa-dev  d...@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
> configure and reorder the list
> 
> 2017-05-12 12:04 GMT+08:00 Xu, Randy :
> > Thanks, Emil
> >
> > dEQP has patch to exclude 565 blend cases (commit named "Exclude
> RGB565 blending cases from the must-pass"), so we don’t need any patches
> now.
> 
> Hi Randy, Tapani,
> I think we still need a patch. Right?
> I see the similar patch is still applied to Android-IA codebase.

Which patch do you means? As Google has excluded the RGB565 for blending test, 
we don’t need patch Mesa

> 
> 
> --
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Chih-Wei Huang]

2017-05-12 12:04 GMT+08:00 Xu, Randy :
> Thanks, Emil
>
> dEQP has patch to exclude 565 blend cases (commit named "Exclude RGB565 
> blending cases from the must-pass"), so we don’t need any patches now.

Hi Randy, Tapani,
I think we still need a patch. Right?
I see the similar patch is still applied
to Android-IA codebase.


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Xu, Randy]

Thanks, Emil

dEQP has patch to exclude 565 blend cases (commit named "Exclude RGB565 
blending cases from the must-pass"), so we don’t need any patches now.

Thanks,
Randy


> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Thursday, May 11, 2017 8:55 PM
> To: Xu, Randy 
> Cc: ML mesa-dev 
> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
> configure and reorder the list
> 
> On 11 May 2017 at 13:43, Xu, Randy  wrote:
> > Thanks, Emil
> >
> > Yes, I have discussed it with Tapani, my proposed solution is not good for
> desktop Linux.
> > We will keep the change for Android only. And I will take care of it.
> >
> What I'm saying is that you don't need to keep that change for Android only.
> Add some trivial infra bits and merge them alongside the patch.
> But at the end of the day you'll be rebasing the patch XX times, so ... enjoy 
> :-P
> 
> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 11 May 2017 at 13:43, Xu, Randy  wrote:
> Thanks, Emil
>
> Yes, I have discussed it with Tapani, my proposed solution is not good for 
> desktop Linux.
> We will keep the change for Android only. And I will take care of it.
>
What I'm saying is that you don't need to keep that change for Android
only. Add some trivial infra bits and merge them alongside the patch.
But at the end of the day you'll be rebasing the patch XX times, so
... enjoy :-P

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Xu, Randy]

Thanks, Emil

Yes, I have discussed it with Tapani, my proposed solution is not good for 
desktop Linux.
We will keep the change for Android only. And I will take care of it.


Thanks,
Randy


> -Original Message-
> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
> Sent: Thursday, May 11, 2017 8:31 PM
> To: Xu, Randy 
> Cc: ML mesa-dev 
> Subject: Re: [Mesa-dev] [PATCH] i965: Add RGBX and RGBA to EGL
> configure and reorder the list
> 
> Hi Randy,
> 
> Found this stuck in my Drafts.
> 
> On 11 January 2017 at 08:04, Randy Xu  wrote:
> > On Android platform, the EGL configuration query (eglGetConfigs) will
> > check the DRI backend. Add R8G8B8A8 and R8G8B8X8 to meet the native
> > app test requirement (like gl2_basic etc.).
> >
> > Reorder the list and move the B5G6R5 to the tail, it can solve two
> > dEQP failures on Android platform, they are dEQP-
> GLES3.functional.fragment_ops.
> >
> blend.default_framebuffer.rgb_func_alpha_func.src.dst_color_one_minus_
> > dst_alpha & .dst_color_constant_alpha. These two failures are all
> > caused by B5G6R5 low precision and the dEQP case always choose the
> > first EGL configure id in list returned by eglGetConfigs. The failure
> > cannot be reproduced on X11 platform as Intel does not support 16bit
> > visuals with X driver
> >
> When developing changes please make sure that you've tested those against
> the normal Linux builds.
> Either handle this yourself, or check with the devs on #intel-gfx about going
> through the Intel CI.
> 
> An identical change broke KDE/Qt in the past [1] and there is some discussion
> how to fix it properly [2].
> 
> Thanks
> Emil
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=95071
> [2] https://lists.freedesktop.org/archives/mesa-dev/2016-April/113654.html
> (check through the thread)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

Hi Randy,

Found this stuck in my Drafts.

On 11 January 2017 at 08:04, Randy Xu  wrote:
> On Android platform, the EGL configuration query (eglGetConfigs) will
> check the DRI backend. Add R8G8B8A8 and R8G8B8X8 to meet the native app
> test requirement (like gl2_basic etc.).
>
> Reorder the list and move the B5G6R5 to the tail, it can solve two dEQP
> failures on Android platform, they are dEQP-GLES3.functional.fragment_ops.
> blend.default_framebuffer.rgb_func_alpha_func.src.dst_color_one_minus_dst_alpha
> & .dst_color_constant_alpha. These two failures are all caused by B5G6R5 low
> precision and the dEQP case always choose the first EGL configure id in list
> returned by eglGetConfigs. The failure cannot be reproduced on X11 platform as
> Intel does not support 16bit visuals with X driver
>
When developing changes please make sure that you've tested those
against the normal Linux builds.
Either handle this yourself, or check with the devs on #intel-gfx
about going through the Intel CI.

An identical change broke KDE/Qt in the past [1] and there is some
discussion how to fix it properly [2].

Thanks
Emil

[1] https://bugs.freedesktop.org/show_bug.cgi?id=95071
[2] https://lists.freedesktop.org/archives/mesa-dev/2016-April/113654.html
(check through the thread)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Randy Xu]

On Android platform, the EGL configuration query (eglGetConfigs) will
check the DRI backend. Add R8G8B8A8 and R8G8B8X8 to meet the native app
test requirement (like gl2_basic etc.).

Reorder the list and move the B5G6R5 to the tail, it can solve two dEQP
failures on Android platform, they are dEQP-GLES3.functional.fragment_ops.
blend.default_framebuffer.rgb_func_alpha_func.src.dst_color_one_minus_dst_alpha
& .dst_color_constant_alpha. These two failures are all caused by B5G6R5 low
precision and the dEQP case always choose the first EGL configure id in list
returned by eglGetConfigs. The failure cannot be reproduced on X11 platform as
Intel does not support 16bit visuals with X driver

Signed-off-by: Randy Xu 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index e1c3c19..d55db27 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1298,9 +1298,11 @@ static __DRIconfig**
 intel_screen_make_configs(__DRIscreen *dri_screen)
 {
static const mesa_format formats[] = {
-  MESA_FORMAT_B5G6R5_UNORM,
+  MESA_FORMAT_R8G8B8A8_UNORM,
+  MESA_FORMAT_R8G8B8X8_UNORM,
   MESA_FORMAT_B8G8R8A8_UNORM,
   MESA_FORMAT_B8G8R8X8_UNORM
+  MESA_FORMAT_B5G6R5_UNORM,
};
 
/* GLX_SWAP_COPY_OML is not supported due to page flipping. */
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev