Comparison of 6th generation game console hardware

Printable View

Show 40 post(s) from this thread on one page

01-26-2014, 05:56 AM
bakemono

Quote:

I think I have seen Amiga compared favorably to the PCE and MD, particularly for being able to display three actual background layers simultaneously. Also, the colors and capability for MOD players seems to leave the PCE or MD behind if I am not mistaken by too many exaggerated comments on the topic. From what I have seen of the Amiga 1000 I would be shocked to see a version of R-Type not surpass the PCE/TG16 game.

The Amiga has 4096 available colors which is a plus, but the color palette is only 32 entries. So your options are 1) one background layer with up to 5 bitplanes = 32 colors, 2) one background layer with 6 bitplanes and 64 colors, with the additional 32 colors being half the intensity of the original palette (called ExtraHalfBright mode), 3) one background layer with 6 bitplanes where each pixel can be one of 16 colors OR it can have one of the R/G/B components given with the other two being copied from the previous pixel (called HoldAndModify mode), 4) two seperate background layers with up to 3 bitplanes (8 colors) each (called dual-playfield).

The Agnus chip can step through a list of register changes to make on certain scanlines (called the Copper list) so mid-screen palette changes and other raster effects were pretty common since they don't necessarily take up any CPU time. I forget whether Copper takes any CPU memory bandwidth, but 5- and 6-bitplane screen modes do steal some bandwidth which slows the CPU down a bit.

Also, there are only 8 sprites, 16 pixels wide, but they can be as tall as the entire screen. So again, the copper list could be used to break-up one tall sprite into multiple smaller sprites by changing sprite registers during the display, but it takes CPU time to figure this stuff out, whereas it's done in hardware on other systems.

Sample playback is much better than PCE or MD but there are only 4 channels. To get more would mean software mixing which is demanding on a 7MHz 68000 so this is somewhat limiting.

Quote:

Which benchmarks did you use for these figures? I'm waiting for a PCI ATA 133 adapter to come in and then I can test all of these cards too. Also, do you have a best practice for swapping video cards? I remember crashing Win98SE by upgrading once, I am very worried that I won't be able to swap these cards today without reinstalling the OS.

My numbers are from the 3Dmark2001 fillrate and high-polygon-count tests. I have a 6GB HDD with Win98 installed on it that I had swapped into various machines. Changing video cards was no problem once I had found the right drivers. Changing motherboards would need an extra reboot or two for everything to sort itself out. Although in one case I ran a couple of benchmarks on a PCI 486 board and since the BIOS was so old it required modifying the partition table to match the different representation of the drive geometry. Then I had to change it back afterward so the drive was bootable on the newer motherboards.
02-23-2014, 05:21 PM
sheath

I'm sorry, I missed the above response. The last month has been unkind. Thanks for posting those performance figures from 3DMark 2001. I will do the same with my Celeron 300A and PIII 500 systems when I get a chance. At least having multiple systems test the same model cards should give us more data to work with and more real world results to compare to the specs.

In the meantime, I found some interesting tidbits about the PowerVR-2DC from an old Videologic document.

From Dreamcast Technical Pages
powervr2dc_features_wince.pdf

powervr2dc_features_wince.pdf (Z:\System Specs\Dreamcast)

PVR2-DC Features: (3-4)
Renders triangles, triangle strips, and quads.
Culling of back faces and tiny polygons.
ARGB Gouraud shading, flat shading.
Specular highlighting.
Perspective-correct mip-mapped texturing.
Texture clamping, wrapping, and mirroring.
Bilinear, trilinear, and anisotropic filtering.
Full-scene anti-aliasing.
Vertex fog and all table fog modes.
Per-pixel translucency sorting.
32-bit on-chip z-buffering.
Hardware clipping to a viewport.
640x480x24 maximum resolution.
RGBA 5650, 5551 and 444 texture formats.
YUV 422, 420 texture formats
8bpp and 4bpp paletized texture formats.
Bump mapping.
VQ texture compression.
Scene capture architecture.

Windows CE for PowerVR-2DC: (5)
Windows API Compatible (32-bit)
Direct X 5.0
VC++ 5.0

Vector Quantization (VQ) takes 256x265 textures, reduces to 2x2 tiles, to 128x128 array of indices in codebook. (8)

Larger textures compress better but are lossier, diminishing returns at 64x64.
Compression Ratios

Original Compressed Codebook Compression
Texture Size Texture Size Size (bytes) Ratio (1:n)
32x32 2048 256 2048 0.89
64x64 8192 1024 2048 2.67
128x128 32768 4096 2048 5.33
256x256 131072 16384 2048 7.11
512x512 524288 65536 2048 7.76
1024x1024 2097152 262144 2048 7.94
(9)

Bump Mapping:
Requires a two pass render.
Bump map contained in second texture.
Each texel (aka buxel) is a vector which is normal to the "bump".(11)

Optimized Textures
Non-linear video memory format (aka "twiddled"), slight performance hit on texture load, Bilinear filtering becomes free. All other textures are linear format, supports all texture modes.

