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

[Tomasz Figa]

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?

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)?

Best regards,
Tomasz