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

[Ard Righ]

airlied, is there much chance this driver will make it into Fedora 14? Or at least F14-rawhide for people to test?

I would very much like to try it, but I'm not game enough at the moment to compile drivers to run on my laptop.

You might not remember, but I thanked you at LCA2010 for your work on the ATI drivers, and that still holds very true

[bridgman]

At least on openarena which was causing 1.5 CS packets per frame I didn't see any useful speedup at all.

I somehow expected a considerably larger number of CS packets per frame (I was thinking more like 10-50) and presumably the speedup would be more significant in those cases. Do you think openarena is typical in terms of CS packets per frame ?

[BlackStar]

KDE Vs. Gnome flamewar + Blackstar + editing previous posts for profit = ... ?

Which reminds me, we haven't had any good flamewars for some time. Don't worry though, the edit window won't affect those. It only annoys honest users, such as bridgman.

Also bridgman got this right.

@marek, airlied: is early-z/hierarchical-z working? This can give a nice speedup, in the order of a few percent in most cases (although I've seen up to 50% on specific tests with high overdraw, heavy shaders and weak hardware).

[V!NCENT]

Sorry, how exactly is edit window supposed to affect whether trolls get in or not? o.O

KDE Vs. Gnome flamewar + Blackstar + editing previous posts for profit = ... ?

[airlied]

Nothing I know of.


I think Dave has done some work to optimize redundant state setting at the beginning of CS and the performance difference was negligible, so I think this has been debunked.

Yeah I modified the stack to accept multiple CS packets per frame, with no re-emit or flushing between them, so at least every frame would cause a re-emit instead of multiple re-emits per frame. At least on openarena which was causing 1.5 CS packets per frame I didn't see any useful speedup at all.

page-flip is probably a good speedup for fullscreen games alright that isn't done yet.

Dave.

[bridgman]

Sorry, how exactly is edit window supposed to affect whether trolls get in or not? o.O

My understanding was roughly the following :

New users aren't allowed to post link-laden ads (and other users don't seem to feel the need to do so ), but spammers were using the edit mechanism to make an initial post without links then go back and edit the post to add the rest of the advertisement. Limiting the edit window seemed to stop the practice.

[marek]

Just speaking for myself and my needs, r300g is very much fast enough. It's also coming very, very close to dethrone i965 as the free driver where most games/apps/demos work.

Glad to hear that. Thanks.

[whizse]

Just speaking for myself and my needs, r300g is very much fast enough. It's also coming very, very close to dethrone i965 as the free driver where most games/apps/demos work.

[nanonyme]

The edit windows should be 5min. That enough to modify your post and keep the trolls out.

Sorry, how exactly is edit window supposed to affect whether trolls get in or not? o.O

[marek]

Is there any mechanism today that could be hacked to give a rough measure of GPU activity, say split between "busy", "flushing", and "idle" ?

Nothing I know of.

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.

I think Dave has done some work to optimize redundant state setting at the beginning of CS and the performance difference was negligible, so I think this has been debunked.