Log in

No account? Create an account
The lima mesa driver runs es2gears. - LIBV Intentionally Breaks Videodrivers [entries|archive|friends|userinfo]
Luc Verhaegen

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

The lima mesa driver runs es2gears. [Sep. 4th, 2013|12:57 am]
Luc Verhaegen
[Tags|, , , , , , , , ]
[Current Location |Rumpelkammer]
[mood |melancholic]
[music |Lemon Jelly - Ramblin' man]


Progress is slow but steady on the lima mesa driver, mostly because I am not giving lima as much time as I should. I now have working attributes, uniforms, vertex buffers and even some state is being set correctly. Enough to run es2gears. Here is the video on youtube, there is an older capture with a rotating smoothed cube as well.

This lima mesa driver uses the old-school (but contrary to popular belief, definitely not deprecated) mesa infrastructure, which, with surprisingly little work, allows me to run the mali binary drivers compiler, and allows me to build the lima driver externally. Using the binary compiler would not be possible from gallium, and with some improvements to the (intel developed, and thus intel focused) mesa glsl compiler, it seems that we might have a potent compiler for the mali ISAs as well. This way, the task of bringing up mesa on mali is nicely split, and we will be able to debug the command stream work separately from the shader compiler. I believe that we did lose the ability to run gles1 programs until Connors open-gpu-tools is hooked up to the mesa glsl compiler. This is just a small price to pay, in comparison to the size of the hurdle to take when doing everything in one go.

We are running es2gears at 130fps on the A10, and 310fps on the Exynos for a 300x300 render. Resizing is currently broken, or rather not implemented. I will need to split up the PLBU command stream to be able to do that properly under DRI2 (where resizes happen behind the mesa drivers back). The way DRI2, mesa and the sunxifb X driver now work together also means that i have to wait for jobs to finish (and then usleep for good measure), so there is a lot of potential for speed-up as well. I am not sure yet how things will have to be hacked to keep X from copying the region before rendering is absolutely done, i guess that we will have to hack something into UMP and the sunxifb driver. But a solution will be found, and we should see around a 50% increase in framerate from that, and even much much more if we manage to use overlays. Since we are in control of all the code now, we should theoretically be able to squeeze every last bit of performance out of the GPU, a luxury not offered to the users of the binary X11 driver.

I will now continue implementing textures, so that i can run all the limare egl tests. After that i will clean up the code and push it out. This will include patches to common mesa versions (and mesa packages) to allow building lima against them. Resizing and job interleaving will have to wait until after that, so keep your eyes peeled on this space :)

10 years in.

A few weeks ago, it was the 10th anniversary of my first contribution to X (a small display fix to the via driver). I cannot state that this anniversary was a happy event.

Looking back, I cannot believe that i once thought that in open source software, code, design and doing The Right Thing, both technically and morally, were paramount. Open source software is about power, politics, corporate affiliation, and loads and loads of noise. Noise and misinformation always wins over code, no matter how good this code is or how hard you work at it. I have had to learn this several times over.

This is especially true in the case of forks. Not the git clone variation, but the loud, aggressive and very detrimental community kind. While often technical reasons are claimed to be the cause, this is never ever the case. It always is about politics and power. And code always suffers as a result, and this suffering is never a short term thing, especially on big forks. See, a fork always means a big stink, a lot of noise, and a power vacuum, and this attracts a certain kind of individual. These personalities form the basis of the new community together with those who instigated or accelerated the fork. Good code simply has no chance in such an environment. Bad code and bad design tends to hang around for a long long time, and tends to influence (read, limit) the thinking of any new blood that turns up. On top of that, the bad mentality also tends to linger for many many years. Politics and noise continues to take precedence over code and design, for the foreseeable future.

The only thing to do in case of a fork, is to go play somewhere else, somewhere where a major fork hasn't taken place. If you don't, or if you do not go far enough, you will see your work impacted, especially if you are not willing to let yourself be limited by the existing mentality and powerbalance.

