The LAST R600 Rumours & Speculation Thread

Status
Not open for further replies.
ATi gave the x1800xl a 256bit bus just like the xt. I don't see why not for the x2900xl. Cut it down by shaders and ROP's(although not too much please hehe..:smile: ), and clock speed, but at least let me keep that new mouth dropping memory controller.

Yeah but the 256bit controller wasn't new with the x1x00 series. I do hope for it but I don't believe that my dreams will come true. With the mainstream models of both nVidia and ATI's parts rumored to have 28bit buses, they've got to put the 256bit one somewhere. Lower-highend and higher-midrange seems like a sensible place for it.

I can say this for certain: if the R600XL were a 512bit bus card even with (I'll use the Inq numbers for this, even though I'm sure they're wrong) 96/128 shaders and 24/32 ROPS, I'd jump all over it. And I wouldn't be the only one.


It'll be interesting to see how they position their product line this time around.
 
I think the liklihood that R600 has 128 pipes (or shaders rather, presumably) is something less than. . .I dunno. . . .0002%? It's small. s m capital ALL. SMALL. I mean, jeez, that's practically the guaranteed number it WON'T have. 64, 80, 96, 256, 320, 384, 480. . .these are all numbers that I might or might not like personally, but I wouldn't rule them out, largely because they're of the age old question "Yeah, how are you counting, bubbula?" But 128? Just really don't see it. :)

Well with some creative math you could end up with anything starting from 64 and upwards from there. I don't think though that's the case here; just some dimbass speculating based on G80's specs.
 
ATi gave the x1800xl a 256bit bus just like the xt. I don't see why not for the x2900xl. Cut it down by shaders and ROP's(although not too much please hehe..:smile: ), and clock speed, but at least let me keep that new mouth dropping memory controller.

What's so exciting about it, other than that it's 512bits wide?
 
I don't expect the R650/680 to be 65nm but rather the current 80nm.

US

Do you really? All signs point to 65nm. Not just because low-end parts are 65nm, and RV670 which might a neutered R600 (GTO?) on 65nm in Q3, but also presumably it's coming close enough to EOY (R600 + ~6 months + patented ATi delay = Q4ish) that 65nm is almost a given because of process evolution...I mean, at the very least it's going to be competing with a 65nm GF8 or even GF9. Also, how much more can they do with 80nm? Add anymore anything and that thing is going to need a RIDICULOUS amount of power. We're already seeing 225W for stock, 300w (of connectors) for over clocking; the top of the new PCI-e spec. Anything more could take 375W of connectors, and I personally do not see that happening for that reason amongst others. Not only because having that kind of power requirement is almost commercial suicide because few would have the juice on correct rails/connectors (especially for XFIRE), but because the thing would also be huge, expensive, hot, and competing against a much more lucrative product (a 65nm GF). Couple all this with the fact ATi has said their lineup in 2008 will include 45nm (Which means likely the R700 generation), I think it's a safe assumption to say all roads lead to the high-end refresh being 65nm.
 
Last edited by a moderator:
You're under the false assumption that it needs something more than a 512bit width to be exciting.

If you read back carefully enough I questioned the supposed exiting part about the ring stop thingy and NOT the buswidth. If GPUs would go right now beyond 512bits of buswidth I'd have serious reasons to worry about read efficiency. Take the common burst value of either DDR3 or 4 and multiply it with 768 or even 1024 bits and tell me if you win or lose more bandwidth in the end while reading a shitload of useless data.
 
If you read back carefully enough I questioned the supposed exiting part about the ring stop thingy and NOT the buswidth. If GPUs would go right now beyond 512bits of buswidth I'd have serious reasons to worry about read efficiency. Take the common burst value of either DDR3 or 4 and multiply it with 768 or even 1024 bits and tell me if you win or lose more bandwidth in the end while reading a shitload of useless data.

computers will never need more that 640K :rolleyes:
 
