[Mesa-dev] [PATCH 7/8] android: support creating texture from gralloc buffer

[Emil Velikov]

On 1 May 2017 at 15:55, Tomasz Figa <tfiga at chromium.org> wrote:
> On Mon, May 1, 2017 at 11:17 PM, Mauro Rossi <issor.oruam at gmail.com> wrote:
>> Hi all,
>>
>> another try to merge android swrast patches in mesa 17.1 or mesa-dev
>> if they are somehow considered useful for android.
>>
>> Mauro
>>
>>
>> 2017-01-20 20:17 GMT+01:00 Mauro Rossi <issor.oruam at gmail.com>:
>>>
>>>
>>>
>>> Il lunedì 9 gennaio 2017, Zhen Wu <wuzhen at jidemail.com> ha scritto:
>>>>
>>>> Thanks for your review, Rob. Using kms-dri would mean writing a new
>>>> gralloc to basically the same thing as
>>>> gralloc.default and moving to grm_gralloc seems to be a bigger task meant
>>>> for another day. But I agree we would
>>>> want to avoid introducing dependency. Would extending drisw loader func
>>>> and limit gralloc dependency in egl_android
>>>> ok with you?
>>>
>>>
>>> Just to avoid a stall situation,
>>>
>>> I get that Rob comments are here as here is the gralloc dependency to be
>>> avoided.
>>> Is this assumption correct?
>>>
>>> BTW I can also confirm patches are working as I tested with Android CTS
>>> dEQP test for EGL and GLES2 modules with marshmallow-x86
>>>
>>> Mauro
>>
>>
>> Hi Rob,
>> we are still maintaining these changes to use llvmpipe
>> they are working and they are useful for testing on VMs and for software
>> rendering.
>>
>> May I kindly jask  if the unwanted gralloc dependency was essentially in
>> this patch 07/08
>> "android: support creating texture from gralloc buffer"?
>>
>> And if that is confirmed, which approaches are applicable here?
>>
>> 1. Reuse some kms-dri specific change implemented in CrOS (? Tomasz did you
>> neeed to change something in dri/sw winsys ? )
>
> Did you by any chance mean kms_swrast? If so, we don't need any
> changes other than falling back to kms-dri in
> egl/drivers/dri2/platform_android.c, if hardware driver fails to load.
> See this patch: https://chromium-review.googlesource.com/c/442414/ .
>
I'd imagine that the kms_swrast fallback should be sufficient, the
patch is missing any information, so there may be more to it.
Mildly related:

Tomasz, any ideas why we didn't merge this fall-back patch? IIRC we
had some related patches that looked a bit hacky, but this looks good
as-is.
Nit: use "char* driver_name" instead of "bool swrast".

> However on ChromeOS we disallow access to DRI control nodes from
> render processes, so we use DRI render nodes and have a local patch
> for the kernel to allow dumb BO ioctls on render nodes. If you can use
> control nodes, you should be okay with the code as is.
>
IIRC control nodes are gone upstream.

Thanks
Emil