You are viewing libv

LIBV Intentionally Breaks Videodrivers - Hey ARM! [entries|archive|friends|userinfo]
Luc Verhaegen

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

Hey ARM! [Feb. 13th, 2013|05:13 am]
Previous Entry Add to Memories Share Next Entry
[Tags|, , , , , , , , ]
[Current Location |Rumpelkammer]
[mood |Happy]
[music |Pixies - Surfer Rosa - River Euphrates]

Quake 3 Arena code.

I pushed out the Quake 3 Arena code used for demoing limare and for benchmarking.

You can build it on your linux-sunxi with
    make ARCH=arm

or, for the limare version (which will not build without the matching limare driver, which i haven't pushed out yet :))
    make ARCH=arm USE_LIMARE=1

for the GLESv2 version (with the broken lamps due to missing alphatest):
    make ARCH=arm USE_GLES2=1

Get a full Quake 3 Arena version first though, and stick all the paks in ~/ioquake3/baseq3. Add this to demofour.cfg in the same directory:
    cg_drawfps 1
    timedemo 1
    set demodone  "quit"
    set demoloop1 "demo four; set nextdemo vstr demodone"
    vstr demoloop1

To run the timedemo then run the quake binary with +exec demofour.cfg

For your own reverse engineering purposes, to build the GLESv1 version with logging included, edit code/egl/egl_glimp.c, and remove the // before:
    //#define QGL_LOG_GL_CALLS 1

But be aware, you are not free to spread that dumped data. That is ID Software data, albeit in a raw form.

I'd be much obliged if anyone hacks up input support, or re-adds sound. Or even adds the missing GLES2 shaders (color as a uniform for instance). That would make this code playable from the console, and should make it easier for me to provide playable limare code.

As you all can see, we have nothing to hide. The relevant differences between GLES1 and limare is in the GL implementation layer. I did shortcut vertex counting, this to ease logging, but this only has limited effect on CPU usage. The lesser CPU usage of limare is not significant or interesting as we do less checking than a full driver anyway. In simpler tests (rotating cubes), our scheduling results in a much higher CPU usage though (like 50% more, from 10% to 15% :)), even if we are not significantly faster. As said in my previous, i am not sure yet whether to keep this, or to find some improvements. Further tests, on much more powerful hardware, will tell.

Connors Compiler Work.

Connor had a massive motivation boost from FOSDEM (and did not suffer from the bug that was going round which so many of us in the last week). Earl from zaReason is sending him an A13 tablet, which should spur him on even further.

He has been coding like a madman, and he is now close to being able to compile the relatively simple shaders used in the Quake 3 Arena demo. He still has to manually convert the ESSL of the vertex shader to his own GP_IR first though, but that's already massive progress which gets us very close to our goals.

I am going to add MBS loading (Mali Binary Shader format) to limare to be able to forgo the binary compiler and load pre-compiled shaders into our programs. Since MBS is also spit out by the open-gpu-tools, we can then distribute our own compiled MBS files directly, and provide a fully open source Q3A implementation on mali.

How cool is that!

The very near future.

With my post purely about Q3A and its numbers, the reactions were rather strange. Seems like a lot of people were hung up exclusively on us being only 2% faster or because we were using this "ancient" game. The blog entry itself explained fully why this ancient game was actually a very good choice, yet only very few read it. Very few realized what a massive milestone an almost pixel-perfect Quake 3 Arena is for a reverse engineered driver.

As for performance... When i started investigating the mali, i had postulated that we would be happy to have only 75% of the performance of the binary driver. I assumed that, even with performance per watt being mighty important in the mobile space, 75% was the threshold at which the advantages of an open source driver would outweight the loss of performance. This would then lead to only ARMs big partners would end up shipping ARMs own binaries. And for projects like CyanogenMod and proper linux distributions there would be no question about what to ship.

With Q3A, and with the various rotating cubes, we now have proven that we can have a 100% match in performance. Sometimes we can even beat performance. All of this is general, no Q3A specific tricks here!

This is absolutely unique, and is beyond even the wildest dreams of a developer of any reverse engineered driver.

Absolutely nothing stops us now from delivering an open source driver that broadly matches the binary driver in performance! And this is exactly what we will be doing next!

Hey ARM!

We are not going away, we are here to stay. We cannot be silenced or stopped anymore, and we are becoming harder and harder to ignore.

It is only a matter of time before we produce an open source graphics driver stack which rivals your binary in performance. And that time is measured in weeks and months now. The requests from your own customers, for support for this open source stack, will only grow louder and louder.

So please, stop fighting us. Embrace us. Work with us. Your customers and shareholders will love you for it.

-- libv.

From: (Anonymous)
2013-02-13 07:15 am (UTC)


Keep up the good work!
[User Picture]From: Michal Lazo
2013-02-13 08:03 am (UTC)


I would like to know how many patents are really used in mali binary drivers.
I can understand if they do all checks in binary drivers they don't need any checks in hw part
But now we can get gpu to unexpected state and that is something that arm don't want.
Look at nvidia and all problems with their drivers

but still
go for open source drivers
From: (Anonymous)
2013-02-13 09:53 am (UTC)


And exactly how hard is ARM really fighting the OSS community? Or are they just making zero effort for open source drivers?
[User Picture]From: nunfetishist
2013-02-14 10:05 am (UTC)


The issue is less "which ARM patents are used" in the binary drivers, but more "which patents of other people's have ARM inadvertently used in the binary drivers". They tend to keep these drives closed not because they're super-secret and magical, but to make it more difficult for competitors to sue them.
[User Picture]From: Michal Lazo
2013-02-14 12:31 pm (UTC)


It is same with nVIdia an AMD :)
From: (Anonymous)
2013-02-13 08:09 am (UTC)


Luc this is great news and I'm so looking forward to running Linux with full 3D on Mali. Question though, is there anything we can help with ? I'm a programmer but I'm really not familiar with the 3D stuff you're talking about here.
If anyone needs it I can donate a RK3066 chip. This has a quad core Mali from what I understand.
From: (Anonymous)
2013-02-13 08:19 am (UTC)


Really really interesting....
hope to see the limare driver soon in gitorious, and some instructions on how to use / test, binary driver is so crappy on sunxi...
From: (Anonymous)
2013-02-13 12:53 pm (UTC)


Good work!!!! Thank you!
From: (Anonymous)
2013-02-13 03:39 pm (UTC)


This is the first ARM graphic driver to promise real OS alternatives from Android.
Congratulations LUC. My best wishes.

I will choose ARM+Mali in my next MiniPC, either RK3xxx or Axx.
Sadly high performance Allwinner CPU choose VR SGX :(
From: ext_1649310
2013-02-13 03:40 pm (UTC)


This is the first ARM graphic driver to promise real OS alternatives from Android.
Congratulations LUC. My best wishes.

I will choose ARM+Mali in my next MiniPC, either RK3xxx or Axx.
Sadly high performance Allwinner CPU choose VR SGX :(