Did Hell Just Freeze Over? Here's Evergreen On Gallium3D!

[nanonyme]

I really really hope the next gen hardware after Evergreen won't yet be anything dramatically different to program. Might allow the gap between releases and working drivers to grow shorter still.

[Hephasteus]

That's something we'll all have to figure out pretty quickly - not just for Evergreen, but if (hypothetically) we were working on another GPU generation it would be important to decide which tree we should use for working on *that* support as well.

(nuts, just rubbed my eye after cutting up scotch bonnet peppers... back later)

Capscasien is not good for eyes.

[monraaf]

Nice. It also runs foobillard. Without textures though, which makes it actually look better than with the broken texture thing in r600c . But it's too slow to be playable.

r300g is already faster than r300c, so I don't think that this is an architectural issue.

Do you have any benchmarks to back that up? Latest phoronix benchmarks I could find show r300g being significantly slower in some benchmarks. But these date back from two months ago, and a lot may have changed for the better since then, I don't know.

Perhaps phoronix could do another benchmark of r300c vs r300g sometime soon and take aways some of the worries people do have about Gallium performance.

[pingufunkybeat]

No, and I don't have an r300-r500 card to test either.

But it's the tenor of recent postings, anyway. For example, the menu in ETQW went from 1fps (r600c) to 30fps (r600g), according to Marek.

Of course, not all apps received such a boost, and some might be slower.

[whizse]

I think marek mentioned somewhere that the slowdown in Tremulous was fixed? It could just be wishful thinking on my part though...

r300g also have hyper-z now (with the right kernel) which might boost performance in some games.

[marek]

No, and I don't have an r300-r500 card to test either.

But it's the tenor of recent postings, anyway. For example, the menu in ETQW went from 1fps (r600c) to 30fps (r600g), according to Marek.

I was talking about r300c vs r300g. I don't know about r600c but I guess the texture upload is shared with r300c and older hardware, so in this case, r300g might beat r600c but I don't wanna speculate. Has anyone tested this?

I think marek mentioned somewhere that the slowdown in Tremulous was fixed? It could just be wishful thinking on my part though...

It was indeed fixed. Both r300c and r300g have the same speed in Tremulous here and Hyper-Z in r300g might further speed it up. I'd like to see some benchmarks from other people to be sure.

With r300g, we are already at the point where we don't know how to get more speed besides enabling Hyper-Z and besides doing some hard work in the compiler. If anyone knows, then I am all ears. Also the thing is that both r300g and r300c benefit from the performance improvements in the r300 compiler, so both drivers might become faster at the same time and comparing them against each other might not be very useful.

[pingufunkybeat]

Aaargh, yes, of course you were talking about r300c/g, I have no idea why I typed 600, probably habit.

[bridgman]

With r300g, we are already at the point where we don't know how to get more speed besides enabling Hyper-Z and besides doing some hard work in the compiler. If anyone knows, then I am all ears.

Is there any mechanism today that could be hacked to give a rough measure of GPU activity, say split between "busy", "flushing", and "idle" ? One of our suspicions was that the command submission/synchronization mechanism was not getting anywhere near as much pipelining between CPU and GPU activity as the proprietary drivers (although the proprietary drivers have it easier because they are multithreaded).

There used to be a general consensus that redundant setting of state in each DRI2 command buffer (no lock so you don't know if the values you set last time are still valid) accounted for a non-trivial chunk of performance, is that still believed or has the theory been debunked ? Generating the state packets may not take a lot of CPU time but executing them on the GPU could take longer. If it is still an issue, we could probably do some context save/restore tricks (or just move context management into the kernel entirely) to speed things up.

One trick we use for performance optimization is simulating "infinitely fast hardware", ie we see what kind of FPS we get if we are never waiting for GPU idle etc...

[diriel]

@bridgman,

maybe a bit offtopic, but I would consider 1 Naga and 5 Rocoto

http://en.wikipedia.org/wiki/Capsicum_pubescens

peppers for your jerk sauce. The Naga can be dramatically hotter than the scotch bonnet. Worst case is, it will be slightly tamer than you desired. There are a number of Naga's and sometimes what is stated is not really what you have. Below I will provide a youtube link to one Naga video "review", where he mentions some other Naga and Naga related peppers. Personally I really prefer the Chocolate Bhut Jolokia, as the taste is fantastic, and the heat is nuclear. Great to cook with. I have not tried the ones in the video review I have linked.

In other news, I can hardly wait for bobcat systems to begin appearing. I am hoping that by mid 2011 the opensource drivers will be up to snuff enough that I can build a internet / low power GP box and really use all open drivers. That would really rock.

Good luck with your Jerk Sauce.
P.S. http://www.youtube.com/watch?v=92RMpJ6_O24

[Xeno]

...
With r300g, we are already at the point where we don't know how to get more speed besides enabling Hyper-Z and besides doing some hard work in the compiler...

IIRC page-flip s still not implemented, enabling it could speed up the things also, especially for lower-end/mobile cards.