Questions about PS2

Thanks everyone for answers! That explains a lot.
Now I want ask some questions about VU0.
1) VU0 can work in micro mode and in macro mode. It can switch modes, but does it can switch modes on per frame basis?
2) VU0 can send data to VU1 through dedicated bus. What benefits does it have?
3) VU0 can also calculate polygons. But does it really have some benefits or it's better to use it for other calculations?
 
1) VU0 can work in micro mode and in macro mode. It can switch modes, but does it can switch modes on per frame basis?

VU0 isn't directly involved in anything to do with frames, you should be able to switch whenever you want. Overhead of doing so notwithstanding.

2) VU0 can send data to VU1 through dedicated bus. What benefits does it have?
3) VU0 can also calculate polygons. But does it really have some benefits or it's better to use it for other calculations?

This is my understanding from the manuals, and is open for correction by people who actually developed on PS2.

I can't find any evidence of a dedicated bus between VU0 and VU1. In fact, as far as I can tell there is no way to efficiently copy data from VU0's RAM to anywhere else. The only way I can find is for the CPU to stop VU0 then use program loads (not DMA) to read back its memory from a location that's mapped in its address space. This is going to be pretty expensive.

What that would suggest is that VU0 in micro mode is only well suited to tasks that don't output a lot of data. One example could be collision detection. There you'd have to load and perform calculations on a lot of geometry data, but would only need to store a small list of items that actually collide.

Calculating polygons, on the other hand, is probably not a good application, especially since VU0 has no path to the GIF as far as I'm aware.

Suffice it to say that VU0 was challenging to utilize well in micro mode, and there are advantages to keeping it in macro mode. So most developers didn't bother with micro mode and IMO a better design would have been to make macro-mode only (and unify it with the integer SIMD registers/operations) and spend the micro RAM on other things like larger CPU L1 caches.
 
VU0 isn't directly involved in anything to do with frames, you should be able to switch whenever you want. Overhead of doing so notwithstanding.


This is my understanding from the manuals, and is open for correction by people who actually developed on PS2.

I can't find any evidence of a dedicated bus between VU0 and VU1. In fact, as far as I can tell there is no way to efficiently copy data from VU0's RAM to anywhere else. The only way I can find is for the CPU to stop VU0 then use program loads (not DMA) to read back its memory from a location that's mapped in its address space. This is going to be pretty expensive.

What that would suggest is that VU0 in micro mode is only well suited to tasks that don't output a lot of data. One example could be collision detection. There you'd have to load and perform calculations on a lot of geometry data, but would only need to store a small list of items that actually collide.

Calculating polygons, on the other hand, is probably not a good application, especially since VU0 has no path to the GIF as far as I'm aware.

Suffice it to say that VU0 was challenging to utilize well in micro mode, and there are advantages to keeping it in macro mode. So most developers didn't bother with micro mode and IMO a better design would have been to make macro-mode only (and unify it with the integer SIMD registers/operations) and spend the micro RAM on other things like larger CPU L1 caches.

I think there was a way to copy from some specific register in the VU0 to some register in the VU1. Not sure what that was useful for. But, it let people draw a connection between the two in the system diagrams :p

You're right. Using the VU0 effectively was a real puzzle. The way that was presented was something like "Upload some code and data. Trigger the code. Have the CPU do some other stuff for 'a while.' Stop the VU0. Download the results." But, you didn't have a good way to know when the results were ready. How were you supposed to schedule anything?

Way late in the PS2's lifetime, some friends of mine figured out how to make it work well. I think they found a way to have the VU0 trigger an interrupt on the CPU. So, they would install an interrupt handler that would kick off whatever work needed to be done on the CPU whenever the VU0 asked for it. For example, you could animate some verts on the VU0 and have an interrupt ready to download the results, upload some more verts to animate, and repeat. Because it was on an interrupt, the CPU's main thread could move on and it didn't have to explicitly schedule or do anything. The main thread would be paused and resumed in the middle of whatever it was doing without noticing that anything happened.

