The LAST R600 Rumours & Speculation Thread

[Shtal]

I think you need to done down the ******ism... The "24 vs 48 pixel shaders on R580" is not the right way to think about it anyway. Also, remember the R580 was 350mm^2, while the G71 was not even 200mm^2...

It's been few pages back when you reply to me....
I don't understand what you mean!

Pixel will still remain pixel, count of the pixel will still remain count; Calculation for 3:1 ratio will still produce outcome. What do you mean ???? "Unless you have something against me"

[Edit: I was comparing G71 vs. R580]

 

[ChrisRay]

Not all pixel shaders are created equally. And that was his point. This is a dead horse argument though.

Chris

 

[AlexV]

Pixel not remain pixel, pixel be different when IHV be different...you not want to understand, many informations not yet available so no good to make absolute statements like that.

 

[^eMpTy^]

So, say R600 has 64 Vec4 shader pipes (plus a scalar? *shrug*) running at 750MHz. Is that enough to topple G80? What about 96 pipes?

In my head I'm thinking 64*4*750 > 128*1350...but obviously it's not that simple.

At what number of pipelines does R600 go from merely being competition for G80, to fully trouncing G80? Again, assuming that this 750MHz core clock with no clock domains is true.

 

[KimB]

At what number of pipelines does R600 go from merely being competition for G80, to fully trouncing G80? Again, assuming that this 750MHz core clock with no clock domains is true.

Well, that's going to depend a whole lot upon how those pipelines are constructed. The real question is, which type of pipeline is more efficient with today's workloads? And by how much? Things like texturing efficiency could play a very big part here, as well as just the usage of the ALU pipelines.

 

[Arun]

Pixel will still remain pixel, count of the pixel will still remain count; Calculation for 3:1 ratio will still produce outcome. What do you mean ???? "Unless you have something against me"

There is no such thing as a "pixel" pipeline, that's just a basic term that could be used to describe a bunch of quite different things. It's really important for you to stop describing architectures in such rough ways. What you describe as pixel pipelines are sometimes very different things...

