Moritz (Better@not.tell) on 4/15/11 wrote:
---------------------------
>Ah, then I get it.
>Because of the fewer "shader"-units DK would predict a lower score, but the score
>will not drop as much as predicted because of the better balance between fixed and programable HW-units.

The problem is that David's assumption is totally wrong; for difference generations of gpu's you can't make a lineair function that predicts its performance.

Most games only require big bandwidth; so performance prediction based upon the aggregated bandwidth would predict things more accurate than David's silly attempt; even then it would be off of course.

Comes newer generation hardware, comes faster hardware, as simple as that.

Where AMD and Nvidia shut up to much about is the actual amount of resources they have to execute executions X.

For example a conditional move is an instruction you can see from AMD's instruction set they have in abundance, but how many of the 4 units can execute this?

There is in the 6900 manual not even a diagram showing the 4 execution units, let alone what sort of instructions which unit can execute.

This is something that's very crucial to know for programmers. If you look at agner fog, he has measured some latencies on cpu's; there is nothing like that about gpu's.

Only what NSA type dudes leak to me is what i know there and usually that's focking accurate.

Yet they leak so fragmentaric, that it's not even remotely enough to write really fast code for a gpu right from scratch.

Only trial and error brings that.

Very simple question is for example how fast is a shift-right?

We know it can shiftright at most max 31 bits, that's what the evergreen could do, so we can safely guess that's the max the 6000 series can do as well.

Yet how many units can execute a shiftright instruction?

Hope you realize how simple such questions are and how much time it takes to test each individual instruction there.

Then there is an opencl compiler in between that can mess things up, in case of AMD; yet i pray it'll get slowly better.

Yet closing our eyes for the huge performance gpu's deliver, just based upon bad documentation from their side, is not the correct approach. If you want performance nowadays, gpu's can deliver that, just it takes a bit more effort to get the great performance out of the gpu.

What i really wonder about is the small amount of contract jobs i see where companies/organisations ask for capable gpu programmers.

The fundamental problem of society might be that they're not used to pay much for software development.

Every HPC guy may figure it out himself; which is not a very clever way to do it if we realize how tough gpu's are to program efficiently.