One TMU every two pipes and writing to texture on PS2?

[JesusClownFox]

I was thinking, since the PS2's pixel pipelines are halved when texturing is enabled, does it mean that there is one texture unit for every two pipes in the GS?

Also, since the PS2's internal texture bus is 512-bit, does this account for read-only, or is it read/write, thus making it 256 bits per direction? Are things like writing to a texture a staple of current 3D acceleration hardware?

 

[Guden Oden]

Half of PS2 pixel pipes can texture, yes.

And the 512-bit texture read-port is as the name suggests, a read port. If you wanna do render to texture ops, you just render your scene to a secondary screen buffer, and that utilizes the 1024-bit framebuffer write port, then read that buffer back as a texture in another rendering pass...

 

[JesusClownFox]

But that would only be useful if you want to render the current frame to a texture, wouldn't it? What if you just want to do some blending or other math on a texture (ie, for procedural effects)?

Also, this thing about three framebuffers, can you or someone else try to elaborate at which points of the pipeline each one is created? I think one is done immediately after the triangle setup and initial Z-buffering, no? Another is (of course) done after the final blending stage, but where would the secondary one go?

 

[Deadmeat]

..

does it mean that there is one texture unit for every two pipes in the GS?

The GS doesn't have any TMU. It is a prehistoric dinosaur whose basic design predates before the 3Dfx Voodoo1, so its architecture does not conform to any of industry standard. SCEI engineers were on a hurry to meet the deadline so they stitched together eight PSX1 GPUs and threw in eDRAM and called it "The Graphics Synthesizer". In someways it's more primitive than the Voodoo1.

The way GS works is that it is really a smart blitter. One pixel "engine" fetches the target "texel" from the frame buffer, while other one one fills in the fetched texel back into the frame buffer. The reason I say "Frame Buffer" twice is that the GS sees the memory as one big chunk.

 

[JesusClownFox]

Deadmeat, I really don't appreciate having you reply to my threads, or any other threads for that matter. It seems the sole insight you can provide as to the technical aspects of the PS2 is brash, angry comments about its primitive architecture and the laziness of Ken Kutaragi and SCEI engineers. Some of your supposed "facts" really seem to come straight out of left-field and multiple times I have doubted your intellectual grasp on the subjects being discussed. After a while, you know, it gets old. I would suggest that you just avoid those threads altogether. Thanks.

With that said, if your explanation is true (and it does seem to make some sense, which is odd in your case), why do you refer to the eDRAM as just the framebuffer? Calling it a blitter is really quite unfair, so long as one is able to keep the framebuffers and textures separate from each other in the memory, which I am sure it does.

Anyways, so the way it works is that one of the two pipelines pulls the texels out of memory, while the other applies it to the proper coordinates?

 

[Deadmeat]

...

I would suggest that you just avoid those threads altogether. Thanks.

You asked for help, you got me.

why do you refer to the eDRAM as just the framebuffer?

Modern GPUs divide the VRAM into multiple logical buffers. The GS sees it as one whole chunk. So called the "texture mapping" of SCEI GPUs is nothing more than a fancy blitter.

It's also a cache for textures and other associated pieces of graphics data (display lists, etc).

Those are carry overs from PSX GPU days.

Anyways, so the way it works is that one of the two pipelines pulls the texels out of memory, while the other applies it to the proper coordinates?

That's what Fafa said...

 

[JesusClownFox]

Calling it a blitter assumes that the textures are loaded at the same addresses as the framebuffers, in which case it would be more of a hassle because the textures would need to be reloaded with every new frame. However, developers have a lot more control over where their data goes than this.

Yes, so the whole of the eDRAM is not divided into separate buffers; personally, I find that to be a great decision. If developers had to wrestle with preset memory locations and sizes, things would probably be even more difficult. Being able to arbitrarily decide on how much space you want your frame/z-buffers, textures, and display lists to take up is fantastic. If you can find any flaws in this design choice, be my guest.

 

[Paul]

It is a prehistoric dinosaur whose basic design predates before the 3Dfx Voodoo1, so its architecture does not conform to any of industry standard. SCEI engineers were on a hurry to meet the deadline so they stitched together eight PSX1 GPUs and threw in eDRAM and called it "The Graphics Synthesizer". In someways it's more primitive than the Voodoo1.

Actually after thinking about what you said for a while I have to agree, compared to what the Geforce 3 in the Xbox, the GS IS primitive.

