Open kozross opened 6 years ago
As I know, there're several ARM chip have been tested with this driver: Allwinner H3, A20, RK3xxx. And now the driver is in an early staging that can only support some simple application like: https://github.com/yuq/gfx/tree/master/gbm-surface
As xserver and wayland, this driver is not able to support yet.
brace yourself the winter is coming
and we all waiting for something GPUseful on ARM SoC's, please make it yuq, you're our only hope
Thanks for your encouragement, not only me, some other guys like Erico and Icenowy are also working on this driver. Hope we can make it finally.
Hello @yuq! Is there some kind of a rodamap/ list of things that have to be done/fixed so that we can contribute?
Hi, I created a wiki page that briefly describe the status and TODO of this project: https://github.com/yuq/mesa-lima/wiki I'll update it when something changes in the future.
@yuq, I noticed that you are working over a mainline kernel version for the H3. Do you reckon if it is OK to use a 3.4 kernel tree for the A20?
It's not OK for using such an old kernel for lima dev. Because the kernel driver uses various kernel interfaces like DRM, DMA_BUF which are quite different between 4.13 and 3.4 kernel.
@yuq, what flags are you building with? I did it with: --enable-opengl --enable-gles2 --enable-gles1 --disable-glx --enable-egl --enable-gallium-egl --with-egl-platforms=drm --with-gallium-drivers=lima --without-dri-drivers
Mine is: --with-gallium-drivers=lima --with-dri-drivers= --with-egl-platforms=drm,x11 --disable-xvmc --disable-vdpau --enable-debug
@yuq, do you install it in the default path (/usr/local) or somewhere else?
P.S. I have a problem while compiling the off-screen rendering example - https://pastebin.com/cVz5cjzS But it's highly possible that the problem comes from my cross-compiled mesa, so now i'm setting up an ARM chroot... It smells like bad linking to me
I cross compile the kernel, but for mesa and gbm-surface, I compile them on the board natively (install to /usr/local). Another thing is you need to install any required lib on the board by mesa, like libdrm. From the log, you may need a newer libdrm on the board. I just use the latest libdrm master and compile/install on the board natively.
That's what I am also doing, but the board is really slow, and because of libtool's messed up "prefix" installing a cross-compiled (on pc) Mesa to the board is tricky; i think that going with a QEMU chroot is an option - https://gist.github.com/mikkeloscar/a85b08881c437795c1b9; I hope that I'll soon find a way to compile everything on a x86_64 host and post the results here :D the Allwinner boards are just too slow..
I hope that I'll soon find a way to compile everything on a x86_64 host and post the results here
I am cross compiling the entire system using Buildroot https://buildroot.org/ , I just made a trivial modification to the mesa3d recipe to also include an option for lima. I use the _OVERRIDE_SRCDIR feature (https://buildroot.org/downloads/manual/manual.html#_using_buildroot_during_development) to keep a local git clone of the relevant repositories (linux-lima, mesa-lima) so that this source is used instead of the upstream one for my lima builds. Using nfs as the root filesystem also helps so that newly built files can be just copied over to a local directory and they will show up on the board without re-flashing.
if there is interest I can push a "buildroot-lima" development repository to my github with these changes and my current configs so that people can just clone it and run a couple of commands to generate a cross compiled full image. I can only provide tested configs for Cubieboard2 (A20) and NanoPi M1 (H3) though since these are my test targets now.
@enunes That would be cool
For completenes sake or interested people, I've gone the complete opposite way. As my whole environment (including the boards) is Debian based, I've integrated the lima work into the Debian mesa packaging so I can simply do a "dpkg-buildpackage" on the source. (https://github.com/mmind/mesa-lima)
I have pushed my Buildroot "extension" to github, along with some quick start instructions and development workflow for Buildroot: https://github.com/enunes/buildroot-external-lima It is what I have been using so far. This will also cross-compile the gbm-surface and gbm-bo-test examples that we have been using out of the box. @vakkov if you are interested, give it a try. @yuq if you feel like it is interesting, you can add a link to this to the wiki too as how to use it in a cross-compiled setup.
@enunes thanks, will give it a try; I ended up doing the same as @mmind since I am also Debian-based; my problem is that for some I can't have the x11 and Co armhf (the multiarch method) dependency packages installed on the host; @mmind, are you just doing "dpkg-buildpackage -aarmhf" on your x86/x64 machine? I ended up doing some weird linking to an armhf chroot so that I can use arm-linux-gnueabihf-gcc with all the threads of my cpu form my host OS ... ugly
@vakkov actually I'm also just compiling natively on one of the beefier Rockchip boards in my boardfarm.
@mmind and how much time does it need to build the whole package?
@vakkov on my rk3288, around one hour
There is nice entry on VC04 wiki, how to test mesa without breaking existing distribution https://github.com/anholt/mesa/wiki/Building-Mesa-for-VC4 So it should be possible to have/test binary and open source drivers on the same image.
Can anybody update me with usablility current mesa-lima? I built mesa-lima/linux-mali accordingly to https://github.com/yuq/mesa-lima/wiki booting my s905w shows in dmesg lima is loaded. Also I see /dev/dri0 for meson-dp and /dev/dri1 for lima gpu but xorg says: https://pastebin.com/A5iqDA9k Is this expected or I miss something?
This place is abandoned. Development moved to https://gitlab.freedesktop.org/lima
ok thx I put my question in gitlab: https://gitlab.freedesktop.org/lima/mesa/issues/69
How complete and/or usable is this driver? Would I be able to compile it for an existing ARM device running something Linux-based and have it work?