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

Tomasz Figa tfiga at chromium.org
Mon May 1 14:55:56 UTC 2017


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/ .

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.

Best regards,
Tomasz


More information about the mesa-dev mailing list