Questions about PS2

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

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

 

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

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

"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.

 

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:

That's a very limited way of communicating but it's something.

 

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.

 

I think by the end of this thread (assuming it ends) liandry is gonna be ready to make a ps2 game lol

 

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.

 

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

 

I did this a while back for presentation. I'd like to know accurate it is and what i could improve. Thanks in advance

 

I only watched the first minute and... Is that a spoiler?

 

Looks correct as far as I can tell.