GE Debugger: Allow jumping to a specific prim

[unknownbrackets]

It's a bit uglier, need to do something about so many buttons...

But anyway, this shows the count (this frame / last frame) of prims/curves, and allows you to jump to a specific one. Great for a dump, since you can just press Alt-N.

For a dump, it'd be theoretically possible to implement a scrubber, just by playing forward to the new position.

-[Unknown]

[hrydgard]

Having the relative jumps is nice too - although not exactly an intuitive interface!

Anyway, this is super good as it is, even though the UI could be improved.

[xebra]

Very nice feature but sometimes wrong because total steps of a current frame and the previous frame is sometimes different.

• Denominator = Total steps of the previous frame.
• Numerator = Current step of the current frame.

So, I think we need like a "dummy run loops" for the display list to get total steps of the current frame.
However, this will a big help us.

Now I'm trying to improve the UI like this.

And I hope to improve like this.

1:PRIM
2:PRIM
3:BEZIER
4:PRIM
5:SPLINE
6:PRIM

Also, if frames have thousand of the steps, it's a little slower adding items in the list box.
So it needs virtual list or something.

[unknownbrackets]

Well, getting the steps of the current frame is only possible with a save state. Many games will submit multiple display lists, or update the stall address multiple times during a frame after writing new commands.

It's not possible to scan ahead and get the total frame count. But at least, it allows you to estimate the right draw for the next frame. For a GE dump, which will draw the same each frame, it's great. For games it's still useful.

Agreed the UX is probably not clear, but it would take a lot of UI to make it clear...

I think a list like that won't necessarily make sense when there are thousands of prims (common in 3D games...)

-[Unknown]

[xebra]

Yeah, no problem if GE dump.
Hmm, the list is useful for a few prims but not for thousands of prims maybe...

Thank you for the explanation about the display list anyway. I still don't understand about that well.

[unknownbrackets]

Well, basically, display lists are like functions built with just-in-time compilation that run on the GPU.

It's entirely possible for a game to have a pre-built list of display lists (like an ELF) and just call them without ever generating them. In practice, no game seems to do this.

Instead, games generally do something like...

sceGuStart();
sceGuAmbientColor(0x00FF0000);
sceGuEnable(GU_ALPHA_TEST);
sceGuDrawSpline(1, 1, 16, verts);
sceGuFinish();

To generate a display list (I'm calling this "jit".) It's possible to run a display list partially too, which is what "stall" means. When I submit the list, I simply provide two addresses:

int listid = sceGeListEnqueue(listramptr, (u32 *)listramptr + 4, -1, NULL);

That would cause the GE to stall/hang as soon as it hits the 4th instruction. Then I can simply add more instructions (via the jit or similar) and call:

sceGeUpdateStallAddr(listid, (u32 *)listramptr + 8);

Which allows it to run farther. It's possible I might've already jitted all the instructions before, and just do this as I prepare vertices or texture data. But it's more common that I'm doing this while jitting.

The sceGu library interface has a helper to manage this automatically. I think many games use this and their developers didn't actually manage the GE stall address directly.

Anyway, a game can enqueue as many display lists as they want. Display lists can trigger signals (which cause CPU interrupts), and it's even possible "pause" running display lists (sceGeBreak), insert a new display list ahead of them, and then unpause.

-[Unknown]

[xebra]

Thanks again Unknown!
I think I need to read the source codes of PSPSDK demos and try to write something basic program using it. And self-debug with PPSSPP, and then I will improve understanding.