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

[Tomasz Figa]

On Sat, May 6, 2017 at 7:13 PM, Mauro Rossi <issor.oruam at gmail.com> wrote:
>
>
> 2017-05-05 19:14 GMT+02:00 Rob Herring <robherring2 at gmail.com>:
>>
>> 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
>
>
> Hi,
> we have DRM permission checks disabled in android-x86 kernels.
>
> In order to give it a try on virtualbox, do I just need:
>
> 1) build kms_swrast
> 2) apply the fallback patch to egl/drivers/dri2/platform_android.c
> 3) apply patch to kernel? Where may I get this kernel patch?

We use crosreview.com/329448 and crosreview.com/356621 .

>
> But will this suffice or WuZhen changes in egl/android are anyway, maybe
> partialy needed?

I believe the 3 steps should be all you need, assuming that your
gralloc uses render nodes and prime FDs.

Best regards,
Tomasz