X1800/7800gt AA comparisons

Status
Not open for further replies.
sireric said:
There's a rather elaborate system in place, but the issue is that access patterns vary greatly even within one application -- One seen might be dominated by a shader, while another by a single texture and another by geometry (imagine spinning around in a room). You could optimize on a per scene basis, but that's more than we plan at this point (a lot of work). But we do plan on improving the "average" for each application. The basis for this, btw, is us measuring the internal performance of apps (in real time), and then adjusting things based on this. Multiple levels of feedback and thinking involved :)

Oh, but optimizing on a per scene basis would be what makes the project fun!

Still, I'm glad to hear that you are actually measuring apps in realtime and adjusting things based on that! Here's what I was thinking though:

You could start out writing an internal program to randomly vary your input parameters, take configurations you've written (or better yet, try to generate them based on some hueristic), and then get a quantitative score (memory throughput, fps, etc). You export the data, use something like weka (a nice data mining tool) to build model trees (basically decision trees with a statistical component at the root nodes, which makes them able to handle co-dependent data), and do a 10-fold cross validation test against your input data.

Once you have the model trees built, you are golden. You incorperate them into your drivers and do your internal realtime test, run your model tree, and given all the attributes, pick the configuration that has the best performance. It would be even more interesting to dig into configurations and not treat them as a black box, but rather find out why certain configurations behave better than others and dynamically modify them...

Oh, this sounds fun. You are lucky. :D

Nite_Hawk
 
acrh2 said:
How does the change in MC programs affect scores in other games (d3d and ogl)?
The reason why I am asking this is because there seems to a large jump in frames @ 1600x1200 4xAA for doom3, but a smaller jump for Riddick (relatively speaking).
In other words, will the fix work only for Doom3 and Riddick or will it lower scores in other games?

Why can't I edit my posts? :)
What I meant to ask was:

In other words, will the fix work for other games, leave other games unchanged, or will it lower scores in other games?
 
Nite_Hawk said:
Oh, but optimizing on a per scene basis would be what makes the project fun!

Still, I'm glad to hear that you are actually measuring apps in realtime and adjusting things based on that! Here's what I was thinking though:

You could start out writing an internal program to randomly vary your input parameters, take configurations you've written (or better yet, try to generate them based on some hueristic), and then get a quantitative score (memory throughput, fps, etc). You export the data, use something like weka (a nice data mining tool) to build model trees (basically decision trees with a statistical component at the root nodes, which makes them able to handle co-dependent data), and do a 10-fold cross validation test against your input data.

Once you have the model trees built, you are golden. You incorperate them into your drivers and do your internal realtime test, run your model tree, and given all the attributes, pick the configuration that has the best performance. It would be even more interesting to dig into configurations and not treat them as a black box, but rather find out why certain configurations behave better than others and dynamically modify them...

Oh, this sounds fun. You are lucky. :D

Nite_Hawk

It would be better to implement multiple configurations via game profiles, like in Forceware drivers.
 
Eric, would the 128-bit bus of RV530 theoretically stand to benefit (relatively) more or less from these bandwidth-saving memory controller tweaks?
 
Last edited by a moderator:
If you actually READ the hexus article, they say that Ogl improvement is overall and ALSO noticable in SS2.

so, so far we have one 30% increase, one 15% and one unbenchmarked one.
I'd love to read the reviews tomorrow.
 
Just a quick note to say (and I'll update the article to say so) that the GTX was a reference board at 430/600, since that makes a difference to some folks and people with higher clocked retail products.
 
neliz said:
If you actually READ the hexus article, they say that Ogl improvement is overall and ALSO noticable in SS2.

so, so far we have one 30% increase, one 15% and one unbenchmarked one.
I'd love to read the reviews tomorrow.

I actually READ it.

What about D3D?
 
acrh2 said:
It would be better to implement multiple configurations via game profiles, like in Forceware drivers.

That would only let you choose a configuration based on the game, not based on the scene. Besides, you then are tied to only use a pre-existing configuration. The idea is that you want this to be dynamic and automatic. The user has no idea what configuration will result in the optimal speed increase without trying all of them. A model tree will let you take a bunch of input parameters (like rops) and try to predict based on all of those attributes what the best configuration would be to use. What's better is that you can re-run the model tree as often as you like to determine if you are still using the optimal configuration given the current input parameters.

Please don't take this the wrong way, but game profiles ala the forceware drivers would be a rather crude solution in comparison.

Nite_Hawk
 
kemosabe said:
Eric, would the 128-bit bus of RV530 theoretcially stand to benefit (relatively) more or less from these bandwidth-saving memory controller tweaks?

It's even more sensitive to these programs/parameters. I'm not sure the effect of this quick fix, but I would guess it would help. Once we've done a first round of tuning, I'm certain it will be benefits too.
 
MulciberXP said:
does this fix have a negative impact on D3D performance?

This is independant (completely) of D3D -- D3D has a different driver and different MC settings systems. Though, there are lots of D3D improvements coming up too...
 
sireric said:
It's even more sensitive to these programs/parameters. I'm not sure the effect of this quick fix, but I would guess it would help. Once we've done a first round of tuning, I'm certain it will be benefits too.

Thanks - best of luck to you and Terry's team in extracting all the performance juice from this discovery. :)
 
Btw Sireric,

When you guys implemented the programmable memory system did you have any idea you'd be able to get this kind of speed increase out of it? That seems like a very bright decision after the fact... Is someone getting a raise? ;)

Nite_Hawk
 
Very awesome, makes it hard to find a fault now in the X1800XT (once its available) performance wise.

I'm curious, how programmable is the 7800GTX memory controller compared to the X1800s.

I'm really looking foward to more tweaks in the MC, seems there is still a lot of performance to be unlocked in the X1Ks.
 
sireric said:
No luck at all. More like being dumb for not doing this earlier. It was very simple. It just required people to start looking into what is going on.
\

Bah!!! I have been on many product launches and this type of stuff always happens. Every time we get to go back and look at a product I can start shaving cost or increase profromance so dont feel bad. When your under the gun you go with what works and meets specs first, then come back and make it mo' better :) Keep up the good work!
 
Nite_Hawk said:
That seems like a very bright decision after the fact... Is someone getting a raise? ;)
Joe doesn't need any more Ferraris :p
 
The new memory controller has just become ATI's (no longer secret) superweapon. The potential for strongly improving performance in all sorts of places has just become pretty significant.
 
Nite_Hawk said:
Btw Sireric,

When you guys implemented the programmable memory system did you have any idea you'd be able to get this kind of speed increase out of it? That seems like a very bright decision after the fact... Is someone getting a raise? ;)

Nite_Hawk

We learned a lot from previous architectures on what works and what doesn't. Could I of guessed a change would cause D3 up 30%? Well, I expected off the bat, that D3 should of been much better than it was. And we still have lots of work.
 
Rys said:
Just a quick note to say (and I'll update the article to say so) that the GTX was a reference board at 430/600, since that makes a difference to some folks and people with higher clocked retail products.

Are you testing on an XL as well?
 
sireric said:
We learned a lot from previous architectures on what works and what doesn't. Could I of guessed a change would cause D3 up 30%? Well, I expected off the bat, that D3 should of been much better than it was. And we still have lots of work.

Well, good luck with it! I have to say I'm a bit envious. You don't get to performance gains like this on established products very often. It makes you feel almost giddy. May be some day I'll be able to sell some of you guys at ATI or nVidia on my data mining performance ideas. I actually built some models and wrote a paper in college to predict framerate score based on videocard/cpu/memory configurations. It was really neat. :)

Nite_Hawk
 
Status
Not open for further replies.
Back
Top