Fireblade Imaging thermal freezes the screen

[Triticum0]

Title

FireBlade

Bug Description

Using Imaging thermal complete freezes the screen untill you press the b button again. once it pressed the frame never get update untill you turn it off.

Expected Behavior

Should still render frame when Imaging thermal turned on https://youtu.be/xlQbTtLjF9c?t=932

xemu Version

v0.8.66

System Information

OS | Windows 10
CPU | AMD Ryzen 5 5700x Eight-Core Processoer
Graphics Device | NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2
Graphics Driver | 4.0.0 NVIDIA 570.133.07
Render | Opengl

Additional Context

Couldn't get renderdoc just crashes emulator when capturing =(

[abaire]

@Triticum0 can you test with the special build from https://github.com/abaire/xemu/actions/runs/17131631207 and attach the resulting stderr log? Hopefully that'll let us confirm whether it's using the same mechanism as Steel Battalion to suppress drawing (I'd be surprised though, since xemu's implementation (incorrectly?) resets the context on every command).

A PGRAPH log spanning when you turn on thermal might also be useful, as would a separate log just while it's on, for comparison. So:

1. Start tracing pgraph, then turn on thermal, then stop logging.
2. With thermal on, start tracing pgraph, stop tracing after a second or so.

[Triticum0]

Crashed with this error before it could start emulator happened to me on Linux before but first time it occurred on windows GLib: ../glib-2.83.2/glib/gmem.c:106: failed to allocate 72340168526266374 bytes

[Triticum0]

here a trace log

xemu.zip

[abaire]

72340168526266374

Very weird, I wonder if something changed in the GitHub build bot that's producing a bad binary. I really doubt this issue is the same as Steel Battalion though, so I don't think it's worth worrying about the special build here.

I'll take a look at the pgraph trace to see if it's doing anything unusual. To double check, is this a trace that started before you turned on the broken thermal imaging, or is this just while thermal was enabled?

[Triticum0]

@abaire Tested using Steel Battalion custom build and Spams this when Thermal is enabled

NV_SET_OBJECT: resetting NV_PGRAPH_CTX_CACHE1 0x19
NV_SET_OBJECT: resetting NV_PGRAPH_CTX_CACHE1 0x12

xemu.log

[abaire]

Thanks! As expected, this isn't doing the unusual setting of the command context to 0 that we see in SB. It is interesting that it's using 0x19 and 0x12 though, I believe 0x12 is used with 2d image blit operations and I'm not sure what 0x19 does. This could just be a case of a missing feature.

Oddly I don't see commands for 0x19 or 0x12 in the PGRAPH trace you sent earlier, so I'm not entirely sure what is going on. It might be worth testing again with https://github.com/abaire/xemu/actions/runs/17162204820 which adds more logs (ideally with pgraph tracing enabled as well)

[abaire]

Looks like 0x19 is actually known in the nxdk already, though confusingly it doesn't follow the normal naming pattern, making it harder to find: NV01_CONTEXT_CLIP_RECTANGLE https://github.com/XboxDev/nxdk/blob/3b24b559124aba8fcb94fddff1d2dc9ef32de461/lib/pbkit/nv_objects.h#L652

Presumably this sets the clip region for some blit operation, which could mean xemu is overblitting and retaining a frozen image.

[Triticum0]

Here a another trace using the new build

Fireblade.txt

[abaire]

Cool, I see it at the very end of that log, right before it does a bunch of 2D blit operations.

I'll add some pgraph tests to verify what the 0x19 clip region does to a 0x9F blit, but I'm optimistic it'll be straightforward and will explain the behavior you're seeing.

[abaire]

Added tests, here are the HW results: https://abaire.github.io/nxdk_pgraph_tests_golden_results/results/Image_blit/index.html

xemu doesn't respect the clip region at all, so it always incorrectly blits the entire target.

However, looking again at the log you sent, I don't think clipping is the problem:

