The NEXT LAST R600 Rumours & Speculation Thread

I agree. What Rys says implies he considers it a driver fault.

I'd just like to see them tested, so far nought. No conception of the theoretical performance of G80's GS architecture and no idea how G80 is dealing with the variety of possibilities there.

I guess we'll just have to see...

Jawed

 

It's also easier for someone to ask for an explanation than to go research the topic themselves and try to better their own understanding so that they can avoid making such silly statements in the future.

First of all, instruction re-ordering is handled by the shader compiler so your statement there has no merit, at least I've never heard of OOE in a GPU. And even if it did, I fail to see how that would be relevant to an R600 to G80 comparison. Let's assume for kicks that GPU's did OOE in hardware. How is R600's ALU configuration more amenable to this than G80's?

And that bit about storing temporary data for in-flight threads - that's the theme that all modern GPU's are built around. Not even sure how to respond to your comments about the number of instructions or branching since they really make no sense to me. Maybe somebody is willing to take a shot at it for ya.

 

We can push peak filter rates (and for more than INT8 surfaces) out of R600 at this point (large and small textures too) with a new tester (w00t!), so it seems the driver and hardware is running freely in that respect, so it would depend on what the app is doing to poop on that somehow.

Don't look forward to it too much! I get nervous around this time that I'm not going to have the time to put everything in there. I've already cut some stuff (which we'll talk about at some point though)......

Which seems to say I should spend less time drinking tea and reading this thread, and more time hacking it up

 

Are those peaks high peaks or low peaks?

Awwwww

 

interesting

LOL

 

Unfortunately explaining is not simple.

You need to think of time-sliced batch scheduling as the primary mechanism, with the GPU operating on a set of tens or hundreds of batches (per cluster). Instruction parallelism is something that's pretty much hidden and not (in my opinion) relevant to a discussion of load-balancing and overall batch throughput.

This is a good starting point:

http://www.beyond3d.com/content/articles/4/8

Jawed

 

The R580 wasnt a massive leap in real world performance over the X1800XT in any respect. I believe the biggest advantages came at ultra high resolutions but for the most part the R520 was a good strong core and the R580 was simply a refresh of that giving a speed boost. In this case, with the R600, its looking like the problem is with the core itself so if what we're waiting on is substantial clock increases at .65nm then thats not very hopeful considering nVidia can do the same thing.

The R520 also had a really good advantage, to me anyway, in improved high IQ performance, and substantially so over Geforce 7 parts, so if the IQ hasnt been improved yet again to something beyond that of the G80 even if its slower, then this card is a pass to me.

Still got the inhouse tech demos to look forward too!

 

All the bench leaks , i'm surprised no driver has been leaked yet

 

for what ? actually they last no more than 2 or 3 days before a new release comes out

 

Rys, just had a question, if the threads in flight are reduced when GS is being used, that will effect everything else right? It will become a "systemic" problem?

 

Unless the driver/compiler can detect that the shader will do no work GS threads must still be run and memory must be allocated. This will be true of both G80 and R600.

 

Very interesting .... R6 Las Vegas ,

R6: Las Vegas, maximun settings

2900XT/8800GTS:
1024x768
min:38/27
med:74/60
max:111/95

1280x960
min:26/18
med:53/42
max:83/68

1600x1200
min:19/13
med:37/30
max:70/48

 

In that it'll affect the performance of the entire chip? It has the potential to, of course, if there aren't enough available threads to keep throughput up.

I think there are also cases (currently, and on G80) where a GS shader can have the thread count increasingly reduced to the point where only a relatively small number of them are running and possibly only on one cluster, because it's doing increased amounts of amplification.

I think worst cases like that are possible on dynamically load-balanced architecture which has fixed resources, though. I haven't tested a shader like that heavily though, nor on R600 yet.

 

From what I have read so far I conclude that the AA of the HD 2900XT is still "broken" because without AA the HD 2900XT is significantly faster than the GTS but with AA the card is slower.

can someone confirm this?

 

Interesting indeed.

Why the hell doesn't R600 kick the living crap out of the 8800 GTS?

Please, someone has to remind the 320 stream processors that's it's showtime. Wakey wakey.

 

I think this is a HD2900XT here.



FEAR


CoH



Are these good scores?

 

Fake ? This test is CPU limited

http://www.firingsquad.com/hardware/geforce_8800_gtx_gts_core_2_performance/page5.asp


http://www.firingsquad.com/hardware/intel_core_2_duo_e4300_review/images/fear800.gif

 

I specified a maximum of 3 vertices....

Honestly on one hand I understand that there are a lot of really hard things to do with respect to the geometry shader. It really does break the parallelism and can easily be coded to bring *any* card to a halt. That said, they must have thought that some of the easy cases could be accelerated efficiently or else they wouldn't have added it to the spec (assuming MS isn't just totally off in left field). Still, the current performance of the G80 GS leaves something to be desired, but I'm willing to conceded that it could be partially or entirely driver related at this point.

Still I won't be surprised if geometry shading is another dynamic branching wrt. NV40 vs R520...

 

It doesn't seem like a joke or anything. He says its on Core2duo @2.4Ghz default. ..so, I donno. We'll see maybe Monday.

 

single card WR!