Further Testing Shows More Hope For ATI Gallium3D

[rapsure]

I tested the 2.6.38-rc1 kernel with a mesa snapshot, and snapshot of the xf86-video-ati drivers on a ATI Radeon X800XL and the performance for the gallium is about half of what the gallium performance for the X1800XT card. Essentially the card performs according to what I would expect for its class. I did enjoy the performance boost because from the 2.6.37 kernel and the mesa-7.10 the performance in some tasks doubled. For all tasks the performance has increased substantially having the page-flip. Nexius doesn't render correctly though and there are other regressions and so I'll wait until mesa-7.11 is released.

[Melcar]

Got a chance to test it a bit yesterday evening. Wow, is all I can write. This 200M isn´t very fast, so any boost in performance is rather noticeable. I could play some games okayishly and even some WINE was acceptable, but now with the new kernel and the latest driver packages from xorg-edgers I can play just as well as I could under Windows. Temple of Elemental Evil with WINE was so-so before on a small 800x600 window, but now I can play it with respectable performance at my screen´s native 1280x768. Vampire The Masquerade Bloodlines is also fast, though I now get weird graphical glitches. One thing that is bothering me considerably is artifacts all over my standard 2D desktop. Turning on composition makes them go away, but that isn´t really a viable work-around for me.

[Beiruty]

I also regressing for lightsmark, most scenes are just black.

[Paulie889]

I also regressing for lightsmark, most scenes are just black.

You should bisect and report a bug at fdo bugzilla. BTW I know about one Lightsmark regression, see https://bugs.freedesktop.org/show_bug.cgi?id=31830 , however there are only some shadows broken here (RV530), not black scenes.

[marek]

I think the performance of r300g may go even higher. There are still some optimizations to be done that should further improve it, like:
- Some state tracker optimizations to make the game Torcs faster. (being worked on)
- Rewriting register allocation in the compiler for it to work with flow control. I am sure this will speed up Lightsmark. (not started)
- Finishing up Hyper-Z support, which is fast Z clear + Zbuffer compression + hierarchical Zbuffering. I am sure this will speed up openarena. (mostly done)

[PGHammer]

Got a chance to test it a bit yesterday evening. Wow, is all I can write. This 200M isn´t very fast, so any boost in performance is rather noticeable. I could play some games okayishly and even some WINE was acceptable, but now with the new kernel and the latest driver packages from xorg-edgers I can play just as well as I could under Windows. Temple of Elemental Evil with WINE was so-so before on a small 800x600 window, but now I can play it with respectable performance at my screen´s native 1280x768. Vampire The Masquerade Bloodlines is also fast, though I now get weird graphical glitches. One thing that is bothering me considerably is artifacts all over my standard 2D desktop. Turning on composition makes them go away, but that isn´t really a viable work-around for me.

I hadn't seen your post until now (24 January 2010 about 0136 EST), but except for the hardware specifics, I have nothing but praise for the latest kernel and latest X/Mesa as things stand; and I'm NOT running (K)Ubuntu, for once.

I'm running openSuSE 11.4 x64 MS5 (of 6) with the Factory X repo, latest kernel from kernel.org (2.6.38-rc2, which I compiled on Saturday) and updated KDE (4.6 RC2; installed less than an hour ago).

The CPU: Intel Celeron DC E1200
The GPU: Visiontek AMD HD5450 PCIe 512 MB DDR3 (Mobility hardware in a desktop fanless suit)

Considering such low-end hardware (basically, I'm running an over-monitored laptop-equivalent; my display is 23" Acer H233H being driven @ 1920x1080), getting hardware acceleration would be (and normally is) quite impossible. However, the combo of the latest kernel and latest X fixes both woes.

2.6.38-rc2 supports kernel-modesetting for *all* graphics hardware by default (no change from 2.6.37; however, a major change from 2.6.36 and earlier, which still lacked KMS for newer AMD GPUs).

Latest X/Mesa (7.6 of X.org and 7.10 of Mesa) *does* implement the new DRI2 for AMD HD5xxx and earlier GPU hardware.

One area that I have had decided issues with (due largely to lack of hardware acceleration) when it comes to FOSS has to do with (quite naturally) Flash performance in Web browsers in general, and in Firefox in particular. Let's face facts - when it comes to the Web, it pretty much runs on Flash. While Flash itself is supported pretty good on FOSS, without hardware acceleration, Flash performance on FOSS bites, and bites badly. However, with the new TCL DRI2 support present and accounted for, not only has Flash performance improved, it is now *at least* the equal of Flash performance in Firefox for Windows (if not better in some cases, due to differences in browser implementation between Firefox on Linux and Firefox on Windows).

That's right - even on wimpy hardware, Flash performance no longer need bite.

Will surprises never cease (I hope).

[oibaf]

I think the performance of r300g may go even higher. There are still some optimizations to be done that should further improve it, like:
- Some state tracker optimizations to make the game Torcs faster. (being worked on)
- Rewriting register allocation in the compiler for it to work with flow control. I am sure this will speed up Lightsmark. (not started)
- Finishing up Hyper-Z support, which is fast Z clear + Zbuffer compression + hierarchical Zbuffering. I am sure this will speed up openarena. (mostly done)

Thanks Marek, you are really doing a great work on fixing and improving the r300g driver and mesa

Also, what about this in r300_screen.c:

case PIPE_CAP_DEPTH_CLAMP: /* XXX implemented, but breaks Regnum Online */

Is it still broken? Will it improve performance if correctly enabled?

There is also a missing CAP in r300g:

r300: Warning: Unknown CAP 43 in get_param.

[marek]

Is it still broken? Will it improve performance if correctly enabled?

Yes, it still is broken and it wouldn't improve performance.

[Prescience500]

It's looking like 300g is going to eventually outperform the proprietary driver. Can 600g do the same before...say 900g is needed and support for the new graphics cards are dropped in the new versions of the proprietary drivers?

[oibaf]

This CAP is also missing:

r300: Warning: Unknown CAP 36 in get_param.

PIPE_CAP_ARRAY_TEXTURES