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

[Mauro Rossi]

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?

But will this suffice or WuZhen changes in egl/android are anyway, maybe
partialy needed?
Mauro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170506/da7714c9/attachment.html>