nv2a_pgraph_method_unhandled 2: 0x9f -> 0x184 (0x14d80) 0x14D80
nv2a_pgraph_method_unhandled 2: 0x9f -> 0x188 (0x14d70) 0x14D70
nv2a_pgraph_method_unhandled 2: 0x9f -> 0x194 (0x14d50) 0x14D50
nv2a_pgraph_method_unhandled 4: 0x19 -> NV019_CONTEXT_CLIP_RECTANGLE_SET_OBJECT<0x0> (0x00014D70 => 85360) 0x14D70
nv2a_pgraph_method_unhandled 4: 0x19 -> NV019_CONTEXT_CLIP_RECTANGLE_SET_POINT<0x300> (0x00000000 {X:0, Y:0}) 0x0
nv2a_pgraph_method_unhandled 4: 0x19 -> NV019_CONTEXT_CLIP_RECTANGLE_SET_SIZE<0x304> (0x01E00280 {W:640, H:480}) 0x1E00280

The clip region is set to the full screen. That said, there are some unhandled 0x9F commands. I know from previous image blit tests that 0x194 is NV09F_IMAGE_BLIT_SET_BETA_OBJECT and we can infer from the above sequence that 0x188 must be something like NV09F_IMAGE_BLIT_SET_CLIP_RECTANGLE_OBJECT. I'm not sure what 0x184 is doing, but it's almost certainly referring to yet another graphics class.

It'd be very useful to examine a longer trace to see where 0x14D80 is set up so we can figure out what it's meant to do. It's possible that the blit is supposed to be doing some blending (beta is a blend factor) and maybe some additional operation that isn't implemented yet.

@Triticum0 can you get a longer trace and search the logs for 0x14D80?

[abaire]

Actually, this is once again already available in the NXDK, just with an unexpected change in naming convention: https://github.com/XboxDev/nxdk/blob/3b24b559124aba8fcb94fddff1d2dc9ef32de461/lib/pbkit/nv_objects.h#L703

Looks like it's setting a color key, which (I assume) could totally change the behavior of the blit. Based on the nxdk header, I assume it's set via https://github.com/XboxDev/nxdk/blob/3b24b559124aba8fcb94fddff1d2dc9ef32de461/lib/pbkit/nv_objects.h#L277

@Triticum0 you can ignore my request from the last comment, but instead see if you see any unhandled commands sent to 0x57 (probably to 0x304 https://github.com/XboxDev/nxdk/blob/3b24b559124aba8fcb94fddff1d2dc9ef32de461/lib/pbkit/nv_objects.h#L280 ). If that's some interesting value it may be that only some portions of the image is supposed to be blitted instead of the entire screen being overwritten.

[abaire]

and it turns out that I actually have that game. I did a trace of unknown commands and never see anything set up the color key. Interestingly I do see that the value is initially set to an object at 0x14D80 during bootup of the Xbox along with all of the other 0x9F image blit context objects:

nv2a_pgraph_method_unhandled 1: 0x39 -> 0x180 (0x11190) 0x11190
nv2a_pgraph_method_unhandled 2: 0x9f -> NV09F_SET_COLOR_KEY_OBJECT<0x184> (0x00014D80 => 85376) 0x14D80
nv2a_pgraph_method_unhandled 2: 0x9f -> NV09F_SET_CLIP_RECTANGLE_OBJECT<0x188> (0x00014D80 => 85376) 0x14D80
nv2a_pgraph_method_unhandled 2: 0x9f -> NV09F_SET_PATTERN_OBJECT<0x18c> (0x00014D80 => 85376) 0x14D80
nv2a_pgraph_method_unhandled 2: 0x9f -> NV09F_SET_ROP5_OBJECT<0x190> (0x00014D80 => 85376) 0x14D80
nv2a_pgraph_method_unhandled 2: 0x9f -> NV09F_SET_BETA_OBJECT<0x194> (0x00014D80 => 85376) 0x14D80
nv2a_pgraph_method_unhandled 2: 0x9f -> NV09F_SET_BETA_OBJECT4<0x198> (0x00014D80 => 85376) 0x14D80

this makes me suspect that 0x14D80 is some default/null object that may mean that the unsupported color keying is a red herring.

A naive attempt to set up color keying in the pgraph tester runs into DMA validation errors while creating the channel, so there may be something special about how the context object is created (e.g., some flag value outside of the class number).