ATI R600 Gallium3D Driver Continues Advancing

[nanonyme]

Note that it's possible that Fedora not using TLS might slow me down a bit. Dunno whether there's a significant penalty. (I'm not using SELinux)
Will try with newer stuff soon and recompiling things with TLS a little later.

[rohcQaH]

The excessive memory consumption I'm seeing with hl2 is probably something with wine.

hmmmmm.. maybe. maybe not.

Take a look at this file (current revision) and search for r600_delete_ps_shader.

wine has some quirks where it's frequently re-creating shaders, so I'd imagine that this leak will hit harder in wine games.

At least it's a known leak.

[pingufunkybeat]

OK, I've tried r600g.

In my tests, it is 2x slower than r600c in openarena. I get solid 60fps with classic, struggle to get solid 30fps with gallium. This is with vsync, so only rough numbers.

KWin bails out complaining that the effects are too slow. I didn't try disabling the checks. It works fine with classic.

Still, nice progress. I haven't noticed any rendering artifacts or lockups, so things re progressing nicely.

[PGHammer]

I "imagine" development is going forward as indicated by mesa git log, http://cgit.freedesktop.org/mesa/mes...t=grep&q=r600g



My distro does not provide binary packages... and I do eselect mesa set r600 classic when I'm done checking out how the current r600g is doing.



The way FOSS works hasn't really changed much the last 15 years, but I am glad I could help you release all that supressed anger.

While R600c leads now, I honestly don't expect it to maintain that lead for long, if the performance gains by R300g are anything to go by. R300g is now actually starting to show up in distribution testing cyclss (and not just Ubuntu, where it has completely replaced R300c, but Debian/Arch/Gentoowide). However, there have been other changes in the Linux graphics firmament (Flash plugin behavior in particular), and if you have hardware that changes over to R300g for Xorg support (basically, Radeon 9200 through the X1K series) you will have no idea whether to yell at Tungsten (who did a ton of contribution work toward the new server) or Adobe (however, because of issues with Flash that are not unique to Linux, I feel on safer ground yelling at Adobe for the sorry state of their Flash plugin).

As I stated earlier, some distributions have already swapped out R300c for R300g during their test cycle; Ubuntu is the most well-known, with Maverick Meerkat kicking 10.10 RC out the door this week. I have two GPUs that I've been throwing at the new server - an AMD AIW 9700 Pro and an X1650 Pro, both in AGP flavor. The test platform otherwise is a P4 2.4 with 512 MB of DDRr333, 40 GB WD PATA HDD, and, as staed, Kubuntu 10.10 RC. From straightforward seat-of-pants observations, R300g loses nothing peerformancewise compared to R300c, and is actually more stable than R300c driving KDE (which, in the 4.5.1 iteration included with Maverick Meerkat, places more demands on Xorg than older versions of KDE); this would actually make KDE 4.5.x a viable option with legacy AMD hardware, which has not really been the case (except among masochistic types due to both performance and stability issues).

Because R300g is a drop-in replacement, as long as you have Xorg 1.9 and Mesa 7.9 or later, if your GPU is covered by this server, you need do nothing in the way of post-change fiddling, which ususally isn't the case with a point release of Xorg, let alone point releases of both Xorg and Mesa, coming down the pike.

[tormod]

and not just Ubuntu, where it has completely replaced R300c

As I stated earlier, some distributions have already swapped out R300c for R300g during their test cycle; Ubuntu is the most well-known, with Maverick Meerkat kicking 10.10 RC out the door this week.

I believe this is all wrong. Quoting from the maverick mesa debian/rules file:

# We should switch to r300g soon, but it won't support UMS.  Stick
# with r300c for now

R300g loses nothing peerformancewise compared to R300c, and is actually more stable than R300c

Maybe for KMS, but UMS (classic) still beats the pants off KMS (classic or gallium) in many cases. And some users need UMS because of KMS bugs.

[droidhacker]

In my tests, it is 2x slower than r600c in openarena.

Would you mind explaining the concept of "2x slower"? Because "slowness" is not a measurable metric that you can multiply.

I suggest you re-encode that brainfart in proper fractions. I.e. "1/2 speed".

[darkbasic]

In my tests, it does not work at all

[PGHammer]

I believe this is all wrong. Quoting from the maverick mesa debian/rules file:

# We should switch to r300g soon, but it won't support UMS.  Stick
# with r300c for now

Maybe for KMS, but UMS (classic) still beats the pants off KMS (classic or gallium) in many cases. And some users need UMS because of KMS bugs.

What KMS bugs?

The only bugs I've ever seen in KMS have been related to something outside of Xorg server control (such as kernel issues prior to 2.6.34). The classic *radeon* Xorg server has supported KMS since Xorg 1.8, and that includes all the way back to the original (R100/Radeon 7000, if you want to be picky); this server is still used by hardware too old to be supported by R300c/g or R600c/g. I'm using an AMD Radeon 7500 (an R100/RV200 part) in Kubuntu 10.10 RC, where KMS is enabled by default (kernel is 2.6.35-22), and I haven't had a lick of trouble with KMS, despite the ancient hardware. The issue may be present in applications I don't use (such as WINE); however, even WINE is a kludge.

I won't say that there *are* no bugs still; however, I personally haven't experienced any that are related directly to the FOSS AMD server efforts in any way/shape/form in the aplications I use.

Therefore, the question stands.

[pingufunkybeat]

Would you mind explaining the concept of "2x slower"? Because "slowness" is not a measurable metric that you can multiply.

I suggest you re-encode that brainfart in proper fractions. I.e. "1/2 speed".

Twice as slow is half as fast. Measured in terms of fps in open arena.

Now go get laid, you stuck up cunt.

[PGHammer]

I don't really believe they be grateful. Your average Ubuntu user expects his stuff to work and doesn't know much about what Gallium3D is.

It still depends on where the user is coming from (as is the case with any new/upgrading user). Despite their reputation for it-largely-just-works, 'buntu has been known to take steps that no other Debian-based distribution (including rolling releases such as sid) is willing to take (such as working with AMD to gain customized Linux Catalyst driver releases, and going with newer kernels, such as 2.6.35-22 in the Maverick Meerkat RC). It is for this reason that I have added an older P4 to my test platform regime in order to observe the state of R300g (which has actually replaced R300c in Maverick Meerkat, and is available as a drop-in replacement for Lucid Lynx via both xorg-edgers and x-swat PPAs). My Evergreen_accel testbox needs a motherboard swap (BIOS in the current mobo has locked up); further, xorg-edgers has been having issues with compiles from this branch (this is something I've observed both prior to and since my meltdown), so I am taking this look in the meantime. I have noticed that R300g is more stable than R300c, especially considering that KMS is now enabled by default in Maverick, and under far heavier loads than the older R300c/UMS combination (even with UMS and R300c, KDE was largely for masochists; however, KDE is now actually usable, KMS and all, on anything driven by R300g).

It is also why I asked the question earlier of another poster in this thread that complained about bugs in KMS. Other than issues relating entirely to older kernels (anything older than 2.6.34 has known issues supporting KMS, and that is regardless of distribution), I have not seen any (either in posts in various fora, here, or personal observation). I want documentation/bug reports; otherwise, I have to take such comments with a large saltmine from Siberia.