Quote:
But they're not 'video drivers'. They're graphics drivers. And like what was already stated, there are different kinds of graphics. I'm sure that since this is an ARM platform the graphics driver is proprietary. The devs likely can't do very much with them in terms of optimizations. That said, what they can do is see which version of the driver gives them the best general results. They'll probably go with that one.
If the driver is opensource of course, then that means everything I said doesn't apply in the least.
We actually have full control over the graphics stack - IPU (framebuffer), 3D GPU (OpenGLES2), 2D GPU (OpenVG).
The "Natty" Xorg driver is vastly improved technologically, as it does far more to get the best performance out of the chips and uses a different acceleration method which allows us to switch between Z430 (3D) and Z160 (2D) acceleration units "on the fly" (actually it's limited to doing it on driver start but, it is better than it was).
The problem is, while "better", it is entirely subjective as Steve mentioned. Benchmarking it shows some extremely good performance benefits, especially with the Z430 driver, but where the driver operates faster in Xv support, you would never notice (since a 24fps video will play at 24fps regardless of driver) and where on single op benchmarks it is several times faster, it is a rare day indeed that an application other than a benchmark pipelines single operations on single pixmap to see the same performances. So far the benefits are restricted to "it feels like it drags windows faster" and "X-Chat seems not to be so sticky". They are essentially not quantifiable improvements.
Assuming you could look inside the new driver (it's not released yet but it will probably be available as source when it is) and you will notice it does eviction of pixmaps from GPU to system memory, bilinear filtering on scaling, and uses a lot less CPU in the best cases but a lot more in others. It doesn't pipeline GPU accesses as well (as the acceleration API is basically stateless, where the libz160 API used currently has full knowledge of the current GPU context and writes a lot less to the GPU) but the way EXA works plays to our favor in that it doesn't really matter as there is a lot going on behind the scenes that is soaking up resources more than we lose. There is a balance to achieve which we believe we are actually achieving. A lot of work needs to get done though..
~
What is not quite as well controlled is the multimedia stack. It's really not ready to go out in our opinion.
The wait is entirely down to quality control right now. It would be stupid to ship it if it only played half the videos people want to play. We've had some successes, but also some dismal failures (playing an Ogg that came as standard with older Ubuntus, and several of the encodings available from BigBuckBunny.org act strangely).
Considering these are the first things people will test (I am not going to acknowledge the existence of anything but free Creative Commons-licensed media :) if some don't work then it's tantamount to it not working at all.