Soon after they figured this out, the world moved on to the 360/PS3 :(
 
I can't find any evidence of a dedicated bus between VU0 and VU1
It's shown on many diagrams. :D

I think there was a way to copy from some specific register in the VU0 to some register in the VU1. Not sure what that was useful for. But, it let people draw a connection between the two in the system diagrams
So his means there is some dedicated bus?

Way late in the PS2's lifetime, some friends of mine figured out how to make it work well.
Was it used in some game in the end?

Soon after they figured this out, the world moved on to the 360/PS3
What year exactly do you talking about? Because 360 was released in 2005, but games were released on PS2 till the end of 2013, games what weren't sports till the end of 2010.

And tell me anyone please what is XGKICK?
 
So his means there is some dedicated bus?

It was less like a bus and more like a small hole in a wall between the VUs.

Was it used in some game in the end? What year exactly do you talking about? Because 360 was released in 2005, but games were released on PS2 till the end of 2013, games what weren't sports till the end of 2010.

Not sure. But, I don't think it shipped.

And tell me anyone please what is XGKICK?

"When the micro-program executes the XGKICK instruction a transfer is performed from a memory location in VU1 data memory to the GIF." http://lukasz.dk/files/TextureGeometrySyncing.pdf

XGKICK is how the VU1 kicks the GIF to wake it up and get it to start transferring some data (commands) laid out in VU1 mem to the GS.
 
It's shown on many diagrams. :D

I've seen it on those diagrams too, although I've also seen it absent on other ones.

I've dug around through all of the EE/VU manuals from Sony and I just can't find any kind of communications interface between VU0 and VU1. As far as I can find neither VU even has a set of registers that is accessible to VU code. The only exception is the xtop and xitop instructions which can read the TOP/ITOP registers from the corresponding VIF.

So if it's possible for VU0 and VU1 to communicate directly I'm completely at a loss as to how.

It could be that the arrow on the diagrams refers to the EE core's connection to VU1, not a special VU0 connection. Then you'd be able to "use" this with VU0 when in macro mode. Or it could be that the block diagrams are misleading/wrong. Would hardly be the first time. Functional documents/register descriptions are always a more reliable and authoritative source than diagrams which are just meant to give a broad overview.
 

I don't mean a block diagram in an official document, I mean an actual description of the functionality. An arrow is very vague.

Anyway, I did miss it, there is an actual connection which is described as follows:

Furthermore, VU1 registers are mapped
to addresses 0x4000 to
0x43ff in VU0.

That's a very limited way of communicating but it's something.
 
Here https://www.dropbox.com/s/pjz8qktadg1cr9d/PS2Optimisations.pdf on page 16 is said what it's better to use 32-bit textures. But I've heard what it's better to use 4-bit and 8-bit textures. Can someone explain this to me?

This is about transferring textures from main RAM to the GS's EDRAM, and the recommendation is to use the 32-bit transfer mode when transferring 4-bit or 8-bit textures, packing 8 or 4 textures at a time.
 
This is about transferring textures from main RAM to the GS's EDRAM, and the recommendation is to use the 32-bit transfer mode when transferring 4-bit or 8-bit textures, packing 8 or 4 textures at a time.
Ok, I understand. Thank you! But textures on PS2 were always 4-bit or 8-bit? And does it mean what pixels in framebuffer also will be not 32-bit but 4-bit or 8-bit?

Also there is 2,5 GB/s bandwith inside EE, if there is ~ 1 GB/s texture transfer to GS, does it mean what only 1,4 GB/s bandwith left for other conponents? And if yes, was i realy enough?
 
I don't think it'll ends soon, because there's a lot of questions ahead! But I ask them because I'm just interested in how PS2 worked.:D
 
I've played a lot of PS2 games last weeks. They wee mostly games from 2001, 2002, 2003 years. I've noticed two interesting things. First, there were a lot of games on PS2 with 3D water, and mostly that was 3D water with reaction to character movement. Second, there sewe a lot of games with reflections, like reflections in water, on marble floor. Can anyone tell why there was so many games with those effects on PS2, and not so many on PS3/Xbox 360?
And maybe anyone can comment my other questions?
Thank you!
 
Two more questions. I've played Black on CRT TV and yesterday tried it on HDTV with component cable in progressive scan and widescreen. Game run very fast, so question is, does it run 60fps on PS2?
Second question, does cutscenes in Silent Hill 3 are videos or run in real time on game with in-engine graphics? In other words does PS2 renders those cutscenes?
 
Something that's been bothering me is that some sources are saying that the EE vector units run at half the EE clock speed (~147-150MHz), and that's what is currently written on Wikipedia. The PCSX2 emulator emulates CPU vs VU cycles by this ratio. But I doubt this is correct. I can't find any Sony sources that state this, only that the EE runs at ~300MHz, and while the user manuals don't mention absolute clock speed at all it seems like it'd be a massive omission to not indicate that the VUs run at half clock. Especially with VU0 in macro mode.

With the half clock figure the 6.2 GFLOPs number (which has directly come from Sony) makes no sense. The following Sony article:

https://www.dropbox.com/s/5ypfnlupv0grolo/Vector Unit Architecture for Emotion Synthesis.pdf

Does seem to make it pretty explicit that the VUs are running at full speed.

Maybe we should update Wikipedia.
 
Two more questions. I've played Black on CRT TV and yesterday tried it on HDTV with component cable in progressive scan and widescreen. Game run very fast, so question is, does it run 60fps on PS2?
Second question, does cutscenes in Silent Hill 3 are videos or run in real time on game with in-engine graphics? In other words does PS2 renders those cutscenes?
I am pretty sure they were real time. I recall the character changed costumes in the cut scenes if you used alternative clothes

Yep confirmed
 
Back
Top