On Wed, Jan 13, 2016 at 12:54 PM, Rob Herring <r...@kernel.org> wrote: > On Tue, Jan 12, 2016 at 8:06 PM, Chih-Wei Huang <cwhu...@android-x86.org> > wrote: >> 2016-01-13 6:29 GMT+08:00 Rob Herring <r...@kernel.org>: >>> On Tue, Jan 12, 2016 at 7:05 AM, Chih-Wei Huang <cwhu...@android-x86.org> >>> wrote: >>>> 2016-01-12 19:55 GMT+08:00 陈渝 <yuc...@mail.tsinghua.edu.cn>: >>>>> hi, Rob, Dave, Zhiwei: >>>>> Thank you all! >>>>> >>>>> Next I need to update other parts should be in the user level. >>>>> >>>>> I need to update drm_gralloc? Do I need to update drm_hwcomposer or >>>>> libdrm? >>>>> Are there any other things I need notice? >>>> >>>> libdrm in marshmallow-x86 is 2.4.66 which is newer enough >>>> to support it, I think. >>>> >>>> drm_hwcomposer is not been used in marshmallow-x86 yet. >>>> So don't worry about it. >>>> >>>> The keypoint is to implement the gralloc_drm_virgil3d.c. >>>> You may look at other gralloc_drm_*.c as examples. >>> >>> Nope, virgl is a pipe driver and support is already there for the most part. >> >> Rob, thank you very much for the input. >> It's the first time I heard the usage of >> AOSP's drm_gralloc & drm_hwcomposer from others. >> Great! >> >> Indeed we have tried to enable AOSP's drm_gralloc & drm_hwcomposer >> in the beginning of marshmallow-x86 porting but failed. > > How far did you get? > >> So we keep to use our implementation. >> (AOSP's drm_gralloc was forked from our lollipop-x86 branch >> since about Jan 2015) >> >> I'm excited to know you have succeeded to use them. >> Could you please guide us how to enable them correctly? > > Well, things are not completely working. I've got 1 device config > which can build for x86 or arm64 (any arch in theory) and runs on x86 > KVM, Dragonboard 410c or arm64 QEMU. x86 KVM seems to work the best. I > can boot and navigate around a bit until it dies. There's at least 2 > problems. > > After a little bit of navigating around I get errors like this from > virglrenderer: > vrend_set_single_sampler_view: context error reported 6 > "ndroid.contacts" Illegal handle 112 > vrend_set_single_sampler_view: context error reported 6 > "ndroid.contacts" Illegal handle 113 > vrend_set_single_sampler_view: context error reported 6 > "ndroid.contacts" Illegal handle 114 > vrend_set_single_sampler_view: context error reported 6 > "ndroid.contacts" Illegal handle 115 > vrend_set_single_sampler_view: context error reported 6 > "ndroid.contacts" Illegal handle 116 > vrend_set_single_sampler_view: context error reported 6 > "ndroid.contacts" Illegal handle 117 > vrend_set_single_sampler_view: context error reported 6 > "ndroid.contacts" Illegal handle 118 > vrend_set_framebuffer_state: context error reported 5 > "ndroid.systemui" Illegal surface 63 > > Usually the screen get flipped and drawn in about 1/4 of the original > screen size after these errors. I can capture a screenshot if > interested.
I wonder a bit if refcnt'ing imbalance or something like that.. accidentally free'ing the last reference to buffer, and then numeric handle getting re-used on a different unrelated buffer (for example) can cause all sorts of fun. > The 2nd problem is the screen fade to black shader program crashes on > linking. Seems to have a NULL function name from the stack trace, but > I've not debugged it further. This triggers whenever the screen off > timeout triggers. iirc, android-x86 had something to comment out this shader. I do remember it causing a segfault in mesa in the shader compiler. I did attempt to reproduce this w/ same shader in a test program (where I could debug w/ sane gdb env, no java, etc), but no luck. (If anyone knows how to apitrace android "java stuff".. that might be a way to get something I could debug.) I can't find the link to the android-x86 patch anymore, since the git servers moved (and not even sure if that still applies to more recent android) BR, -R > Freedreno seems to have some additional problem I haven't fully characterized. > >> Any necessary changes? > > Yes, my changes are all pushed into my github acct[1]. Instructions > are here[2]. The changes are largely build fixes, virtio-gpu support, > freedreno/dmabuf support from Rob Clark's tree, and hacks around > issues I've found. > >> Especially, is the vanilla kernel 4.4 ready to use them? > > What I'm using is pretty close to stock 4.4[3]. There's a couple of > Android patches and some virtio-gpu related changes. The virtio-gpu > changes are mainly adding atomic support for virtio-gpu. There's some > others for fb mmap and panning support as well. > > Rob > > [1] https://github.com/robherring?tab=repositories > [2] > https://github.com/robherring/generic_device/wiki/Android-with-DRM-mesa-graphics > [3] > https://git.linaro.org/people/rob.herring/linux.git/shortlog/refs/heads/android-4.4 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
