wtf is up with poly counts

About things to sacrifice in order to have some eDram onboard:
if it's indeed true that R500 has 10 Mbytes of eDram we know they 'sacrified' something like 90 MTransistors.
Now if we'd know the ratio between logic and edram density for R500 fabbing process we could estimate how many ALUs they 'sacrified' to have some eDram.
Since we don't know that ratio I should just shut up :)
May someone help me here? ;)
 
Bye the way , NAO , you can roughtly estimate 10MB without control logic. 30% from conctrol logic so 6-7MB. with 90Mtransistors. But now gottogo be back few days.
 
Link: I used the PS2 GS numbers to come up with a Xenon figure, LOL :)
GS has 4 megabytes of edram, with 35 MTransistors dedicated to it.
10/4*35 = 87.5, then I rounded that figure to 90 MTransistors ;)
 
nAo said:
About things to sacrifice in order to have some eDram onboard:
if it's indeed true that R500 has 10 Mbytes of eDram we know they 'sacrified' something like 90 MTransistors.
Now if we'd know the ratio between logic and edram density for R500 fabbing process we could estimate how many ALUs they 'sacrified' to have some eDram.
Since we don't know that ratio I should just shut up :)
May someone help me here? ;)

You'd probably have to work it out from die area rather than transistor count, since RAM have relatively tightly packed transistors compared to general logic.
 
ERP said:
You'd probably have to work it out from die area rather than transistor count, since RAM have relatively tightly packed transistors compared to general logic.
I would like to but I haven't any die area figure about edram and TMSC and it seems completely uncorrect to derive that kind of data from a completely different company (sony) using a completely different process that has been improved with a lot of revisions..
 
I said both game and hardware developers, and this is only one issue. Developers have succeeded in many others. However, I feel that game developers haven't pushed hardware developers hard enough, and hardware developers haven't delivered. I think raytracing is the first step in that direction, and the guys from Saarcor prove without a doubt it's a perfectly doable thing. I just wish the hardware guys would just do it, and the game guys would demand it without question from them. I don't see how compatilbility would be an issue. There should be little trouble in emulating a rasteriser with a raytracer. However the reverse is far from true, simply because raytracing is so superior.
 
For the same amount of tranistors needed for ray tracing i'm sure you could increase the raw power of all other areas of the gpu at least 50 fold .

Ray tracing is just to demanding right now. There are better areas to spend your transistor budget on .


I think alot of people just get a buzz word in thier head and don't understand that all it is , is marketing fluff . Let the developers do thier thing and you will see amazing results , don't play arm chair quarter back and insult them
 
I'd like to know that myself. I got a chance to play the thing about a year ago (I think) and it was damned impressive for being smaller than most of my Jpg files. How could they even store the geometry for all of that in 96K?

Later
 
Okay, I give up, I'm not going to write it up the Nth time why there's no reason to push raytracing in realtime applications...
 
ERP said:
You'd probably have to work it out from die area rather than transistor count, since RAM have relatively tightly packed transistors compared to general logic.
Area is, pretty much, all that is all that's of importance because it determines the cost of the chip.
 
For the same amount of tranistors needed for ray tracing i'm sure you could increase the raw power of all other areas of the gpu at least 50 fold .

Ray tracing is just to demanding right now. There are better areas to spend your transistor budget on .
I wouldn't entirely say that. Raytracing pipelines themselves are not large at all. A chip that does ordinary Whitted raytracing at 1024x768 in realtime would be less than 1/8th the size of your typical GPU. It's just that decent quality raytracing with some real shading flexibility that does decent antialiasing and goes beyond one or two depths of recursion requires a hell of a lot of raytracer pipes, and a lot of ancillary hardware (much the same way that the majority of die space for a single GPU rasterizer pipe is shader-related). Then there's the whole hell involved with memory access and having to have direct access to the entire scene data. That's basically where the bulk of your transistors are going to go.

As I recall, the predecessor to the current ART VPS chips didn't even have any specialized hardware. Rather, it was just a big collection of non-pipelined scalar FPUs, and specialized firmware that was effectively just multi-threaded BMRT. And yes, it was several times faster than CPU raytracing renders, and the chip ran at 50 MHz -- still not realtime, though. Don't really know for sure about the current ones.

The real demanding nature of raytracing is when you try to get into GI variants that just have huge performance demands if you want to get into realtime. By the time you're looking in that direction, the number of ray pipes you need is enormous.

I'm not going to write it up the Nth time why there's no reason to push raytracing in realtime applications...
Depends what you mean by that. If you mean it won't ever be needed, then I can't agree. If you mean, it's not necessary now, then sure. There's still a lot of room for GPUs to grow still, but the exponential trends they push cannot last indefinitely. The biggest issue is the simple fact that rasterizers hardware is not inherently suited to do just anything. The variety of tricks and fakes we need to pull do not all work together well. They all have limitations and not entirely dismissable corner cases. The patchwork that links them all together works and all, but when that library of interacting tricks that lie within the scope of a single project grows larger... well, that leads to fragility.
 
L_i_n_k said:
Arent we being conservative here, but anyways Here is a Pretty imressive game/tech demo imo, it takes 98k in zip but requires 500MB of ram.

http://www.filemirrors.com/search.src?file=kkrieger-beta.zip&getright=1

That's freaking amazing, smaller file than most Jpeg images and such a big thing once it's all loaded.
However, we're just moving the problem from one side to the other, this 96k file requires 500MB RAM, and RAM is much more expensive than storage, so really, although impressive, it's nothing more than a show off.
 
Back
Top