Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Completeness and usability question #3

Open
kozross opened this issue Oct 10, 2017 · 25 comments
Open

Completeness and usability question #3

kozross opened this issue Oct 10, 2017 · 25 comments

Comments

@kozross
Copy link

kozross commented Oct 10, 2017

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?

@yuq
Copy link
Owner

yuq commented Oct 11, 2017

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.

@onoraba
Copy link

onoraba commented Nov 8, 2017

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

@yuq
Copy link
Owner

yuq commented Nov 9, 2017

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.

@vakkov
Copy link

vakkov commented Nov 12, 2017

Hello @yuq!
Is there some kind of a rodamap/ list of things that have to be done/fixed so that we can contribute?

@yuq
Copy link
Owner

yuq commented Nov 13, 2017

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.

@vakkov
Copy link

vakkov commented Nov 13, 2017

@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?

@yuq
Copy link
Owner

yuq commented Nov 13, 2017

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.

@vakkov
Copy link

vakkov commented Nov 15, 2017

@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

@yuq
Copy link
Owner

yuq commented Nov 16, 2017

Mine is:
--with-gallium-drivers=lima --with-dri-drivers= --with-egl-platforms=drm,x11 --disable-xvmc --disable-vdpau --enable-debug

@vakkov
Copy link

vakkov commented Nov 16, 2017

@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

@yuq
Copy link
Owner

yuq commented Nov 16, 2017

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.

@vakkov
Copy link

vakkov commented Nov 16, 2017

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..

@enunes
Copy link
Contributor

enunes commented Nov 16, 2017

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.

@enunes
Copy link
Contributor

enunes commented Nov 16, 2017

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.

@vakkov
Copy link

vakkov commented Nov 16, 2017

@enunes That would be cool

@mmind
Copy link
Contributor

mmind commented Nov 18, 2017

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)

@enunes
Copy link
Contributor

enunes commented Nov 18, 2017

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.

@vakkov
Copy link

vakkov commented Nov 18, 2017

@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

@mmind
Copy link
Contributor

mmind commented Nov 18, 2017

@vakkov actually I'm also just compiling natively on one of the beefier Rockchip boards in my boardfarm.

@vakkov
Copy link

vakkov commented Nov 18, 2017

@mmind and how much time does it need to build the whole package?

@mmind
Copy link
Contributor

mmind commented Nov 18, 2017

@vakkov on my rk3288, around one hour

@PabloPL
Copy link
Contributor

PabloPL commented Dec 7, 2017

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.

@warpme
Copy link

warpme commented Nov 20, 2018

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?

@chelobaka
Copy link

This place is abandoned. Development moved to https://gitlab.freedesktop.org/lima

@warpme
Copy link

warpme commented Nov 20, 2018

ok thx
I put my question in gitlab: https://gitlab.freedesktop.org/lima/mesa/issues/69

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants