R520 for notebooks: M58 when and what?

[Dave Baumann]

"M58" was scheduled for R520, that was what the roadmaps stated some time ago and that is probably what turned up on the PCI SIG list. ATI are now saying that they will not go a notebook version of R520, so "M58" as it was is not going to occur. My hypothesis is that they will go with R580 as their next high end DTR chip because it'll probably give them more room to play around with clocks/configurations and probably still have fairly high performances.

 

[Karma Police]

"M58" was scheduled for R520, that was what the roadmaps stated some time ago and that is probably what turned up on the PCI SIG list. ATI are now saying that they will not go a notebook version of R520, so "M58" as it was is not going to occur. My hypothesis is that they will go with R580 as their next high end DTR chip because it'll probably give them more room to play around with clocks/configurations and probably still have fairly high performances.

Aha! That's why I originally thought it was the R520-based months ago.

So it was the R520 but the huge delay changed their plans to the R580 instead, with the internal code name remaining the same.

 

[kemosabe]

My hypothesis is that they will go with R580 as their next high end DTR chip because it'll probably give them more room to play around with clocks/configurations and probably still have fairly high performances.

I may not be getting the nuance of your comment, but wouldn't a threefold increase in the number of shader processors more than compensate for lower core clocks

I thought R580 was the number of the beast.

 

[Geo]

Well, I mentally added "compared to the desktop version" to his last sentence.

 

[kemosabe]

Hehe.....you'd think I'd have learned by now.

[size=-3]But I still think Dave needs extensive tutoring in how to transfer mental thoughts into written expression.[/size]

 

[Skrying]

I may not be getting the nuance of your comment, but wouldn't a threefold increase in the number of shader processors more than compensate for lower core clocks

I thought R580 was the number of the beast.

Isnt that what he just said? He said, the raw power of R580 would probably give them room to play with clock configurations and still maintain high performance? I dont see how you would have taken his comment a different way.

 

[kemosabe]

Well he seemed to be comparing hypothetical performance of a mobile R520 with that of a R580, and said:

"and probably still have fairly high performances."

This would seem to be minimizing the expected difference in raw pixel shader power between the two ASICs, assuming what we've heard about R580 is accurate.

 

[Dave Baumann]

No, you're not thinking about the environment we're talking about. R520 its using its clockspeed in the desktop environment to give it a healthy chunk of its shader performance, because in a desktop environment it can, however running these speeds and voltages in a DTR/Noteebook form factor probably isn't going to work. I'm saying with R580 they probably have more room to play with the speeds, hence the heat output/voltage use, whilst still maintaining a better shader performance.

 

[Rys]

So you're definitely expecting, because the theoretical shader rate is so high, that M59 will come clocked a bit lower than on discrete boards because of thermals, but since that rate is so high it won't really matter and performance will still be great?

 

[Dave Baumann]

No, I'm saying it'll give them a little more room to play around with, and the likelyhood is the shader rates and processes will be towards more of an equelibrium with NVIDIA, so they will be in a similar situation. But, certainly, I'm not expecting the speeds we're going to see from the desktop parts.

 

[kemosabe]

OK, that's exactly what Geo presumed you were saying - all clear.

I listened to ATI's CC last night and it seemed that Orton was being somewhat misleading in stating that a part like the X1800 "wouldn't be taken up by the notebook market". In fact what he really meant was that they wouldn't be able to make R520 competitive enough at significantly lower clock speeds. This will be the second consecutive generation where ATI fails to adequately address the growing 3D performance focus of the DTR market (and where the GPU margins are highest). Could there still be any validity to the rumour that R520 was originally designed with up to 32 shader processors in mind but that yields didn't allow for production of those chips? This would certainly have allowed them the flexibility that you're alluding to for R580.

 

[Jawed]

It seems to me that R5xx texturing performance is mostly on a competitive knife-edge, so even in an architecture like a mobile version of R580, which'll stick to having 16 texture pipelines (presumably), there'll be a real issue with texturing performance if lower clocks are used.

I suppose it'd be interesting if ATI can individually-clock:

• vertex shader pipes
• texture pipes
• pixel shader pipes
• ROP pipes

In which case there'd be an opportunity to have high texturing clocks but with much lower clocks in the other sections of the GPU.

Jawed

 

[Dave Baumann]

Could there still be any validity to the rumour that R520 was originally designed with up to 32 shader processors in mind but that yields didn't allow for production of those chips?

Ugh. God. No.
Look at the die shot in the article, its quite clear that there are 4, and only 4, quads there.

It seems to me that R5xx texturing performance is mostly on a competitive knife-edge, so even in an architecture like a mobile version of R580, which'll stick to having 16 texture pipelines (presumably), there'll be a real issue with texturing performance if lower clocks are used.

Shader instruction to texture ratio will go up on the instruction side - current apps may not be there, but thats the way things are going.

 

[Geo]

It seems to me that R5xx texturing performance is mostly on a competitive knife-edge, so even in an architecture like a mobile version of R580, which'll stick to having 16 texture pipelines (presumably), there'll be a real issue with texturing performance if lower clocks are used.

I suppose it'd be interesting if ATI can individually-clock:

• vertex shader pipes
• texture pipes
• pixel shader pipes
• ROP pipes

In which case there'd be an opportunity to have high texturing clocks but with much lower clocks in the other sections of the GPU.

Jawed

Given Demirug's point, and Wavey's agreement, about the graphic representation of the texture array vs its physical location. . .just how likely is it we'll see separate clocks for PS and texture units this gen?

I *think* that's a rhetorical question, but maybe someone will disagree. . .

 

[Geo]

Ugh. God. No.

Coming in 2006, "Tempting the Frying Pan: My life at Beyond3D", by Anonymous.

 

[Joe DeFuria]

Coming in 2006, "Tempting the Frying Pan: My life at Beyond3D", by Anonymous.

 

[Jawed]

They are truly independent pipelines as far as I can tell.

Work in progress in the shader ALUs has nothing to do with the work in progress in the texture pipes. If 5 or 6 different ALU batches have been executed in the time it takes the texture pipes to return results doesn't make or break the GPU.

Sure, I don't know what I'm talking about because I'm not a chip designer.

It just seems to me there's an opportunity there.

Jawed

 

[Joe DeFuria]

Ugh. God. No.

Next time...Use this.

 

[Geo]

They are truly independent pipelines as far as I can tell.

Work in progress in the shader ALUs has nothing to do with the work in progress in the texture pipes. If 5 or 6 different ALU batches have been executed in the time it takes the texture pipes to return results doesn't make or break the GPU.

Sure, I don't know what I'm talking about because I'm not a chip designer.

It just seems to me there's an opportunity there.

Jawed

If I've managed to digest this properly (note danger warning), they are independent logically. Physically they are still part of the PS on a one-to-one basis. I would think (and maybe here is where I'm making my mistake) that this fact would be Significant when discussing the difficulties associated with trying to clock them independantly from the PS.

 

[Jawed]

It's a question of granularity on the die, I guess.

Each PS "unit" appears to consist of:

• scheduler (128 threads are private to each unit)
• shader ALUs
• texture pipes
• texture cache
• register array
• hierarchical z/stencil
• ROP pipes

Each of those functional blocks is separated from its compadres by an interface. These blocks aren't intertwined in any particularly symbiotic way that I can identify. They're designed to "free-wheel" independently of each other, functionally. To me it's not a great stretch to imagine that they also free-wheel in terms of their clocks.

Jawed