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

[Rob Herring]

On Sat, May 6, 2017 at 7:37 AM, Tomasz Figa <tfiga at chromium.org> wrote:
> On Sat, May 6, 2017 at 2:14 AM, Rob Herring <robherring2 at gmail.com> wrote:
>> 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.
>
> Which DRM drivers end up being used in both setups?

QEMU is virtio-gpu and db410c is freedreno. For h/w rendering, the
render node is used for EGL and GBM. For s/w rendering, I'm using the
card node.

> FYI, I tried to get the Android tree from your github (you pointed to
> me some time ago for reproducing another issue) to work and couldn't
> get anything besides black screen even without any changes. I just
> followed the steps from the guide, without doing anything special. Any
> chance there is simply something flaky there (a race condition or some
> dependency on certain implementation specific behavior of some module)
> that simply stops working if the running setup changes even a bit
> (e.g. I might have used a different version of Qemu)?

Do you have a log? What version of QEMU did you try?

Rob