I promised myself ages ago I would write a blog about this, more for the PS2 community than anything else as this seems to be almost a dark art in terms of understanding how it works.

Some of you may be familiar with Path 3 masking, some of you may not. In any versions around 0.9.4 or older, have you ever played a game where say some of the floor textures have had writing on them or just looked like absolute crap? Well the likelihood is that was due to Path 3 Masking problems. For those not familiar, here is a picture example of persona 3 displaying Path 3 masking issues.



So, what is it exactly?

Path 3 masking is a method of synchronizing the order in which geometry data (polygons etc) and the textures that go on them are sent to the GS (Graphical Synthesizer). It was a pretty efficient method of transferring information, which took completely different path routes to make optimal use of the PS2 Memory BUS and used a stalling method to keep the texture and geometry lists in order instead of interrupts which took extra cpu time. This way, developers could queue up massive amounts of textures and stream them to the GS in time with the geometry data efficiently.

Here is a badly drawn diagram showing what the Mask does:



As you can see, the mask stops PATH3 from transferring while the VU is busy, then lets it go and almost immediately puts the mask back on, this ensures that at the end of the texture transfer, PATH3 stops again!

So what was the problem? Why did everything look like crap?

Truthfully? we never had proper control over these packets. The GIF packets can come through the PATH3 DMA channel lumped together, where in actual fact, we should have been stalling half way through it, but in the emulator, we didn't really care what these packets were, so we just threw it all at the GS and ignored any packet ends and this is what caused the Texture/Geometry lists to go out of sync, this is where the crap on the screen came from. As the emulator evolved it became progressively easier to fix this issue, although we had the theory down, developers would handle it in different ways with different timings for the masks, so it took a fair amount of testing and tweaking to get right.

Fortunately these days we have got this pretty much solved and we completely analyze the GIF Packets before sending them on their way, so we know where we can stop the transfers, however we do still get the odd time where this rears its ugly head, due to how we have to time everything perfectly, but due to the nature of emulators, timing is painful to get correct and will probably never be so. Generally however, using gamefixes such as "EE Timing Fix" can get around these issues, without compromising too much on stability.

Like our Facebook Page and visit our Facebook Group!

Great blog and pretty short one

i am hoping that you can put a blog about all GIFs paths 1, 2, 3 ...

Well there's only so much you can say about Path3 masking ;p Just figured i should make my contribution tho as it's something which isnt discussed much.

Cotton kinda covered the paths in his blog on Threading VU1.

The general idea however is Path 1 does Geometry data while Paths 2 and 3 do Texture data. The only difference between Path2 and Path3 is Path2 can have the textures bundled together with the geometry data, where as Path3 is purely textures, which is good for uploading tile maps and such, textures which can be referenced all over the place.

Like our Facebook Page and visit our Facebook Group!

nice one.

but here's a question about path 2 for textures and geometry.

most diagrams if not all refer that path2 going thru vif1. is it possible to use it for untransformed geometry (for example a batch of screenspace quads with framebuffer texture coordinates) and send it to the gif?

I have nothing to check that. would be cool if somebody with knowledge could answer. thx

(09-02-2011 04:36 AM)xstyla Wrote:  nice one.

but here's a question about path 2 for textures and geometry.

most diagrams if not all refer that path2 going thru vif1. is it possible to use it for untransformed geometry (for example a batch of screenspace quads with framebuffer texture coordinates) and send it to the gif?

I have nothing to check that. would be cool if somebody with knowledge could answer. thx

yes it is.

there actually are no limitations between what the different paths can transfer.
they can all transfer textures/geometry; the reason that games specialize them (having path3 do textures while path1 does geometry) is for efficient use of the ps2.
also since path1 is from VU1 memory, the biggest size a packet can be is 16kb (the size of VU1 memory). path2 and path3 can transfer up to 1mb of gif data.
so it makes sense that games aren't going to be using path1 for transferring big texture data.

path3 also has a special mode that the other 2 paths don't have. it lets it transfer big IMAGE data (textures) and interleaves them with path1/path2 transfers (instead of having to wait for path3 to finish before path1/path2 can start).

the biggest problem with path3 masking is the timing problem which refraction mentioned.
there is a technique games use with path3 where they basically send a huge amount of path3 data at once. and then they time vif1 path3 masking commands (which enable/disable path3) in order to interleave the GIF packets with path1/path2 GIF packets.
to emulate this behavior 100% reliably the emulator needs to emulate its components at much more accurate timing/syncing than it currently does, and its just not very feasible (too many components need to be rewritten with better timing code, and even then random games will still probably have problems).
instead we decided its better to code a fast and relatively good system, and then special gamefix the games that have problems due to bad timing. if games didn't actually rely on the timing of components this wouldn't have been a problem, but sadly they do with path3 masking.

ahh ok. and yeah I did see a couple of diagrams already and know a lil of the quirks to sync textures and geometry.

Tbh its been a pain in my ass for years and we'd put lots of stuff in place to try and keep stuff in time, alas we can only do so much.

Like our Facebook Page and visit our Facebook Group!

Very nice job Refraction! The diagram was a little funky but I really liked the post. It's great to see another blog post! Do you or cotton have any plans on what your next blog post will be (assuming there is going to be a next one )?

I know you guys have recently implemented a system that puts the packet pieces in a queue until it has a complete packet or something along those lines. Does that affect this at all?

That's related to the gif packets I spoke of yes

Like our Facebook Page and visit our Facebook Group!

Programming to the metal, a dying art (thanks MS). Always amazed at what can be done to unlock that last 10% of power.