I guess of particular interest in light of recent discussion is that the VQ compression only scales up based on texture size, so in order to get 8X compression the textures have to be 1024x1024, a huge texture for that generation if I am not mistaken. Also of note is that bump mapping requires a second pass, which may be why it was rarely used. Other than that I have a hard time seeing the PVR2-DC feature set as anything but fairly robust for the 6th generation.

I also was able to find an old multiplatform comparison chart that seems fairly accurate for the time, although some numbers are off or fail to note exceptions we have discussed here. Still, PC Vs Consoles did a great job considering this was way back in December of 2001. Based on the recent flame war, I mean tech discussion, over in Insert Coin, I'd say some here would contest the overall GFLOP performance listed for the Xbox and Gamecube versus that of the PS2. The Dhrystone MIPS ratings for each CPU is very interesting, and a spec I haven't seen before in a cross platform comparison. This makes it easier to compare with PC CPUs as well.
02-23-2014, 06:13 PM
Barone

Quote:

Originally Posted by sheath

In the meantime, I found some interesting tidbits about the PowerVR-2DC from an old Videologic document.

32-bit on-chip z-buffering.

It doesn't have a z-buffer.

Quote:

Originally Posted by sheath

I guess of particular interest in light of recent discussion is that the VQ compression only scales up based on texture size, so in order to get 8X compression the textures have to be 1024x1024, a huge texture for that generation if I am not mistaken.

I think most of the time most of the games didn't use 1024x1024 textures. 256x256 was already big for the time, 128x128 was more common in most of the DC games AFAIK.

Quote:

Originally Posted by sheath

Also of note is that bump mapping requires a second pass, which may be why it was rarely used.

Usually, you'd also be limited to one light source affecting the surface.

Quote:

Originally Posted by sheath

Based on the recent flame war, I mean tech discussion, over in Insert Coin, I'd say some here would contest the overall GFLOP performance listed for the Xbox and Gamecube versus that of the PS2.

Parallel processing is a key feature of the PS2 architecture which those tables and lists fail to contemplate. Oddly enough, industry seems to have moved in that direction for some esoteric reason.

Too bad that those tables with specs and theoretical numbers are always more important than the actual benchmarks using the vector units though...

There's a .doc version of that info here: http://www.cms.livjm.ac.uk/library/a...ole%20Spec.doc

Also:
"Multitexturing

One texture per polygon just isn't enough any more. The PS2 has fillrate to spare, and the dual context rendering architecture can draw two copies of every triangle for little more cost than one, so you are wasting the hardware if you have only a single texture stretched over your geometry. Xbox supports four layers, and Gamecube eight (although in practice you can only afford to use two or three while maintaining a good framerate)."

"This layer based approach to multitexturing does a good job of scaling across differences in hardware capabilities. Our PS2 projects are using two texture layers, with the gouraud alpha controlling a crossfade between them. On Gamecube we add a third multiply mode detail layer, while on Xbox the flexibility of pixel shaders lets the artists choose any possible combine modes for their three layers, with the fourth generally reserved for the programmers to do dynamic lighting or reflections."
http://www.gamasutra.com/view/featur...s_.php?print=1

rusty had already comment on the performance problems of the GC's architecture when doing multitexturing. Looks like that, despite rusty being a PS2 blind fanboy, Shawn Hargreaves agreed with him. Too bad Shawn became a MS whore and so his comments also worth nothing, despite his contributions varying from Allegro to XNA.
02-23-2014, 06:59 PM
zyrobs

Quote:

Originally Posted by Barone

...rusty being a PS2 blind fanboy...

Dude wrote full games on both the PS2 and Gamecube (and also Xbox and DC). I'd say he's about the only one on this entire board who can objectively say if one machine was better than the other.
02-23-2014, 07:28 PM
Barone

Quote:

Originally Posted by zyrobs

Dude wrote full games on both the PS2 and Gamecube (and also Xbox and DC). I'd say he's about the only one on this entire board who can objectively say if one machine was better than the other.

He's supposed to have "fails in his reasoning". Go figure.

And here's another ~~flame~~ article with a benchmark to be ignored/dismissed/blamed/not comprehended:

http://www.gamepilgrimage.com/sites/...nchmarks/1.png

http://www.gamepilgrimage.com/sites/...nchmarks/2.png

http://www.gamepilgrimage.com/sites/...nchmarks/3.png

http://www.gamepilgrimage.com/sites/...nchmarks/5.png

Full ~~insult~~ article download: https://drive.google.com/file/d/0B0c...it?usp=sharing
02-24-2014, 10:27 AM
sheath

Quote:

Originally Posted by Barone

It doesn't have a z-buffer.

I'm fairly sure they were trying to speak in understandable terms about the benefits of the tile based renderer culling like a 32-bit z-buffer without a hit to performance or VRAM.

Quote:

Originally Posted by Barone

I think most of the time most of the games didn't use 1024x1024 textures. 256x256 was already big for the time, 128x128 was more common in most of the DC games AFAIK.

