71cb1aef6f
This PR adds a feature to merc2 to update vertices. This will be needed to efficient do effects like blerc/ripple/texture scroll. It's enabled for blerc in jak 1 and jak 2, but with a few disclaimers: - currently we still use the mips2c blerc implementation, which is slow and has some "jittering" because of integer precision. When porting to PC, there was an additional synchronization problem because blerc overwrites the merc data as its being read by the renderers. I _think_ this wasn't an issue on PS2 because the blerc dma is higher priority than the VIF1 DMA, but I'm not certain. Either way, I had to add a mutex for this on PC to avoid very slight flickering/gaps. This isn't ideal for performance, but still beats generic by a significant amount in every place I tested. If you see merc taking 2ms to draw, it is likely because it is stuck waiting on blerc to finish. This will go away once blerc itself is ported to C++. - in jak 1, we end up using generic in some cases where we could use merc. In particular maia in village3 hut. This will be fixed later once we can use merc in more places. I don't want to mess with the merc/generic selection logic when we're hopefully going to get rid of it soon. - There is no support for ripple or texture scroll. These use generic on jak 1, and remain broken on jak 2. - Like with `emerc`, jak 1 has a toggle to go back to the old behavior `*blerc-hack*`. - In most cases, toggling this causes no visual differences. One exception is Gol's teeth. I believe this is caused by texture coordinate rounding issues, where generic has an additional float -> int -> float compared to PC merc. It is very hard to notice so I'm not going to worry about it. |
||
|---|---|---|
| .. | ||
| GlobalProfiler.cpp | ||
| GlobalProfiler.h | ||
| readme.md | ||
Event Profiler
The event profiler is a tool to analyze timing of multiple frames. Unlike sampling-based profilers, this profile captures an exact timeline of what happens of what happens when.
Capturing a profile
In the OpenGOAL window, click "Profiler" and check "Record" to start recording. The buffer has a fixed maximum size and it will automatically overwrite old data once it is full.
When something interesting happens, click the "dump to file" button to save the buffer (currently a few seconds) to prof.json in jak-project.
The idea is that you can leave this running as you play, and then when the game stutters or does something interesting, you can click the dump button and get the result.
Viewing a profile
Open Google Chrome and go to chrome://tracing. Then click load and open the json file. Or, just drag and drop the file into chrome.
Press 1 for a box drawing tool. This lets you select a region of the flame chart and get a list of events inside the box.
Press 2 for panning.
Press 3 for zooming.
Adding an event
The GOAL kernel automatically adds events for each process. If you want to add another event, you can use (with-profiler "name-of-event" <body>). Do not call suspend or do a return inside of this. If you need more control over stopping/starting, there are functions in gcommon.gc to explicitly start/stop events. But you must match them up correctly yourself!
In C++, the graphics profiler automatically adds a profiler nodes as events. To add an event, you can use
auto p = scoped_prof("name-of-event");
The event is active from this call until the destruction of p.
Multiple threads
The event profiler currently works on both the graphics and EE threads. Adding the events can safely be done from any thread, but enable/disable/dump should be done from a single thread at a time.
Each thread should periodically insert a ROOT instant event when there are no active range events. This is required to make the retroactive dump feature work properly as the event buffer does not capture the tree structure fully, and it must be able to find a point in time when no events are active.