However then I also think.. The Philosophies of the time period in which it was built were totally different. And given the time period the thing was built in, the thing rocked. Back when the GS was being engineered, fast was the name of the game, and that's just what it delivered. Had GS been built around the time Nvidia built the NV2A? You would see a much different GS.

 

[JesusClownFox]

I think it's just two different approaches to the same end-goal. The Vector Units fill the same purpose as the vertex shaders, only without the benefit of specialized microcode. You still have the flexibility of a general-purpose processor, though.

As for pixel-shading, however, the PS2 looks pretty weak. Had it had stronger multitexturing and multipass abilities (and better specialized instructions - DOT3), it probably could've been capable of the more commonly-used effects that are present in DX7- or 8-level games nowadays.

 

[JesusClownFox]

On the subject of this separation of texture fetching and applying to texture coordinates, isn't this similar to what has happened recently with the breakdown of what were previously called "texture units" on DX9 cards? Now it's separated between the texture map and its associated parameters (ie, coordinates), which supposedly allows for greater flexibility.

 

[Megadrive1988]

The GS doesn't have any TMU. It is a prehistoric dinosaur whose basic design predates before the 3Dfx Voodoo1, so its architecture does not conform to any of industry standard. SCEI engineers were on a hurry to meet the deadline so they stitched together eight PSX1 GPUs and threw in eDRAM and called it "The Graphics Synthesizer". In someways it's more primitive than the Voodoo1.

The way GS works is that it is really a smart blitter. One pixel "engine" fetches the target "texel" from the frame buffer, while other one one fills in the fetched texel back into the frame buffer. The reason I say "Frame Buffer" twice is that the GS sees the memory as one big chunk.

As anti-Sony and anti-PS2 as this might be, there is probably *some* truth to at least some of these statements. though GS was made in the 1995-1998 timeframe. Gamecube's Flipper in 1998-2000, and Xbox's NV2A in 2000-2001. GS is by far the oldest of the three chips. as bare-bones as GS is, it's a FAST mofo.

I am anxious to see how much Sony has improved their consumer Playstation graphics chip with the Visualizer in PS3.

 

[Lazy8s]

Paul:

The Philosophies of the time period in which it was built were totally different. And given the time period the thing was built in, the thing rocked. Back when the GS was being engineered, fast was the name of the game, and that's just what it delivered. Had GS been built around the time Nvidia built the NV2A? You would see a much different GS.

There's never been a general consensus in method at any time period - PowerVR Series 2 predates GS. As JesusClownFox was saying, Sony took a different approach to the same end-goal, and I'd expect those 'philosophies' to have been a part of the GS's design even if it had been developed later at the time of the NV2A. That's not to say the end results wouldn't stack up, though.

The PS2 seems to be a really fillrate-centric design, but I question the wisdom of that balance considering the machine is of an era still reliant on texturing and anti-alaising schemes for graphics.

 

[akira888]

One quibble Megadrive1988 - the NV2X architecture the XGPU is based on was complete by summer 2000. In fact that year NV was debating whether to release GF3 for Xmas 00 or just a souped up GF2 (which they actually did of course). Since ASICs of this complexity take at least two years to develop I think a Q4 '97 - Q2 '00 timeframe for XGPU's development is more realistic, which is only about a year and a half back from GS's development time frame.

 

[Deadmeat]

...

PowerVR Series 2 predates GS

But the GS core design predates Voodoo1, as it is a recycled core...

 

[freq]

Re: ...

PowerVR Series 2 predates GS

But the GS core design predates Voodoo1, as it is a recycled core...

OK, I wasn't planning on doing much more than skim through this site, but this comment had me on the floor. I mean, where do you get your information, off the back of a cracker jacks box using your secret decoder ring?

I mean, where does this "recycled core" idea come from, the idea that it uses roughly the same subset of blending functions as the PS1 GS, or merely the fact that it's capable of being backwards compatible? Here's a tip: The first GS did not support perspective correction, which means all data was shipped to it in 2D coords. The PS2 supports perspective correction, which means the whole front end of the processor is different to support the 3rd coordinate. It also supports Z, which means the whole pipeline needs to be redone to support Z rejection. Not to mention bilinear filtering, which is another huge addition to the pipeline compared to where we started, and the whole memory system is different...
You know what? The only part of the PS1 GS that could POSSIBLY be reused is the aforementioned blending modes, which may take up a fair number of transistors but are fairly insignificant in terms of complexity when designing a processor. This doesn't even BEGIN to take into account some of the other complexities of the processor.

