PS2 is based on a 32-bit MIPS core (plus the real powerhouses, the two 4x32-bit / 1x128-bit Vector Units), but the memory bus affair is more complex. The main RAM is in two 16-bit Rambus banks, then there's a lot of internal 128-bit, 64-bit and 16-bit buses in the Emotion Engine, then there's the 2560-bit monster bus to the embedded memory in the Graphics Synthesiser...
You are referring to project "CELL", later called "Grid". A joint project of IBM, Sony Computer Entertainment and Toshiba. Sony sees Playstation 3 in it, IBM sees networking gear and other implementations. While it's not terribly revolutionary it is funky, like an archipelago of programmable parallel execution units in a sea of bandwidth... Google gets you plenty of info.
I agree, but regarding Athlon some further credit should also go to the ex-Digital Alpha people who joined AMD and helped make the K7 architecture (not just the CPU to NB interface) so good:-)
Recently there was an interesting game between Kramnik (who beat Kasparov) and Deep Fritz, a multiproc derivative of the German Fritz 7 chess program (evaluated to be a better player than Deep Blue).
In contrast to Kasparov vs. Deep Blue, Kramnik was allowed to study the program beforehand and was allowed days off in the tournament for resting. In turn, the Deep Fritz team was allowed to change the program's opening strategies during the tournament.
The first half went to Kramnik 4-1 (3 victories, 2 draws), but then the DF team realised Kramnik had always exchanged queens early on to suit his favorite style (of playing strong positions with the strongest individual piece out), modified the program's opening strategy to be more careful with the queen, and the end result was a 4-4 tie.
Google may come up with something if somebody is actually interested in chess.:-P
"Particular application" is the key; Sun gear has certain strenghts. There's still some way to go before a single Linux instance can employ 100+ x86 processors effectively.
If Sun gets (Solaris) to the 4096-way they are (AFAIK) targeting with UltraSPARC IV, they have some more breathing room again.
Me too would hate to see Sun as just another IA32/IA64 system vendor...
I'm no expert, but I thought PRMan also heavily uses shader programs in addition to (or instead of) static textures, so with complex effects there can be quite a lot of FP math imvolved too.
Maybe he meant future Intel-based Xserves, not the Pixar rendering farm. Although I can't understand why Apple would waste resources on such a thing at this point, with IBM's PowerPC 970 arriving soon. Should be nicely performing and low-power for rack servers.
I don't remember it exactly or have a link handy... But I remember the computer system in the early Airbus aircraft consisted of four machines, each with two halves. While each of the four machines had specialised tasks, each was nevertheless capable of doing the others' tasks in case of malfunction; each computer ran different code for the same task. Furthermore, the two halves of each computer ran different code and the halves constantly monitored each other -- if results differed, another computer took over the failing task. So there was pretty good error checking and system redundancy.
Why the early Airbus planes do lead the disaster charts has mainly to do with pilot interface. It was possible to accidentally have the aircraft in "Cruise mode" or "Takeoff mode" at landing, and there was no loud and clear warning system -- this led to some crashes. Another related issue was the abundance of numerical information in place of the traditional round gauges -- you didn't notice a problem so quickly (at a glance), if at all. [Again no linkage, I read this in a book on aircraft disasters.] Due to poor interface design, the aircraft were very prone to human error, despite all the safeguarding automation.
Moot point, though. Obviously Boeing won't employ WinXP in the aircraft but firmly on the ground.
What PowerVR Series 2 (Neon250) and 3 (Kyro 1/2) did was just basic supersampling -- sampling and rendering at a higher rez, then scaling down to the display rez; Voodoo 5, Radeon 7500, Geforce 2 can all do that.
The difference with the PowerVRs is that they can do it a small tile at a time, instead of a full screen, because they sort all polygons into tiles beforehand ("deferred tiled rendering"). (The main reason for deferred rendering -- tiled or not -- is that because you know all polygons beforehand, you can zap the occluded polygons before the time-taking rasterising into pixels, i.e. you can eliminate the needless overdraw.)
The two types of sampling, super and multi, differ only on texture usage. Multisampling reuses the texture data for all samples (subpixels), while supersampling creates truly unique subpixels. Multisampling costs much less performance, but only supersampling helps with texture artefacts (aliasing) -- like the jaggies in the alpha-textured rails in Counter-Strike; however, anisotropic (non-uniform, perspective-adaptive) texture filtering negates texture artefacts, so multisampling is becoming dominant in gaming cards.
Whether the image is rendered larger then downsized (Geforce 2), or rendered into multiple buffers then combined (Voodoo 5), is irrelevant to whether the underlying method is multisampling or supersampling.
Both multisapling and supersampling can "freely" be implemented as ordered grid (fixed subpixel sampling points), rotated grid (fixed but the sample-point grid is rotated some degrees -- just catches the worst, most visible cases better), or stochastic pattern (random points). Radeon 9700 (2X to 6X) uses a clever hybrid, having a repertoire of pre-calculated random sampling patterns.
Hope this helps and doesn't come across as arrogant. I'm just an interested aficionado myself. You were right, FSAA ain't as simple as just as rendering and reducing.:-)
***
I'd also like to comment to the "who needs 2500 fps?" people. First off, 24 or 30 fps is good for movie/TV, because the individual frames are blurry (camera shutter has a measurable open time, effectively blending source data); but 60 fps is enough for computer games where every frame is instantaneous and razor-sharp. Some people claim they can tell between 60 and 75 fps -- I sure can tell between 40 and 60 fps. Second, nobody need 100+ fps, but show me a card that gives me 1600x1200 with 128-sample anisotropic and 16-sample FSAA (the "Holy Grail") in all near future "complex shaders for every pixel" games, and then I'll be satisfied. Not before...
***
But GFFX Ultra with the screaming dustbuster... good riddance. The consumers have spoken and been heard, I guess.
"Non-Uniform Memory Architecture/Access." Not sure what that implies, except that sometimes you need to have data that is "far away" in a different memory (CPU group) node and use it like it was local.
Like being able to ignore the speed diffrerences (although they affect perormance).
First off, I'm late here, but thanks for replying! Hope you come across this sometime browsing your posts list...
There is a difference. As I understand it, TAA is anti-aliasing (increasing the sample count / sampling frequency) in the temporal domain as opposed to spatial AA. An accumulation buffer is the technical method to implement the consept of TAA. An accumulation buffer can be used for more specific things also, such as the motion blur effect, depth of field effect, soft shadows, etc... (The stuff 3dfx evangelised for Voodoo5. Their "Tarolli buffer" was a proprietary implementation of a generic accumulation buffer.) You spot the slight difference in the hierarchy of things:-)
You're right, in OGL you can't do TAA within a single frame, for the reasons you described. But you can use the accumulation buffer to combine consequent finally-rendered frames to do TAA. There, you're just blending whole bufferfuls of pixel color data. -- Although with those specific "3dfx effects" such as motion blur you'd indeed need to remember poly info from scene to scene; I don't know how they did it internally (a multi-scene vertex buffer?), nor whether it worked in OGL at all. I know they performed their FSAA grid rotation by jittering the geometry slightly from frame to frame (scene to scene), so some inter-scene magic was done.
There's good articles on it at Beyond3D.com -> Articles -> T-buffer Investigated, if you're interested in gamming tech.
And all AFAIU, I'm no pro here, just a 3D aficionado:-)
Slashdot Mirror
"I read the first two books, but the movies were much better."
;-)
Huh?
Well, to each their own. You are probably a big Bad Taste fan
And not that Tolkien's books don't suck when compared to e.g. Robert E. Howard's masterful Conan series... Crom!
"Our suns have been highly reliable."
Whereas in our system we have only one sun, and the uptime has been horrible. It goes down every day.
[Sorry, had to.]
Just to add detail:
PS2 is based on a 32-bit MIPS core (plus the real powerhouses, the two 4x32-bit / 1x128-bit Vector Units), but the memory bus affair is more complex. The main RAM is in two 16-bit Rambus banks, then there's a lot of internal 128-bit, 64-bit and 16-bit buses in the Emotion Engine, then there's the 2560-bit monster bus to the embedded memory in the Graphics Synthesiser...
So PS2 is hard to classify by bus width.
You are referring to project "CELL", later called "Grid". A joint project of IBM, Sony Computer Entertainment and Toshiba. Sony sees Playstation 3 in it, IBM sees networking gear and other implementations. While it's not terribly revolutionary it is funky, like an archipelago of programmable parallel execution units in a sea of bandwidth... Google gets you plenty of info.
I agree, but regarding Athlon some further credit should also go to the ex-Digital Alpha people who joined AMD and helped make the K7 architecture (not just the CPU to NB interface) so good :-)
Recently there was an interesting game between Kramnik (who beat Kasparov) and Deep Fritz, a multiproc derivative of the German Fritz 7 chess program (evaluated to be a better player than Deep Blue).
:-P
In contrast to Kasparov vs. Deep Blue, Kramnik was allowed to study the program beforehand and was allowed days off in the tournament for resting. In turn, the Deep Fritz team was allowed to change the program's opening strategies during the tournament.
The first half went to Kramnik 4-1 (3 victories, 2 draws), but then the DF team realised Kramnik had always exchanged queens early on to suit his favorite style (of playing strong positions with the strongest individual piece out), modified the program's opening strategy to be more careful with the queen, and the end result was a 4-4 tie.
Google may come up with something if somebody is actually interested in chess.
Go Finland! :-)
Ah. Thanks for the insight!
Also look up the "KLAT" cluster supersomputer. It has a very cleverly routed, efficient network, with only three (IIRC) NICs per box.
They understood not everything has to connect to everything else. Wonder if their method is doable on a rack blade server?
... e?
My company has a render garden (too small to be a render farm) of a dozen or so Athlons.
Then I have a render-pot of one Athlon.
"Particular application" is the key; Sun gear has certain strenghts. There's still some way to go before a single Linux instance can employ 100+ x86 processors effectively.
If Sun gets (Solaris) to the 4096-way they are (AFAIK) targeting with UltraSPARC IV, they have some more breathing room again.
Me too would hate to see Sun as just another IA32/IA64 system vendor...
I'm no expert, but I thought PRMan also heavily uses shader programs in addition to (or instead of) static textures, so with complex effects there can be quite a lot of FP math imvolved too.
:-)
Thanks for the "Renderman" etymology.
Why not Apple?
Heck, why not 1024 iMacs!
Imagine a lovely field of sunflowers.
However, their site says RenderMan now offers raytracing as an additional tool for effects. (While it's still a scanline renderer.)
Maybe he meant future Intel-based Xserves, not the Pixar rendering farm. Although I can't understand why Apple would waste resources on such a thing at this point, with IBM's PowerPC 970 arriving soon. Should be nicely performing and low-power for rack servers.
"the first Unix ever to make it on the desktop"
What about e.g. *BSD (with KDE/Gnome)? Not a major, commercial OS like MacOS X, but still a desktop Unix.
I don't remember it exactly or have a link handy... But I remember the computer system in the early Airbus aircraft consisted of four machines, each with two halves. While each of the four machines had specialised tasks, each was nevertheless capable of doing the others' tasks in case of malfunction; each computer ran different code for the same task. Furthermore, the two halves of each computer ran different code and the halves constantly monitored each other -- if results differed, another computer took over the failing task. So there was pretty good error checking and system redundancy.
Why the early Airbus planes do lead the disaster charts has mainly to do with pilot interface. It was possible to accidentally have the aircraft in "Cruise mode" or "Takeoff mode" at landing, and there was no loud and clear warning system -- this led to some crashes. Another related issue was the abundance of numerical information in place of the traditional round gauges -- you didn't notice a problem so quickly (at a glance), if at all. [Again no linkage, I read this in a book on aircraft disasters.] Due to poor interface design, the aircraft were very prone to human error, despite all the safeguarding automation.
Moot point, though. Obviously Boeing won't employ WinXP in the aircraft but firmly on the ground.
What PowerVR Series 2 (Neon250) and 3 (Kyro 1/2) did was just basic supersampling -- sampling and rendering at a higher rez, then scaling down to the display rez; Voodoo 5, Radeon 7500, Geforce 2 can all do that.
:-)
The difference with the PowerVRs is that they can do it a small tile at a time, instead of a full screen, because they sort all polygons into tiles beforehand ("deferred tiled rendering"). (The main reason for deferred rendering -- tiled or not -- is that because you know all polygons beforehand, you can zap the occluded polygons before the time-taking rasterising into pixels, i.e. you can eliminate the needless overdraw.)
The two types of sampling, super and multi, differ only on texture usage. Multisampling reuses the texture data for all samples (subpixels), while supersampling creates truly unique subpixels. Multisampling costs much less performance, but only supersampling helps with texture artefacts (aliasing) -- like the jaggies in the alpha-textured rails in Counter-Strike; however, anisotropic (non-uniform, perspective-adaptive) texture filtering negates texture artefacts, so multisampling is becoming dominant in gaming cards.
Whether the image is rendered larger then downsized (Geforce 2), or rendered into multiple buffers then combined (Voodoo 5), is irrelevant to whether the underlying method is multisampling or supersampling.
Both multisapling and supersampling can "freely" be implemented as ordered grid (fixed subpixel sampling points), rotated grid (fixed but the sample-point grid is rotated some degrees -- just catches the worst, most visible cases better), or stochastic pattern (random points). Radeon 9700 (2X to 6X) uses a clever hybrid, having a repertoire of pre-calculated random sampling patterns.
Hope this helps and doesn't come across as arrogant. I'm just an interested aficionado myself. You were right, FSAA ain't as simple as just as rendering and reducing.
***
I'd also like to comment to the "who needs 2500 fps?" people. First off, 24 or 30 fps is good for movie/TV, because the individual frames are blurry (camera shutter has a measurable open time, effectively blending source data); but 60 fps is enough for computer games where every frame is instantaneous and razor-sharp. Some people claim they can tell between 60 and 75 fps -- I sure can tell between 40 and 60 fps. Second, nobody need 100+ fps, but show me a card that gives me 1600x1200 with 128-sample anisotropic and 16-sample FSAA (the "Holy Grail") in all near future "complex shaders for every pixel" games, and then I'll be satisfied. Not before...
***
But GFFX Ultra with the screaming dustbuster... good riddance. The consumers have spoken and been heard, I guess.
Mod this up!
(A dupe post about reacting to dupe articles. It's funny, laugh.)
"Non-Uniform Memory Architecture/Access." Not sure what that implies, except that sometimes you need to have data that is "far away" in a different memory (CPU group) node and use it like it was local.
Like being able to ignore the speed diffrerences (although they affect perormance).
"Enginuity"? Must be a phrase among local rocket scientists.
Mod parent up!
The "Total Ship Monitoring" system in the article was for maintenance, not combat control.
(Sheesh, "change or modify", what a gem... hope you get the difference intended.)
First off, I'm late here, but thanks for replying! Hope you come across this sometime browsing your posts list...
:-)
:-)
There is a difference. As I understand it, TAA is anti-aliasing (increasing the sample count / sampling frequency) in the temporal domain as opposed to spatial AA. An accumulation buffer is the technical method to implement the consept of TAA. An accumulation buffer can be used for more specific things also, such as the motion blur effect, depth of field effect, soft shadows, etc... (The stuff 3dfx evangelised for Voodoo5. Their "Tarolli buffer" was a proprietary implementation of a generic accumulation buffer.) You spot the slight difference in the hierarchy of things
You're right, in OGL you can't do TAA within a single frame, for the reasons you described. But you can use the accumulation buffer to combine consequent finally-rendered frames to do TAA. There, you're just blending whole bufferfuls of pixel color data. -- Although with those specific "3dfx effects" such as motion blur you'd indeed need to remember poly info from scene to scene; I don't know how they did it internally (a multi-scene vertex buffer?), nor whether it worked in OGL at all. I know they performed their FSAA grid rotation by jittering the geometry slightly from frame to frame (scene to scene), so some inter-scene magic was done.
There's good articles on it at Beyond3D.com -> Articles -> T-buffer Investigated, if you're interested in gamming tech.
And all AFAIU, I'm no pro here, just a 3D aficionado