Hi Rob, On Mon, May 8, 2017 at 11:29 PM, Rob Herring <robherri...@gmail.com> wrote: > 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?
It was quite a bit ago and I don't remember what I tried in the end, but looking at the working environment I used at that time, it was QEMU 2.8.0 and I couldn't get any logs because for some reason I couldn't connect to adb. Maybe I was just unlucky enough to try it at the time there was some known issue in the tree. I'm going try again with current sources. Best regards, Tomasz _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