These recent discussions are the first time I have seen texture sizes discussed in relation to 6th generation hardware. Didn't we see that PS2 GS stalls were caused by the dev trying to use 256x256 textures without slicing them up into 32x32 first? Trying to read Videologic's chart, it looks like all of the memory sizes are in bytes but only one column makes this explicit. If they are all in bytes then a 128x128 texture is listed at 32768 bytes (32KB), which is only a 20 byte per pixel texture for some reason. After VQ compression this goes down even further to 4096 bytes (4KB). Similarly a 256x256 texture is listed at 20 bytes per pixel, or 1310720 bytes (1280KB) which is down to 16384 bytes (16KB) after VQ compression.

I think we quite pessimistically gave the Dreamcast only 2MB left over in peak polygon performance games earlier in this thread. That would mean 128 256x256 textures or 512 128x128 textures with VQ compression. These numbers might be half if a 40 byte texture became standard after this article was published.

I also don't know if the texture compression only benefited streaming from Main RAM and the textures still had to be uncompressed in VRAM before they were displayed. If so then the discussion becomes about streaming texture detail on a per frame basis from main ram at 800MB per second rather than how many textures can fit into 1-2MB of VRAM.

Quote:

Originally Posted by Barone

Usually, you'd also be limited to one light source affecting the surface.

Considering how rarely we saw the effect in games prior to 2003 I'd take that rather than nothing at all. Certain Shenmue 2 comparisons show that the Dreamcast version used prebaked real time changing textures for building shadows, polygonal shadows for NPCs and modifier volume shadows for the main character. So lighting had the potential for multiple sources/objects on the Dreamcast if need be even if bump mapped objects were always by necessity limited to close ups.

Quote:

Originally Posted by Barone

Parallel processing is a key feature of the PS2 architecture which those tables and lists fail to contemplate. Oddly enough, industry seems to have moved in that direction for some esoteric reason.

Too bad that those tables with specs and theoretical numbers are always more important than the actual benchmarks using the vector units though...

Are you referring to the experiment document that shows the PS2 with VUs can hang with a Pentium 4? The one that everybody in the ~~troll party~~ insert coin discussion overlooked because it didn't include the exact CPUs in the Gamecube and Xbox?