Now if only i wasn't such a stubborn bastard ;)

From: (Anonymous)
2013-09-04 08:00 am (UTC)
You are plain awsome, Luc!
(Reply) (Thread)
From: (Anonymous)
2013-09-04 10:32 am (UTC)
Congrats, dude, this is great news ;-)
(Reply) (Thread)
From: (Anonymous)
2013-09-04 11:26 am (UTC)
Will this result in patches to Mesa master? I would love to have Mali, mainstream support along Freedreno. There are lot of cheam Mali chips (Allwinner) that are crying for opensource support.
(Reply) (Thread)
[User Picture]From: libv
2013-09-04 11:51 am (UTC)
Yes, there are patches to mesa, and there will be further ones, and i will attempt to upstream them.

You will however be able to use the lima mesa driver with limited changes to your installed system. You will (hopefully - depending on how we fix the job interleaving) not need to build or install the latest kernel, mesa or xserver. You will however need to rebuild mesa, or install the provided packages, to be able to build the lima driver against it.
(Reply) (Parent) (Thread)
From: (Anonymous)
2013-11-02 09:16 pm (UTC)
Could you show us how to do this with links etc? This would be a big help! I'm sure many more people would be able experiment and do some good demos. I've got a load of GLES2 demos on the Raspberry Pi and would like to port it to Mali. Great Work!
(Reply) (Parent) (Thread)
From: (Anonymous)
2013-09-04 01:01 pm (UTC)
Cool stuff but I have a question. You mentioned various problems with this driver and X. What if I don't need X and just want Wayland support ? Will it be possible ? Wouldn't that be easier, at least in theory ?
Things seem to be moving towards Wayland slowly but surely and with Jolla recently announcing Wayland only for their devices I'm very interested in a port of it ( or just nemo and Mer ) using lima instead of that crappy binary driver that Mali has.
(Reply) (Thread)
[User Picture]From: libv
2013-09-04 01:30 pm (UTC)
This is all open source software, at least it will be once i clean up the current mess and push it out. It should be possible to make it work with just about any windowing system.

I rather doubt that the DRI2 problems i currently have will magically get solved by wayland though.

Edited at 2013-09-04 01:30 pm (UTC)
(Reply) (Parent) (Thread)
From: (Anonymous)
2013-09-04 01:37 pm (UTC)
DRI problems no, I've read a bit about it and from what I do understand about this for Wayland you need the 3D driver with DRI and KMS. You did however mention some problems with X and that's what I was talking about but hey I'm quite sure you know these things better than me, I was just curious.
And I think the 10 years since your first commit is something to celebrate and it should make you feel good. One of the best things we can do as people is to make a contribution, a positive one, and I think that you did and are still doing.
As someone who also makes contributions to open source I understand this and I thank you.
(Reply) (Parent) (Thread)
[User Picture]From: libv
2013-09-04 01:59 pm (UTC)
It's not really a problem with X, it's a problem with how everything in the open source graphics world is badly mashed together.

All other graphics drivers at the moment have pretty much everything in one place, intel even explicitly stopped using the 2d engine to be able to queue everything together and to do away with most synchronization. Mali is a core tied to many different display, 2d and media engines, and the shortsightedness of the x86 world or DRM is really starting to show here.
(Reply) (Parent) (Thread)
From: (Anonymous)
2013-09-07 09:24 pm (UTC)
Quote: "Now if only i wasn't such a stubborn bastard ;) "

I wished I had the skills to be like that. There have been various Projects I wanted to join or create. Whenever I was near reaching a personal milestone, everything went downhill. Something was changed by other people, something I depended on and everything I learned and worked for was of no importance anymore. That's pretty sad, considering I'm talking about a ten years timeframe myself. It always got worse. Today it seems pretty much every open-source project is broken by design and to make it work you have to join a club of self proclaimed elite and aquire the secret recipe in exchange for your soul..... or something.
(Reply) (Thread)