Do you really? All signs point to 65nm. Not just because low-end parts are 65nm, and RV670 which might a neutered R600 (GTO?) on 65nm in Q3, but also presumably it's coming close enough to EOY (R600 + ~6 months + patented ATi delay = Q4ish) that 65nm is almost a given because of process evolution...I mean, at the very least it's going to be competing with a 65nm GF8 or even GF9. Also, how much more can they do with 80nm? Add anymore anything and that thing is going to need a RIDICULOUS amount of power. We're already seeing 225W for stock, 300w (of connectors) for over clocking; the top of the new PCI-e spec. Anything more could take 375W of connectors, and I personally do not see that happening for that reason amongst others. Not only because having that kind of power requirement is almost commercial suicide because few would have the juice on correct rails/connectors (especially for XFIRE), but because the thing would also be huge, expensive, hot, and competing against a much more lucrative product (a 65nm GF). Couple all this with the fact ATi has said their lineup in 2008 will include 45nm (Which means likely the R700 generation), I think it's a safe assumption to say all roads lead to the high-end refresh being 65nm.

65nm would be a totally new design. Look at the past and that will tell you how it will go in the future.
 
If you read back carefully enough I questioned the supposed exiting part about the ring stop thingy and NOT the buswidth. If GPUs would go right now beyond 512bits of buswidth I'd have serious reasons to worry about read efficiency. Take the common burst value of either DDR3 or 4 and multiply it with 768 or even 1024 bits and tell me if you win or lose more bandwidth in the end while reading a shitload of useless data.

I think this is precisely the reason why GPUs have multiple independent memory channels. So you don't have to tie up the entire zomg-bit bus to read just for a small read/write.
 
Ok my guess based on current hype/info/misleads/hogwash...

XTX 96 shaders 512bit bus 1GB mem at 2GHz core ~750mhz
XT 96 shaders 512bit bus 512MB mem at 1.8GHz core ~650mhz
XL is the tricky one, so 2 different guesses
If it is 512 bit bus then 64 shaders, 500 core, 1.5GHz mem
If it is 256 bit bus then it could have the full 96 shaders but 650 core and 1.5GHz mem

That leaves us with the XTX2 (if there is going to be one)
Will it be two XL chips. IF so then 256 bit or 512 bit? One would think 256 with 96 shaders per but the other version would yield the rumored 128 shaders (or 2x64) on a 512bit bus.....



Ouch my head hurts
 
I think this is precisely the reason why GPUs have multiple independent memory channels. So you don't have to tie up the entire zomg-bit bus to read just for a small read/write.

Which TODAY would mean a complete waste of added hardware in order to hide all that latency involved. It took 5 years until GPUs went from a 256 to a 512bit wide bus.
 
... but at least let me keep that new mouth dropping memory controller.
:?:

If you're happy with 256 bits, what exactly is wrong with the memory controller of R580 and how do you expect this to be improved in R600? Do you have reasons to assume it currently doesn't perform at the best possible efficiency?
 
All I know is if ATI delivers 128 vec4 ALU's in R600, Nvidia's got some explaining to do about why they could only fit 64 scalar in similar transistors. Although if performance is within 10% or so, then they dont have to do any explaining.
 
Convince me that we NEED today more than 512bit wide busses; read again in case you haven't understood the quoted paragraph above.

No need to get so defensive. Most of us could think of many situations where a GPU would NEED more than a 512bit wide bus to local mem, as I'm sure could you. You can't think of a way to saturate ~179 GB/s (@ 2.8ghz GDDR4)? I think its kind of a pointless exercise though.
 
All I know is if ATI delivers 128 vec4 ALU's in R600, Nvidia's got some explaining to do about why they could only fit 64 scalar in similar transistors. Although if performance is within 10% or so, then they dont have to do any explaining.

If ATI delivers 128 vec4 ALU's and the card performs only 10% faster than the G80, ATI has some explaining to due. Even at *only* 700-800mhz 128 vec4 ALU's would have to be pretty damn innefficient to only outrun 128 scalar ALU's (@ 1350mhz) by 10%. I would say ouch to ATI.
 
No need to get so defensive. Most of us could think of many situations where a GPU would NEED more than a 512bit wide bus to local mem, as I'm sure could you. You can't think of a way to saturate ~179 GB/s (@ 2.8ghz GDDR4)? I think its kind of a pointless exercise though.


Actaully its quite hard to saturate that much bandwidth before you hit a shader or fillrate bottleneck ;). Shaders get more complex less bandwidth thats necessary, post render effects take up bandwidth though, how many types of post render effects are we using in today's games, I really can only think of 2 or 3 that will become main stream, HDR, motion blur, (I wouldn't put deffered shading into this but since Unreal 3 engine has it.....) Deffered shading. Then we have AA and AF that take up bandwidth. Opps forgot depth of field, so thats 3-4 :)
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top