Slashdot Mirror
Sony's Monster Graphics Chip
GFD writes "EETimes Has an article about a monster (462-mm2!!) graphics chip discussed in a paper at the ISSC. The numbers are astounding such as 256 mbits of on chip memory. Barely manufacturable though..." I'd still love to see what that bugger can do... bet it still can't simulate realistic hair in real time ;)
I've just finished reading the article. A few thoughts spring to mind:
First of all, this sounds like the Emotion Engine hype all over again. It might be an amazing chip, but it'll probably just be "decent" when it finally gets here.
Secondly, don't expect to see this in quantity until 0.15/0.13 micron fabs get here. Remember the Emotion Engine. Fabbing a chip that big is a royal pain. It'll get much easier when finer linewidths shrink the die size.
Thirdly, CMOS fabrication processes can be optimized for good quality DRAM, or for good quality logic. Not both (without throwing lots of money at it). The two types of circuit have contradictory requirements for transistor characteristics. In practice, this has meant that DRAM-plus-core chips have either had slow cores or bulky, slow, hot DRAM.
The only saving grace is that most of the chip area will be DRAM. This means that most of it will be tolerant of manufacturing faults (you usually have more DRAM rows than you need, and cut out the faulty ones before packaging). This is the only thing that will let them fab a chip this size at all.
The chip should provide interesting perspective when it arrives (much as the Emotion Engine did), but I don't expect it to take the world by storm.
Toshiba has expressed interest in offering the 128-bit processor for high-end routers and switches.
For....graphics? "Hey, this is great!" "What are you talking about, we lost two whole subnets!?" "Yeah, but look at how beautifully those error messages are rendered"
--
ah kiss --- such nonsense.
>Therefore, logically, when we reach 50 million
>polygons/second in calculation for a graphics
>chip, it is effectively impossible to make the
>graphics quality any better without improving
>the quality of the screen.
Oh Bollocks. Just spitting a pixel to the screen has nothing to do with the overall quality of the image that is produced. Anti-aliasing. Motion blur. Depth of field. Programmable shading (no more of this gourand/phong with badly mapped textures etc etc). Don't even get me started ---- TONS of effects that can be incorporated. Hair, fur, skin, particles, atmospheric effects, lens effects, volume rendering effects, etc etc etc.
Until you can make a CG image indistingishable from a live source at that resolution there is TONS that can be improved.
Have u worked in the graphics biz? I have......
j
So this chip has the same fill rate, but 8x the RAM, only 2x the RAM ports, and 7x the complexity?
It sounds to me like Sony have just made this an 8x multitexturing part at *huge* expense. And an 8x multitexturing part with only 2x the internal bus for texture cache reloading. Slow.
And supersampled antialiasing will cost you 75% of your fillrate, since that isn't increased either.
I just don't understand who this chip is for.
"The numbers are astounding such as 256 mbits of on chip memory."
Wow, two hundred fifty six millibits of on chip memory. That's like, what, almost 1/20th of a byte?
Ok, the story is light on details and nobody else here seems to have any understanding so here is the real skinny. This is an expanded version of the GS (Graphic Synthesiser) chip in the PS2. I expect even the same clock speed, from the 75 million poly number. By the way, that number is a theoretical peak based on it taking 2 cycles to do triangle setup of a flat-shaded untextured polygon.
Your comment about triangles having 3 verts thus cutting the performance in half is wrong though. Tristrips get you pretty close to 1 vert/poly. Each time you kick a vert you use the previous two kicked verts to form your poly. Thus, a 20 poly strip only needs 22 verts. You are correct that texturing and shading require more setup time, however. Generally you're at 5 cycles of setup time and thus 30 million polys/sec.
2560 bit bus is because you have 16 functional units in parallel, thus 160 bits per unit. 32 bits framebuffer read, 32 bits framebuffer write, 32 bits Z buffer read, 32 bits z buffer write, 32 bits texture read giving 5x32 = 160 bits total. Note you need all these accesses to happen concurrently to fully render a pixel in 1 clock cycle. This is all internal to the chip, too. The external bus interface is 128 bits.
The advantage of having 32 megabytes of on-die memory is that you can generate many full-screen buffers in 32 bit and use them as texture sources for high-quality image processing effects like motion blur or depth of field or environment mapping. Think of that 32 megabytes as a big cache. You could store many more megabytes of texture in system memory and DMA them up to the GS for rendering as needed.
This latter fact is also true for PS2. I generally suggest that people think of the PS2's graphics chip (NOT the cpu core) as 16 Voodoo1s in SLI, overclocked to 150mhz, on a 32x AGP bus. To be sure, PS2 has some developer issues but lack of texture memory is not that high on the list.
The 'router' comment surely refers to the Emotion Engine itself. Sony developed that chip in a joint venture with Toshiba and it is manufactured in a fab owned by the Sony/Toshiba JV. It's essentially a 300MHz MIPS core with the ability to do lots of floating-point math in parallel.
I am surprised that this chip is only news now, Sony demonstrated this concept at the last SIGGRAPH (the GSCube machine). It's intended purpose is to replace render farms. Put 16 of these chips together and you could do semi-close-to-pixar rendering quality in semi-realtime. Good enough to preview animations and lighting and so on.
Graham
think the real push should start moving away from higher polygon rates and more towards greater visualization enhancements for each polygon. We're already dealing with cool things such as environmental bump mapping. I'm still waiting for the fully featured ray-tracing engine. I'd be perfectly happy with a scene that was only 30fps, 800x600, average number of polygons if I could just feel the glimmer of living light.
If you have decent calculation engines on-chip, you can use a silly polygon throughput to emulate nicer features that might be difficult to implement directly. Tesselate large polygons to make NURBS surfaces. Add multiple semitransparent "halos" for fancy lighting effects. Use various sneaky tricks to emulate volume effects like smoke and Ye Canonical Plasma Field. Etc.
You can do all of these in the main CPU, but it bogs down the CPU like crazy and saturates your system bus (sending all of those triangles to the chip). If you can get the chip to do it for you, then it'll look almost as good as real curved surfaces/lighting/etc, without hogging system resources (just rendering resources).
While a true hardware implementation of nifty features would be more efficient, the brute force approach lets you use mainly well-understood designs, and lets you patch bugs in firmware instead of needing a new chip revision.
No idea what Sony's actually going to do.