Anyway, if this comparison list truly included the VUs, which I think that GFLOP projection must, what would it look like in your view? I think if it included the requirement of hard fought parallelism the list should have separate processing capabilities listed for just the MIPS core, plus the MIPS and FPU, MIPS and 1/2 VUO and 5% VU1 (as seen in Sony's 2003 doc) and so on. I would even say that the dates of developer comments which include how much of the vector units were utilized should be marked in said comparison list or spec sheet.

Before any red cards are flashed, I would do the same thing to the Saturn, Xbox 360, and PS3 if I had enough data to cite. I like how these PCvConsole lists separate the CPU's Integer and Floating Point performance from the GPU performance of consoles that rely on Hardware T&L. I think that is only fair.

Quote:

Originally Posted by Barone

There's a .doc version of that info here: http://www.cms.livjm.ac.uk/library/archive/mike%20baskett%20(2)/CD1012/All/Lecture%202/Video%20Games%20Console%20Spec.doc

Sweet, if I could only get Drupal or Godaddy to stop crashing as I try to create a new content type for hardware specs now.

Quote:

Originally Posted by Barone

Also:
"Multitexturing

One texture per polygon just isn't enough any more. The PS2 has fillrate to spare, and the dual context rendering architecture can draw two copies of every triangle for little more cost than one, so you are wasting the hardware if you have only a single texture stretched over your geometry. Xbox supports four layers, and Gamecube eight (although in practice you can only afford to use two or three while maintaining a good framerate)."

"Little more than the cost of one" is a recurring statement now, but somehow the second pass polygons are indicative of true polygon performance of the system as well. I think this matter should be handled delicately, as the marketing departments (that's right, I didn't start it) have made polygon counts the sacred cow of the generation.

Quote:

Originally Posted by Barone

"This layer based approach to multitexturing does a good job of scaling across differences in hardware capabilities. Our PS2 projects are using two texture layers, with the gouraud alpha controlling a crossfade between them. On Gamecube we add a third multiply mode detail layer, while on Xbox the flexibility of pixel shaders lets the artists choose any possible combine modes for their three layers, with the fourth generally reserved for the programmers to do dynamic lighting or reflections."
http://www.gamasutra.com/view/featur...s_.php?print=1

That stood out to me as well. Does this mean that the Xbox and Gamecube have 1/3rd and 2/3rds more polygons available? I'm pretty sure nobody would risk that comparison since the GPUs handle the second through third passes and almost everything else on chip.

The bezier patches part is interesting, it seems like the writer only views them as a development shortcut even while he claims "the PS2 vector unit" is especially suited for them. I'm guessing we can't tell by looking at the games whether we are looking at a bezier patched model or a hand designed high polygon count curved model. Not that I think there is technically much of a difference, aside from the amount of time/resources spent on the model creation and the uniqueness of the model(s) that is.

Quote:

Originally Posted by Barone

rusty had already comment on the performance problems of the GC's architecture when doing multitexturing. Looks like that, despite rusty being a PS2 blind fanboy, Shawn Hargreaves agreed with him. Too bad Shawn became a MS whore and so his comments also worth nothing, despite his contributions varying from Allegro to XNA.

That's right, it is abundantly clear that stating a preference other than what the reader came in the door with is bias while stating a preference in agreement with the reader's prejudice is unbiased.
02-24-2014, 10:41 AM
rusty

Quote:

Originally Posted by sheath

I also don't know if the texture compression only benefited streaming from Main RAM and the textures still had to be uncompressed in VRAM before they were displayed.

They stayed compressed in VRAM and the PVR2 did the decompression during the texture fetch (which didn't happen until the tiles were "finalised").
02-24-2014, 11:42 AM
Barone

Quote:

Originally Posted by sheath

I'm fairly sure they were trying to speak in understandable terms about the benefits of the tile based renderer culling like a 32-bit z-buffer without a hit to performance or VRAM.

That (their statement) is an awful stretch then and still technically wrong since the lack of a z-buffer makes some effects a lot harder or impossible to perform.

Quote:

Originally Posted by sheath

Didn't we see that PS2 GS stalls were caused by the dev trying to use 256x256 textures without slicing them up into 32x32 first?

It's not a 0 or 1 case like that AFAIK. 32x32 was optimal but it doesn't mean that the GS would stall each and every time when using bigger textures.

Quote:

Originally Posted by sheath

I also don't know if the texture compression only benefited streaming from Main RAM

On the DC you have to use DMA copies to transfer textures from the main RAM to the VRAM AFAIK, unlike PS2/GC/Xbox.

Quote:

Originally Posted by sheath

and the textures still had to be uncompressed in VRAM before they were displayed.

In terms of programming, I don't think so.

Quote:

Originally Posted by sheath

Are you referring to the experiment document that shows the PS2 with VUs can hang with a Pentium 4? The one that everybody in the ~~troll party~~ insert coin discussion overlooked because it didn't include the exact CPUs in the Gamecube and Xbox?

That and the dot product comparison showing the VU0 outperforming a PIII 600 MHz by a wide margin (by that test, the VU0 would be roughly equivalent to a PIII 1.0+ GHz for such task) from 4 to 16 element vectors.

Quote:

Originally Posted by sheath

Anyway, if this comparison list truly included the VUs, which I think that GFLOP projection must, what would it look like in your view? I think if it included the requirement of hard fought parallelism the list should have separate processing capabilities listed for just the MIPS core, plus the MIPS and FPU, MIPS and 1/2 VUO and 5% VU1 (as seen in Sony's 2003 doc) and so on. I would even say that the dates of developer comments which include how much of the vector units were utilized should be marked in said comparison list or spec sheet.

I'm not criticizing the list or the comparison tables themselves; 'cause those are pretty good IMO.
I'm just saying that it's like the SUPERior NES thing all over again in some extent.

The specs may suggest that the PS2 would be killed dead without hardware support for texture compression, while it could use VQ-based schemes in the vector unit without much trouble.
The specs may suggest that the far superior MIPS rate of the GC's CPU would also kill the PS2 dead. However, the far better efficiency of the VU0 when running micro-code is not be taken into account.
The specs state that the GC has an 8X advantage over the PS2 in terms of multitexturing, which seems to be a bit far from the reality according to the developers.
The specs show but most people seem to ignore/not realize that 16 of the 40 MB of GC's RAM are pretty dead for material streaming since it's used as audio RAM and has pretty low bandwidth. So, you have useful 24 MB of system RAM on the GC against useful 32 MB of system RAM on the PS2.
...

Quote:

Originally Posted by sheath

"Little more than the cost of one" is a recurring statement now, but somehow the second pass polygons are indicative of true polygon performance of the system as well.

So, in your opinion, only the most expensive-to-render polygons should count?

Quote:

Originally Posted by sheath

That stood out to me as well. Does this mean that the Xbox and Gamecube have 1/3rd and 2/3rds more polygons available?

IDK how the "detail layer" is actually rendered on the GC and how it impacts the polygon count.
For the Xbox, the 4th layer sounded like a serious advantage.

Quote:

Originally Posted by sheath

The bezier patches part is interesting, it seems like the writer only views them as a development shortcut even while he claims "the PS2 vector unit" is especially suited for them. I'm guessing we can't tell by looking at the games whether we are looking at a bezier patched model or a hand designed high polygon count curved model. Not that I think there is technically much of a difference, aside from the amount of time/resources spent on the model creation and the uniqueness of the model(s) that is.

Sounds like the PS2 VUs specialized operations are seen as disadvantages by you.
02-24-2014, 12:03 PM
sheath

Quote:

Originally Posted by Barone

That (their statement) is an awful stretch then and still technically wrong since the lack of a z-buffer makes some effects a lot harder or impossible to perform.

Those disadvantages are certainly worth noting. I would put this under the hazards of being brief, you imply malicious intent or incompetence.

Quote:

Originally Posted by Barone

It's not a 0 or 1 case like that AFAIK. 32x32 was optimal but it doesn't mean that the GS would stall each and every time when using bigger textures.

While large textures causing the GS to stall may not be black and white, though Sony's doc more than implies it is, they certainly are a reliable problem based on the evidence on the table.

Quote:

Originally Posted by Barone

On the DC you have to use DMA copies to transfer textures from the main RAM to the VRAM AFAIK, unlike PS2/GC/Xbox.

Which means what exactly to the bandwidth constraints?

Quote:

Originally Posted by Barone

That and the dot product comparison showing the VU0 outperforming a PIII 600 MHz by a wide margin (by that test, the VU0 would be roughly equivalent to a PIII 1.0+ GHz for such task) from 4 to 16 element vectors.

I don't think anybody in their right mind would put the EE against the PII 733Mhz alone for gaming performance. I'm pretty sure we established that the SH4 was even significantly better for game related calculations.

Quote:

Originally Posted by Barone

The specs may suggest that the PS2 would be killed dead without hardware support for texture compression, while it could use VQ-based schemes in the vector unit without much trouble.

We have first and third party developer quotes explaining how most games use palettized textures to save the GS from itself. I would put that at the top of the list before VQ.

Quote:

Originally Posted by Barone

The specs may suggest that the far superior MIPS rate of the GC's CPU would also kill the PS2 dead. However, the far better efficiency of the VU0 when running micro-code is not be taken into account.
The specs state that the GC has an 8X advantage over the PS2 in terms of multitexturing, which seems to be a bit far from the reality according to the developers.

That 8X multipass thing needs to be contextualized with the dev quotes about how any passes before the framerate suffers I agree. As for the Vector Units making up for any perceived deficiency in the CPUs, you seem to be ignoring the hardware processing capabilities of the GPUs for the other systems. I know you aren't, but since we are jumping to conclusions based on omissions there it is.

For my part I have always shown the PS2 as a system that depended almost entirely on the CPU and its on die processing capabilities to push 3D, while the later 6th gen consoles relied more heavily on the GPU's processing capabilities. I seem to be getting lumped in with "typical" forum "Sega fans" though.

Quote:

Originally Posted by Barone

The specs show but most people seem to ignore/not realize that 16 of the 40 MB of GC's RAM are pretty dead for material streaming since it's used as audio RAM and has pretty low bandwidth. So, you have useful 24 MB of system RAM on the GC against useful 32 MB of system RAM on the PS2.
...

I am fairly certain everything I have posted in this thread listed the different RAM types. I admit I haven't dug very deeply into how the different RAM is supposed to function at peak, it all read like it was dependent on the developer to make optimizations though.

Quote:

Originally Posted by Barone

So, in your opinion, only the most expensive-to-render polygons should count?

I am leaning toward counting them only as much as they weigh in resources, and even then only in the context of systems with better GPUs not needing more polys for effects in the first place.

Quote:

Originally Posted by Barone

IDK how the "detail layer" is actually rendered on the GC and how it impacts the polygon count.
For the Xbox, the 4th layer sounded like a serious advantage.

Quote:

Originally Posted by Barone

Sounds like the PS2 VUs specialized operations are seen as disadvantages by you.

The heavy requirement on the developer and the obvious difficulty in getting the VUs to function even at half efficiency is a technical disadvantage. Listing their theoretical peaks without that context is pure biased fabrication on the part of everyone who does it.
02-24-2014, 12:06 PM
rusty

Quote:

Originally Posted by sheath

The bezier patches part is interesting, it seems like the writer only views them as a development shortcut even while he claims "the PS2 vector unit" is especially suited for them. I'm guessing we can't tell by looking at the games whether we are looking at a bezier patched model or a hand designed high polygon count curved model.

I missed this part until Barone pointed it out.

Bezier patches as a development shortcut? Not so much a shortcut, but more a choice in terms of cost for computation. What Shawn is talking about is how easy it is to dynamically compute the polygons when tessellating a Bezier surface compared to using sub-division surfaces. When dealing with multiple sub-div surfaces close together, you need to know all the information about surfaces that are next to each other to solve issues with gaps that appear due to tessellation (because it's based on the mid-points of the cage).

With Bezier patches, that's often not the case. Even if you have to fill in gaps between two neighboring surfaces, all you need to know about are the neighboring splines and that's a small amount of data. Something like 6 or 8 control points depending on the Bezier type.

Quote:

Originally Posted by sheath

Not that I think there is technically much of a difference, aside from the amount of time/resources spent on the model creation and the uniqueness of the model(s) that is.

There's a quite a bit difference. The great thing about high order surfaces such as Bezier patches is that you can do dynamic level of detail, which means you don't have to store as much data. You can also get a very large amount of triangles for that very small set of data. And this is what the PS2 was really built to do and it's why the Vector Units (in particular VU1) work the way that they do. This is what Shawn means by saying "the PS2 vector unit is especially suited to them".

Instead of a few jarring LOD stages on the bike cowling, you end up with a truly smooth progression of detail. And all from a very minimal data set.
02-24-2014, 12:29 PM
rusty

Quote:

Originally Posted by sheath

While large textures causing the GS to stall may not be black and white, though Sony's doc more than implies it is, they certainly are a reliable problem based on the evidence on the table.

You had similar issues on XBox and GC. If you read outside of the texture cache, you ended up with a stall. It's just that the cache on those machines was associative where as the GS cache was a block device that split VRAM into 32x32 blocks. You could end up with texture read stalls on the GC and XBox as easy as you would on PS2. It just happened under different conditions.

Quote:

Originally Posted by sheath

For my part I have always shown the PS2 as a system that depended almost entirely on the CPU and its on die processing capabilities to push 3D, while the later 6th gen consoles relied more heavily on the GPU's processing capabilities. I seem to be getting lumped in with "typical" forum "Sega fans" though.

I think you're either mis-representing or mis-interpreting the system design. On the PS2, the Emotion Engine was the MIPS main core, the vector units, the GS, 4MB of VRAM and the satellite units such as the integer decode unit. They were all on the same die.

For rendering you HAD to use VU1. It is analogous to the hardware T&L unit on the Flipper, or the vertex shader units on the XBox. VU1's only job, was to transform and feed data to the GS. You could back it up with VU0 if you had to (it had a direct connection to VU1) but it wasn't required.

Quote:

Originally Posted by sheath

The heavy requirement on the developer and the obvious difficulty in getting the VUs to function even at half efficiency is a technical disadvantage. Listing their theoretical peaks without that context is pure biased fabrication on the part of everyone who does it.

I wouldn't say that it was difficult to get the VU's to function at more than half efficiency. Sure, you had to write assembler code to use them (there was a vector C tool available at the end too) but it was never really that hard. And besides....the only way to use paired singles on the GC was to write assembler to use those instructions. The hardest part was making sure that the system was balanced; that you were only processing just enough data to feed the next system so that it didn't have to wait around. And that was difficult until the performance analyzer came about because you had no way to measure that sort of thing. Once the PA kit appeared, it was pretty plain sailing.

For VU0 code, you could use the unit it in co-processor mode. The MIPS core would issue instructions to VU0, and so that made prototyping your code pretty straight forward and even at 50% of the speed of microcode, it was still pretty quick. Then you would run your code through the PA kit, look at what was doing the most work and implement parallel VU0 microcode/MIPS code in order of importance. Some times the real speed up came from staying off the main EE bus and just doing stuff inside of scratch pad.

**edit** There was this really nice VU assembler editor that somebody had written. You wrote your VU code in two columns, with the upper and lower instructions side by side. What this editor would do was, as you were writing code, it would show you where stalls were going to happen if one execution pipe was relying on the result from the other. It was such a simple thing, but it made life much easier, especially at 11pm at night when you were trying to meet your schedule.
02-24-2014, 01:01 PM
sheath

Quote:

Originally Posted by rusty

You had similar issues on XBox and GC. If you read outside of the texture cache, you ended up with a stall. It's just that the cache on those machines was associative where as the GS cache was a block device that split VRAM into 32x32 blocks. You could end up with texture read stalls on the GC and XBox as easy as you would on PS2. It just happened under different conditions.

Interesting. Did these texture read stalls on the Gamecube and Xbox require 1st party document releases to help developers figure out what was going wrong?

http://www.sega-16.com/forum/images/misc/quote_icon.png Originally Posted by sheath http://www.sega-16.com/forum/images/...post-right.png

For my part I have always shown the PS2 as a system that depended almost entirely on the CPU and its on die processing capabilities to push 3D..."

Quote:

Originally Posted by rusty

I think you're either mis-representing or mis-interpreting the system design. On the PS2, the Emotion Engine was the MIPS main core, the vector units, the GS, 4MB of VRAM and the satellite units such as the integer decode unit. They were all on the same die.

As far as I know the MIPS and VUs are on the same, what, sub die on the main ASIC. Whatever we want to call that is fine with me. My point wasn't about how many processors and assistant chips were on the same die, but that the PS2 relies on the CPU's processing capabilities rather than the GPU for 3D graphics.

Quote:

Originally Posted by rusty

For rendering you HAD to use VU1. It is analogous to the hardware T&L unit on the Flipper, or the vertex shader units on the XBox. VU1's only job, was to transform and feed data to the GS. You could back it up with VU0 if you had to (it had a direct connection to VU1) but it wasn't required.

I got the VUs mixed up again, VU1 was the one that was only used to 56% by 2003, VU0 was at 2% (pg14). Again, and I don't know how to be more completely bluntly clear about this, I have always known that the PS2 required the CPU to be fully utilized, including the VUs, in order to be competitive with the Xbox and Gamecube polygon wise or effects wise. How in the world my posts keep resulting in the same "you don't seem to understand the PS2 has VUs" statements is the only thing I am confused about.

Quote:

Originally Posted by rusty

I wouldn't say that it was difficult to get the VU's to function at more than half efficiency. Sure, you had to write assembler code to use them (there was a vector C tool available at the end too) but it was never really that hard. And besides....the only way to use paired singles on the GC was to write assembler to use those instructions. The hardest part was making sure that the system was balanced; that you were only processing just enough data to feed the next system so that it didn't have to wait around. And that was difficult until the performance analyzer came about because you had no way to measure that sort of thing. Once the PA kit appeared, it was pretty plain sailing.

I'm not trying to use your words against you, but I will need you to clarify. How does the above mesh in your mind with:
"... But the machine was just such a beast under the hood. A Beast that took a lot of effort of get the simplest things up and running, but a still a beast all the same. ..."

That and your other comments about spending large portions of the development cycle just optimizing micro code and assembly for the PS2 could easily be read as a contradiction with the above statement. Also, when was the performance analyzer for the PS2 released to third parties?

Quote:

Originally Posted by rusty

For VU0 code, you could use the unit it in co-processor mode. The MIPS core would issue instructions to VU0, and so that made prototyping your code pretty straight forward and even at 50% of the speed of microcode, it was still pretty quick. Then you would run your code through the PA kit, look at what was doing the most work and implement parallel VU0 microcode/MIPS code in order of importance. Some times the real speed up came from staying off the main EE bus and just doing stuff inside of scratch pad.

That sounds like a nice feature to free up the MIPS, I wonder if Sony viewed this as the 2-8% usage or something else. Also from the previously linked Sony document:
"pg 20
Reaching for the Limits of PS2 Performance - How Far Have We Got?
©2003 Sony Computer Entertainment Europe.
VU1 Usage
•
Should run almost 100% of the time
•
Often stalls on textures
•
Often stalls on big polygons
–
Subdivide when possible (e.g. particles)
•
Don’t overdo clipping"

So the games pulled up to the time of this research in 2003 used 2-8% of the VU0, and VU1 was still needing further explanation to avoid the above pitfalls. pg 29 advocates VU0 usage as you are describing, or specifically for skinning, testing visibility, AI, physics and particles specifically to prevent the MIPS from stalling. pg 32 summarizes the article to say that "most games still don't use VU0" and that most games are using 2-5 million polygons per second (aka horrible mid gen Dreamcast land for the Insert Coin crowd).
02-24-2014, 03:54 PM
rusty

Quote:

Originally Posted by sheath

Interesting. Did these texture read stalls on the Gamecube and Xbox require 1st party document releases to help developers figure out what was going wrong?

Sure. How are you going to know about this stuff is it's not document? If you don't know what the hardware is doing and the documentation is not telling people about it, the hardware manufacturer has to publish those docs. I work for one of the big three hardware manufacturers. My particular specialty is performance on our hardware and this is something you often come up against. Either the hardware isn't documented at all/well enough or it's documented but no bugger knows where those docs are located.

Quote:

Originally Posted by sheath

As far as I know the MIPS and VUs are on the same, what, sub die on the main ASIC. Whatever we want to call that is fine with me. My point wasn't about how many processors and assistant chips were on the same die, but that the PS2 relies on the CPU's processing capabilities rather than the GPU for 3D graphics.

Then you know more than I do about the die layout :) But is that such a big deal? The VU is still slaved to the GPU and has immediate access to it. I'm not really sure what it is you're trying to prove, or the relevance. It doesn't matter where the VU was located; its only job was to transform data and push triangles to the GS. For all intents and purposes, it was part of the rendering pipe-line and in principal, part of the GPU.

Quote:

Originally Posted by sheath

I got the VUs mixed up again, VU1 was the one that was only used to 56% by 2003, VU0 was at 2% (pg14). Again, and I don't know how to be more completely bluntly clear about this, I have always known that the PS2 required the CPU to be fully utilized, including the VUs, in order to be competitive with the Xbox and Gamecube polygon wise or effects wise. How in the world my posts keep resulting in the same "you don't seem to understand the PS2 has VUs" statements is the only thing I am confused about.

Yeah, but that was from 2003. I had finished work on my first PS2 game by 2002 and the results of that presentation would have been from the first two years of European development for non-launch titles. While I wrote a lot of animation and physics code on VU0, I remember one of the smartest guys (a PhD in Theoretical Astrophysics) in the team just not "getting" the system even though he thought that he did. And it was awful. He wrote this apparently awesome ray-casting code for VU0 that would do NOTHING for long periods of time while the MIPS core would gather data and then suddenly jump into life.

"One ray-cast per frame is the best you'll ever get on this fucking horrible system" he proclaimed. Two years later, we were doing 120 ray-casts on a much more complex scene at 60fps.

Quote:

Originally Posted by sheath

I'm not trying to use your words against you, but I will need you to clarify. How does the above mesh in your mind with:
"... But the machine was just such a beast under the hood. A Beast that took a lot of effort of get the simplest things up and running, but a still a beast all the same. ..."

Please don't apologize. It's a good point. Having to make a lot of effort is not the the same as being difficult, at least, not in my view. By effort I mean planning, and bench marking different ideas and features to poke away at the stuff that the hardware documents and sdk documents don't explain, like how the system should be used. If you were fairly intelligent, you'd figure a lot of that from looking at the system as a whole. The PS2 wasn't N64 difficult where no matter what you did, the GPU had bus priority so you were fucked six ways from Sunday no matter how good your code was. On the PS2, you always felt like you had another hardware feature that could help out.

So by effort, I meant that you had to really design your code first. You weren't a rock star "coder". You found yourself being a proper, boring software engineer.

Quote:

Originally Posted by sheath

That and your other comments about spending large portions of the development cycle just optimizing micro code and assembly for the PS2 could easily be read as a contradiction with the above statement.

Hmm....that depends. This is more a reflection on the tools, rather than the hardware. I came from a low level background, although I also spent a lot of time writing tools and higher level stuff. In fact, most of the industry at that point had a low level background and still looked at C as being a complete luxury. A lot of the guys who were my age, had just come from University (I didn't go to Uni) weren't from the same background as me. And for most of them, the low level nature of the tools for the PS2 was something beyond (or beneath) them.

It's wasn't so much about optimizing micro code. That was pretty straight forward. It was making sure that you had everything running in parallel without stuff blocking or waiting for data. Which is the big trick on modern console hardware as it happens. It was really about tweaking the numbers...like how much data to process to balance the MIPS core and VU0.

Quote:

Originally Posted by sheath

Also, when was the performance analyzer for the PS2 released to third parties?

Geez...I didn't see one until 2003. I'm pretty sure that other devs doing stuff for Sony had it before then though.

Quote:

Originally Posted by sheath

That sounds like a nice feature to free up the MIPS, I wonder if Sony viewed this as the 2-8% usage or something else.

I think that it was things like I previously mentioned on that awful ray-cast implementation. It's people not really getting how the system was supposed to be leveraged.

Quote:

Originally Posted by sheath

Also from the previously linked Sony document:

I'll comment one by one,

Quote:

Originally Posted by sheath

Should run almost 100% of the time

This is a balance issue. VU1 and the GS should be running in parallel and with no interruptions. If it isn't, it means you've not done your homework and just sat back and been impressed with how quickly you can transform a packet of vertices without considering what's going on with the GS. Or you've chosen a simple single buffered approach to VU1/GS workload.

Quote:

Originally Posted by sheath

Often stalls on textures

Could be improper GS cache alignment, polys that straddle texture cache blocks, or small triangles that are using the incorrect MIP/not using MIP mapping.

Quote:

Originally Posted by sheath

Often stalls on big polygons
Subdivide when possible (e.g. particles)

Again, a GS cache issue.

Quote:

Originally Posted by sheath

Don’t overdo clipping"

Clipping was done on VU1. I remember one really smart guy who had access to PS2 before I did, and all his VU1 code was limited because put every triangle through clipping even if it didn't need to be. We all just thought 'that's the way you do it" because other graphics hardware put every triangle through it's clip stage, right? Instead, the trick was to have clipping and non-clipping microcode, project the bounding volume of the object into clip space during scene visibility checks and determine which microcode to use.

Quote:

Originally Posted by sheath

So the games pulled up to the time of this research in 2003 used 2-8% of the VU0, and VU1 was still needing further explanation to avoid the above pitfalls. pg 29 advocates VU0 usage as you are describing, or specifically for skinning, testing visibility, AI, physics and particles specifically to prevent the MIPS from stalling. pg 32 summarizes the article to say that "most games still don't use VU0" and that most games are using 2-5 million polygons per second (aka horrible mid gen Dreamcast land for the Insert Coin crowd).

It would have been games release in the mid-2002/early 2003 period. I'm betting my first PS2 game was one of them *shudder*. The thing was not that the hardware was difficult; people just didn't get its parallel nature and Sony had a really difficult time in promoting that among developers.
02-24-2014, 03:54 PM
Chilly Willy

Quote:

Originally Posted by Barone

On the DC you have to use DMA copies to transfer textures from the main RAM to the VRAM AFAIK, unlike PS2/GC/Xbox.

This one I can refute. You can copy data to VRAM using the CPU just fine. The SH4 also has store queues that allow for faster CPU transfer of data. I used that in my Doom for DC port.
02-24-2014, 05:08 PM
Barone

I was referring to the term "streaming" (from the main RAM).
sheath had said: "If so then the discussion becomes about streaming texture detail on a per frame basis from main ram at 800MB per second rather than how many textures can fit into 1-2MB of VRAM."
The DC isn't supposed to work like that AFAIK.

"Reverend-IGN: Tech fun again!: In the last chat you said that low video RAM was limiting things like the textures and anti-aliasing. Isn't there some way you can take some Main RAM and assign it to be video RAM? And if not, why?
DavidBioWare: Yes, the video memory situation has improved dramatically since last time.
DavidBioWare: The problem was that there was too little video memory to fit all our textures, and the machine can't use a texture unless it's specifically in video memory.
DavidBioWare: What we've found since then is that the PS2 has enough bus bandwidth to transfer each texture from main memory to video memory as it's needed.
DavidBioWare: That's on the order to 100s of Mb per second. We hadn't anticipated that the PS2 had that kind of brute horsepower on its bus. No other machine I've used does, including any PC or the Dreamcast. "
http://www.ign.com/articles/2000/11/...hat-transcript

"Playstation 2 EDRAM is very fast but 4 MB is a little quantitative so you must think different, you can't put a lot of textures and render the scene, you must think and develop a technique to exploit the full potential of Ps2 architecture.
So you can send to GS, textures via PATH3 and in the same time compressed vertices through Vif, this is a very advanced technique but i think is very powerfull, the main difficult is synchronization about texures and primitive to render.
If your game works in full buffer imho this is the only valid choice because you need a lot of Frame Buffer memory and you have not so much space for stored textures."
http://forum.beyond3d.com/showpost.p...40&postcount=9

Show 40 post(s) from this thread on one page