R500 + eDRAM... what are the benefits?
- Thread starter Acert93
- Start date
It should probably scale better than current solutions as it makes savings all round - power is saved because you are always using ALU's for one thing or another and never waiting for either VS or PS to finish something (and its not really possible to clock either down while they are not doing anything), and you'll also make saving on things like buffering between VS and PS.
If performance per/transistor is roughly on par with non unified architectures then it seems like a great design to populate a product line with. If memory buses are the same along with the arbiter and the only difference is the number of ALU's then Sireric might need to find something more exciting to work on.DaveBaumann said:
Would such a design be similar in that if a number of ALUs were bad they could just be disabled like pipelines are today?One thing I wondered about, what happens when a frame is finished and the backbuffer needs to be transferred to external memory? Does the chip simply stall for that short period, having no backbuffer to write to, or maybe do some vertex only work?
I mean, 3.5 MiB/frame (color data for 720p) at 60 fps seems to require such an insignificant period of time that it may not be worth any kind of double-buffering effort. But with render-to-texture, that requirement may only go up.
I mean, 3.5 MiB/frame (color data for 720p) at 60 fps seems to require such an insignificant period of time that it may not be worth any kind of double-buffering effort. But with render-to-texture, that requirement may only go up.
Isn't the 64 concurrent threads derived from 48 which can be assigned to each of the ALU's and 16 others which are assigned to the TMU's?
How many components can be operated on in the ALU's, 5? And can operations use any mix of components. 4+1 is obvious, but are other combinations supported?
What kind of flexibility is there with the TMU's. Is there filtering for FP32? Can the TMU's be stacked to feed fewer ALU's to acheive single cycle trilinear or FP samples. What filtering levels are supported?
How expensive is branching in this architecture? Is the initial Z pass for a more automated, sophisticated form of Ultra-Shadow? What type of Hyper-Z is being employed?
How many components can be operated on in the ALU's, 5? And can operations use any mix of components. 4+1 is obvious, but are other combinations supported?
What kind of flexibility is there with the TMU's. Is there filtering for FP32? Can the TMU's be stacked to feed fewer ALU's to acheive single cycle trilinear or FP samples. What filtering levels are supported?
How expensive is branching in this architecture? Is the initial Z pass for a more automated, sophisticated form of Ultra-Shadow? What type of Hyper-Z is being employed?
I'm not gonna say anything... Just read;
http://www.hardocp.com/article.html?art=Nzcx
Especially, this part:
WHATTA HELL ???!!
http://www.hardocp.com/article.html?art=Nzcx
Especially, this part:
WHATTA HELL ???!!
therealskywolf
Regular
eSa said:I'm not gonna say anything... Just read;
http://www.hardocp.com/article.html?art=Nzcx
Especially, this part:
WHATTA HELL ???!!
That sounds good.
That gives me a little more optimism for how the real games, especially 2nd gen games designed for the new architecture, will perform.
Idea to toss about: Does Sony have an early advantage with the fact the RSX looks to be an evolution of the current design + access to SLI 6800U with ballpark performance compares to MS who is stuck with a 50% performing SM 2.0 card with no eDRAM and totally different architecture?
It would seem development for the PS3 would be easier at this point, yes? Or should I say, PS3 game development should be more of a known factor.
Idea to toss about: Does Sony have an early advantage with the fact the RSX looks to be an evolution of the current design + access to SLI 6800U with ballpark performance compares to MS who is stuck with a 50% performing SM 2.0 card with no eDRAM and totally different architecture?
It would seem development for the PS3 would be easier at this point, yes? Or should I say, PS3 game development should be more of a known factor.
Similar threads