There is nothing you could really refer to as a "pixel pipeline" in the G7x and R5xx; you had ROPs, ALU pipelines, texturing pipelines, etc. - if you even want to see things in terms of pipelines at all, that is. With these kinds of notions, how would you describe G80 or R600? (hint: you can't...)

There's really no reason to make such statements, with such certainty, if you lack the technical understanding needed to truly understand what you are saying... Anyway, while the practical ratios are not that simple to calculate, it is fairly obvious that the R580 has much higher ALU 'power', but it is with a more expensive to produce chip. From an enthusiast pov, that doesn't matter much if they are sold at similar price points - but it is still worth pondering upon before making statements as bold as yours...

 

[zgemboandislic]

http://www.xbitlabs.com/news/video/display/20070123045017.html

Well this is certainly good news. I remember that I mentioned this possibility last year, but noone seemed to agree.

To have 3 competitors in the discrete GPU world would be perfect.

 

[Twinkie]

Would you consider the GTS with the memory bandwith of the GTX as bandwith limited ?

Why you ask? Im not even sure if G80 is bandwidth limited or not bandwidth limited.

Now wheres is the beyond3d G80 performance benchmarks..

 

[Jawed]

I thought Nvidia said the parallel data cache is 16KB at the Supercomputing conference. My thinking is you shouldn't just add up the parallel data caches from the 8 thread processing clusters and call them a 128KB cache because data isn't shared between clusters. At least I don't think it is. Mike Houston seems to think it's 16 KB as well.

I think Uttar is saying that each cluster, which has two 16KB PDCs, adds up to a total PDC size of 256KB.

16 independent PDCs will mean that shared data algorithms will have to work with smaller tiles. It doesn't sound unusable. Obviously 16KB per array is rather small in comparison with Cell's 256KB of LS.

And it's also worth bearing in mind that if there's any thread swapping, then some PDC will be consumed while G80 manages the registers involved in thread swapping. e.g. 4KB of each PDC might be reserved for thread swapping. 16 objects per thread, with 4 threads in flight (1 active, 3 being swapped) with 4x fp32 (128-bit) operands per object is 4KB.

Or 8KB if 32-object threads are being used - which would mean the PDC provides 64 bytes per object, i.e. 4x fp32s. Obviously, just guessing at scenarios.

Jawed

 

[Bouncing Zabaglione Bros.]

http://www.xbitlabs.com/news/video/display/20070123045017.html

Well this is certainly good news. I remember that I mentioned this possibility last year, but noone seemed to agree.

To have 3 competitors in the discrete GPU world would be perfect.

Posted already at B3D (even frontpaged). There's a thread for it which is more on topic than this one.

 

[Rys]

Now wheres is the beyond3d G80 performance benchmarks..

? When we get the driver we need, we'll get round to it. As it stands, B3D has more important things to do in the interim while NVIDIA sort that out. We're both sorry for the wait (I think)

 

[Geo]

Posted already at B3D (even frontpaged). There's a thread for it which is more on topic than this one.

And I'd bet a nickel that Xbit found out about it from us, directly or indirectly, but that's the way it goes. :smile:

 

[neliz]

And I'd bet a nickel that Xbit found out about it from us, directly or indirectly, but that's the way it goes. :smile:

The advent of Larrabee is upon is.. but will they beat AMD to their R700?

 

[zgemboandislic]

Posted already at B3D (even frontpaged). There's a thread for it which is more on topic than this one.

Errr, sorry about that, kinda didn't see it

 

[PeterAce]

? When we get the driver we need, we'll get round to it. As it stands, B3D has more important things to do in the interim while NVIDIA sort that out. We're both sorry for the wait (I think)

I think people are a bit disapointed that you didn't do the performance article in two parts - a D3D9/ OpenGL performance article (which compares 7900/7950GX2/R580 to G80) even just some Rightmark, fillrate tester(s) and other B3D's own thoretical shader tests (mentioned in the Arch part) would be fine.

Then the second part being the 'full nitty-gritty D3D10 performance article' (when NV has provided required/correct driver etc).

You've already split up Arch, IQ, (and I assume an upcomming CUDA) then a two part Perf would be consistant to your new article style.

 

[Shtal]

There is no such thing as a "pixel" pipeline, that's just a basic term that could be used to describe a bunch of quite different things. It's really important for you to stop describing architectures in such rough ways. What you describe as pixel pipelines are sometimes very different things...

There is nothing you could really refer to as a "pixel pipeline" in the G7x and R5xx; you had ROPs, ALU pipelines, texturing pipelines, etc. - if you even want to see things in terms of pipelines at all, that is. With these kinds of notions, how would you describe G80 or R600? (hint: you can't...)

There's really no reason to make such statements, with such certainty, if you lack the technical understanding needed to truly understand what you are saying... Anyway, while the practical ratios are not that simple to calculate, it is fairly obvious that the R580 has much higher ALU 'power', but it is with a more expensive to produce chip. From an enthusiast pov, that doesn't matter much if they are sold at similar price points - but it is still worth pondering upon before making statements as bold as yours...

I'm not trying to be difficult....
Please explain what this mean when some website quote like this:
Pixel Pipelines 16 and Pixel Shaders 16 for R480

Core 480
Silicon Process 110nm
Transistor Count 160
(millions)
Core Speed MHz 540
Memory Speed MHz (Effective) 590 (1.18GHz)
Memory Size 256
Bus Standard Peg x16
Bus Width 256
Pixel Pipelines 16
Pixel Shaders 16
Vertex Shaders 6
Peak Memory Bandwidth 37.8
(GB/s)
Pixel Fillrate 8,640
(million pixels/sec)
Texel Fillrate 8,640
(million texels/sec)
API Compliancy DX9.0b Sm2.0

 

[Rys]

I think people are a bit disapointed that you didn't do the performance article in two parts - a D3D9/ OpenGL performance article (which compares 7900/7950GX2/R580 to G80) even just some Rightmark, fillrate tester(s) and other B3D's own thoretical shader tests (mentioned in the Arch part) would be fine.

And we did ponder that approach, but went the way we have in the end. As a concession we pointed at Tridam's analysis and the work I did for G80 at Hexus, as good means to get a handle on perf compared to existing hardware until we get there ourselves. Maybe we got the balance between talking about perf and showing it off properly wrong (we always thought arch and IQ were most important to you guys in terms of our initial focus, since the man and his dog will focus more on perf on NDA expiry and we can just point you at some of those that we like), but I'll keep that in mind for future pieces.

Back on topic, Shtal, when you see pixel pipeline written like that it usually refers to the ROP count instead (or more specifically final pixels written per clock). The word pipeline is a poor fit, and there's a language barrier you're hitting up against when you post which exacerbates the issue a little and can frustrate. Not to worry though, that's what the forums are for in part, to help you learn :smile:

 

[rwolf]

There is no such thing as a "pixel" pipeline, that's just a basic term that could be used to describe a bunch of quite different things. It's really important for you to stop describing architectures in such rough ways. What you describe as pixel pipelines are sometimes very different things...

There is nothing you could really refer to as a "pixel pipeline" in the G7x and R5xx; you had ROPs, ALU pipelines, texturing pipelines, etc. - if you even want to see things in terms of pipelines at all, that is. With these kinds of notions, how would you describe G80 or R600? (hint: you can't...)

There's really no reason to make such statements, with such certainty, if you lack the technical understanding needed to truly understand what you are saying... Anyway, while the practical ratios are not that simple to calculate, it is fairly obvious that the R580 has much higher ALU 'power', but it is with a more expensive to produce chip. From an enthusiast pov, that doesn't matter much if they are sold at similar price points - but it is still worth pondering upon before making statements as bold as yours...

Last I checked R580 had a 16 pixel pipeline with 48 pixel processors. Just because the implementation is not always 1:1 for all components doesn't mean the pixel pipeline is not there.

 

[KimB]

Last I checked R580 had a 16 pixel pipeline with 48 pixel processors. Just because the implementation is not always 1:1 for all components doesn't mean the pixel pipeline is not there.

Well, the pipelines are certainly there, but modern pipelines are so decoupled from pixels that it's becoming rather useless to think of them as pixel pipelines.

 

[Dave Baumann]

Well, the pipelines are certainly there, but modern pipelines are so decoupled from pixels that it's becoming rather useless to think of them as pixel pipelines.

Kinda depends on how you look at things really.

Hark back to Voodoo days and we have separate chips for the pixel pipeline and the texture pipeline - they were decoupled then (with a scalable number of texture units). We've gone through a whole mess of stuff since then, but if you look at something like Xenos there are remarkable paralells in that the texture pipes and the pixel pipes are separate chips!

The "pixel pipeline" can just be boiled down to the ROP's, which are still relatively fixed function elements that they were in Voodoo days - the texture piplines, though, have grown to be rather large, programmble units.