On 1 May 2017 at 15:55, 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. >> >> 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/ . > I'd imagine that the kms_swrast fallback should be sufficient, the patch is missing any information, so there may be more to it. Mildly related:
Tomasz, any ideas why we didn't merge this fall-back patch? IIRC we had some related patches that looked a bit hacky, but this looks good as-is. Nit: use "char* driver_name" instead of "bool swrast". > 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. > IIRC control nodes are gone upstream. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
