|The lima mesa driver runs es2gears.
||[Sep. 4th, 2013|12:57 am]
es2gears!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 ;)