On Sat, May 6, 2017 at 7:37 AM, Tomasz Figa <tf...@chromium.org> wrote: > On Sat, May 6, 2017 at 2:14 AM, Rob Herring <robherri...@gmail.com> wrote: >> On Mon, May 1, 2017 at 9:55 AM, Tomasz Figa <tf...@chromium.org> wrote: >>> On Mon, May 1, 2017 at 11:17 PM, Mauro Rossi <issor.or...@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.or...@gmail.com>: >>>>> >>>>> >>>>> >>>>> Il lunedì 9 gennaio 2017, Zhen Wu <wuz...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
