A Big Comparison Of The AMD Catalyst, Mesa & Gallium3D Drive

[entermVet]

hi guys

hey. not sure if this is the right section

[smitty3268]

The drivers don't actually replace any application code, just a couple of system libraries (mostly to implement functionality that the underlying system can't handle yet, eg splitting drawing operations across multiple GPUs).

Catalyst AI is working on the linux drivers, though, right? That swaps out application shaders for what the driver says are equivalent more optimized shaders for the hardware, as i understand it. Not that these tests were shader heavy, anyway...

[bridgman]

I didn't think we had Catalyst AI on Linux, but I haven't looked for a long time.

I don't really know what Catalyst AI does (I kinda thought of it as a Windows-only thing), although you could argue that the optimization logic in any compiler is expected to replace sections of code with equivalent, but more efficient code wherever possible.

[RealNC]

I don't really know what Catalyst AI does (I kinda thought of it as a Windows-only thing)

It provides a nice slider and checkbox to look at

[smitty3268]

You may be right - the more i think about it, the more i think i remember it containing lots of application-specific code which is probably only really used for windows apps.

Anyway, i believe it does a little more than a traditional compiler is able to, actually swapping out entire shaders for others that maybe aren't quite the identical thing but that appear to be the same. It's been a while since i looked into it, though - way back when it was introduced on windows.

[liam]

Same here with the Quadro, mobile version of this chip (135NVS). I did manage to get tear-free video at some point, by stopping compiz and using VDPAU but the desktop remained tear-y. Performance sucked, too.

My experience has been that you can expect degrees of tearing with Xv being the worst. OGL has given me the best thus far (better than VDPAU), but it tears as well. My understanding is that this is an X issue and you only get rid of it when the ogl app has sole ownership of the display.
Regardless, I've yet to come across an output method that provides a reliably tear-free. OTOH, Gnome Shell appears tear-free to me, but my guess is that it really isn't, and it is just imperceptible.
Off-topic but there's a weird quirk I've come across with Splitted-Desktop's va-api/vdpau output in that it uses less cpu than a straight vdpau implementation

[liam]

Sorry, but as far as I can remember my linux experience when I ran Nvidia with nvidia drivers, I can't remember having seen any video tearing at all. The video quality was just clean.
But I'm talking of times when the Nvidia 6400 GTS was the board to have, which places us somewhere in 2004.
Perhaps since those old days has nvidia as much tearing as ATI do, but that's not what i've read so far from nvidia users.

Anyway, if the tearing is corrected with the 2011.1 ati drivers, it's old story now...

Obviously many factors are at play, but all I can tell you of is my experience. If you look around the Nvidia forums you'll find plenty of people griping about their 2D support. Also, while I don't think I am particularly sensitive to tearing, I also don't think I tend to imagine it. Again, my experience has been with both KDE and Gnome (though I use mostly the later), and with vlc/mplayer/totem/dragonPlayer. None have had consistent tear-free video regardless of whether it was ogl or vdpau/vaapi.

[BlackStar]

My experience has been that you can expect degrees of tearing with Xv being the worst. OGL has given me the best thus far (better than VDPAU), but it tears as well. My understanding is that this is an X issue and you only get rid of it when the ogl app has sole ownership of the display.
Regardless, I've yet to come across an output method that provides a reliably tear-free. OTOH, Gnome Shell appears tear-free to me, but my guess is that it really isn't, and it is just imperceptible.

Gnome Shell = Mutter = vsynced OpenGL app with sole ownership of the display (more or less). Compiz is similar but AFAIK uses a less reliable but faster method of syncing.

One quick test if you are using Compiz: set vsync to off (application defined) in your driver settings, enable vsync in Compiz and run the Compiz benchmark plugin. This causes Compiz to use regular vsync (glSwapInterval and glSwapBuffers) - do videos still tear then?

[jakubo]

hi, i havent read all the messages... yet id like to know if the catalyst driver has been run on multiple cpu cores (again)?
i think it was mentioned before, that theres no multicore support for oss drivers and therefore no real comparison possible. one would neet to know how the catalyst scales on multicore cpus.
can anyone comment on that, please?

[xeros]

fixed that for you o_O
actually im pretty impressed with some of the benchmarks.
1/4 of the catalyst performance is pretty good i think.
and afaik they havent really started doing any optimizations on the cards yet.
would have loved to see how the old catalyst drivers for r300 performed.
but thanks for the benchmarks michael!

Right, my impression of the performance with the r300g vs last working fglrx is simmilar in Nexuiz or Xonotic on Radeon 9600 and X300 but it needs to enable some performance improving features (not lowering picture quality though). Enabling GLSL shaders is one of the options that improves performance to something about twice as without it is most cases but the other options using more GLSL shaders should be used carefully to not drop performance too much.