[Mesa-dev] ANDROID: eglCreateImageKHR missing modifiers

Tapani Pälli tapani.palli at intel.com
Thu Aug 23 07:42:04 UTC 2018



On 08/22/2018 07:56 PM, Emil Velikov wrote:
> Hi all,
> 
> Pardon for dropping in so late. I've seems to have missed this.
> 
> On 24 July 2018 at 14:24, Martin Fuzzey <martin.fuzzey at flowbird.group> wrote:
>> Hi Thomasz,
>>
>> thanks for your reply
>>
>> On 21/07/18 04:27, Tomasz Figa wrote:
>>>
>>>
>>> As you noticed, this adds back the dependency on gralloc handle
>>> structure. Moreover, it actually adds a dependency on the handle
>>> having a binary format compatible with gralloc_gbm_handle_t. This is
>>> not something that we can do in upstream Mesa, since there are more
>>> platforms running gralloc implementations other than gbm_gralloc.
>>
>>
>> Looking at it a bit more is it really that bad?
>>
> Note that there are at least three different implementations - the
> "original" drm_gralloc, gbm_gralloc (props to RobH) and an another one
> used in CrOS (or was it Android?)

Chrome OS and Android Celadon use gralloc implemented in minigbm 
library. I think proposal from Tomasz is the best one, implement API 
between Mesa and gralloc to query modifiers. This makes it possible to 
use multiple gralloc implementations.

> 
>> The compile time dependency is on gralloc_handle.h which is actually part of
>> libdrm not a specific gralloc implementation.
>> Does mesa need to compile with old versions of libdrm?
>> 0r is the structure going to be removed from libdrm?
>>
> I think you missed gbm in gralloc_*gbm*_handle_t. The header
> gralloc_handle.h was added to libdrm by Robert Foss, explicitly to aim
> and standardise things.
> 
> 
>>>
>>> Unfortunately, I don't have a very good solution for this. In Chrome
>>> OS we just don't support modifiers in EGL/GLES on Android. Obviously
>>> it would be a good idea to have some way to query gralloc for the
>>> modifier, but I don't see Android providing any generic way to do it.
>>>
>>> The least evil I can think of as a makeshift for now could be an
>>> optional gralloc0 perform call that returns the modifier for given
>>> buffer.
>>
>>
>> An advantage of a new perform call would be that other gralloc
>> implementations could be extended to support it without changing their
>> handle structure but is that really likely?
>>
> I did not keep track of the gralloc_handle_t discussion, but Rob
> (cc'd) should have some info.
>  From vague memory the standardized handle had means to track modifiers
> amongst others.
> 
> That is obviously somewhat orthogonal to Android making it use of it ;-)
> 
> HTH
> Emil
> _______________________________________________
> 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