So unless we all wake up tomorrow in fairyland where clinkerbell the happy angel clomps around on the tulips in his plate mail hush puppies, we can all laugh at the stupidity of claiming that the core of the PS2 GS is somehow just 16 PS1 GS's put together, and somehow all those other features like bilinear filtering and perspective correction and z-buffering were all available on the PS1 way ahead of its time but nobody used it because those were the days of pioneer hard-core programmers who wanted to do all the Z-tests themselves. Everyone agree?

Now lets laugh some more.

 

[Crazyace]

Interesting DM comments...

I like the smart blitter one best....
I don't recall any console industry standards available when the GS was designed ( If you mean Windows / PC industry then only the Xbox could count as 'industry standard' - as both the DC PVR chip and the GC Flipper chip contain many unique features and quirks... )

 

[Guden Oden]

Trust DM to be able to completely de-rail a thread by injecting some Sony hate into it.

But that would only be useful if you want to render the current frame to a texture, wouldn't it?

You could of course send whatever geometry and/or textures you want to be the basis of your render-to-texture operation, and the buffer you allocate does not have to be screen-sized. It most likely won't be anyway, as space on eDRAM is limited. Besides, as you know it's rare that a big-ass texture is ever used at a near 1:1 ratio between pixel:texel, so a huge buffer would be pretty pointless anyway.

What if you just want to do some blending or other math on a texture (ie, for procedural effects)?

Well, I don't see what's stopping you from doing that also, heh. Like I said, there's nothing stopping the GS from rendering to a smaller than screen-size region. Though I don't know what kind of overhead that might involve if you're not planning to do actual 3D rendering on it. Maybe it would be easier to let a VU work that texture over instead and upload it anew.

Also, this thing about three framebuffers, can you or someone else try to elaborate at which points of the pipeline each one is created?

Hm, which stage? I would think the programmer decides that by specifying an area in eDRAM to which to clear and render into (including clearing space for front and Z buffer), so it'd be done by the time the chip actually starts rendering. The rest of the space could then be used for textures and stuff like render targets for render-to-texture ops etc.

I don't know exactly what restrictions the GS puts on the address granularity of buffer placement, if the start of a buffer must be aligned in some special way etc, but if there are such considerations (and I guess there are, due to the multi-ported bus layout of the memory), one of the forum's resident PS2 programmers could answer it.

I think one is done immediately after the triangle setup and initial Z-buffering, no?

INITIAL Z-buffering? GS is an immediate-mode renderer... It Z-buffers as it goes along... Or maybe you're thinking in some way my sleep-muddled brain is not capable of following?

 

[Squeak]

Might as well re post an old unanswered question of mine:

What is the definition of a real texture unit (TMU)?
And what makes the GSs implementation differ?

 

[phed]

Well, there's nothing bad with a specialized blitter. It allows lots of post-processing which is quite expensive with these traditional 3d-cards.

It seems the idea is to give tools to do whatever you want, rather than implementing a faster version of the status quo of graphics.

 

[JesusClownFox]

You could of course send whatever geometry and/or textures you want to be the basis of your render-to-texture operation, and the buffer you allocate does not have to be screen-sized. It most likely won't be anyway, as space on eDRAM is limited. Besides, as you know it's rare that a big-ass texture is ever used at a near 1:1 ratio between pixel:texel, so a huge buffer would be pretty pointless anyway.

Aaah..I got it. I thought by framebuffer you were referring to the main FB that renders the entire scene. So, are all textures in eDRAM seen as mini-framebuffers (or as you call it, render targets), then? If that's the case, is it possible to use the 512-bit texture in the place of the framebuffer read port?

Hm, which stage? I would think the programmer decides that by specifying an area in eDRAM to which to clear and render into (including clearing space for front and Z buffer), so it'd be done by the time the chip actually starts rendering. The rest of the space could then be used for textures and stuff like render targets for render-to-texture ops etc.

Hmm, I always thought that 3D renderers traditionally rendered to a framebuffer automatically in the pipeline, heh.

INITIAL Z-buffering? GS is an immediate-mode renderer... It Z-buffers as it goes along... Or maybe you're thinking in some way my sleep-muddled brain is not capable of following?

I was under the impression that IMRs did a Z check once after rasterization and once after texturing. Wouldn't continuous Z-buffering be a bandwidth killer?

This business of early Z-tests...can someone elaborate more on this, please?