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

[Rob Herring]

On Mon, May 1, 2017 at 9:55 AM, 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.

I would really like to, but all my attempts at getting swrast to work
so far have failed.

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

I've got this kind of working with the above patch and disabling all
DRM permission checks. While it seems like things boot up normally, I
can't get anything but a black screen both on qemu and db410c. Even if
I memset buffers when mmapping them, just black. But things like
moving the mouse causes hwc updates and I don't see any errors. I've
successfully used SwiftShader for s/w rendering though.

Rob