-
-
Notifications
You must be signed in to change notification settings - Fork 278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nv2a: Handle framebuffer CPU blit and PVIDEO only rendering #1146
base: master
Are you sure you want to change the base?
nv2a: Handle framebuffer CPU blit and PVIDEO only rendering #1146
Conversation
There appears to be a race condition going on that causes stale frames to be displayed (on my machine if you let it run long enough there will be periods where things sync up and look fine and periods where it jumps back to a stale frame for a bit and jitters) Attached is a video of one such run. The test alternates frames between different colored checkerboards, performing a buffer swap between each blit. WARNING: THIS CONTAINS RAPIDLY FLASHING VIDEOCPUBlitJitterTest.mp4The video is captured at 120hz so it's expected that each color should be displayed for ~2 frames of video, but significantly longer runs can be seen (e.g., by extracting frames: Colors should alternate: However frames 122-130 (as well as others) show a sequence break, in this case green&black is skipped entirely as the black&blue frame is repeated. Note: The issue is less pronounced on an M1 |
Some numbers illustrating the problem (running the same test program that just blits checkerboards and swaps frames). This shows that the framebuffer surface used by the xemu UI can get out of sync with the buffer being written to by the guest.
A similar run tracking changes to
|
8b179d7
to
356da2a
Compare
356da2a
to
373dc1d
Compare
Updated to take a different approach. Rather than fall back to the VGA handling in xemu.c, cases with a valid framebuffer but missing/non-matching |
e79faa4
to
031c46a
Compare
@@ -5146,6 +5155,144 @@ static void pgraph_render_display_pvideo_overlay(NV2AState *d) | |||
out_x, out_y, out_width, out_height); | |||
} | |||
|
|||
static void surface_copy_expand_row(uint8_t *out, uint8_t *in, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: Most of these are just moved so they'll be defined before the new first point of use.
@abaire you broke Broken-Sword-The-Sleeping-Dragon 2022-07-06.10-26-30.mp4 |
Tested all the games except |
Thanks, then it's probably safe to assume they're due to a different underlying cause. |
Looks like the pitch ends up being incorrect for this case. I just ordered it, will look at it again in a week or two when it arrives. |
031c46a
to
00d3916
Compare
Looks like it also breaks the FMV for Serious Sam, so hopefully fixing that will fix Broken Sword as well |
00d3916
to
886537c
Compare
@Triticum0 can you check Broken Sword again with the latest commit? I'm not sure it'll actually work given the video you posted, but it now properly handles framebuffers other than 32bpp (like Serious Sam's intro video). |
do you want me to use a debug command in the monitor? |
No, it seems like there's either something interesting about that specific game, or about this patch in general. @theboy181 has similar output for games that I know work with this patch (e.g., Pirates... which is the primary game I tested with on my machine) so I'm suspicious that there is something else I'm missing, possibly driver version related since I think all three of us are using nvidia hardware. |
77afde6
to
d27b5e8
Compare
d27b5e8
to
3e3de08
Compare
@Triticum0 I was able to debug Broken Sword, it used a non-packed pitch for the VGA buffer but should be fixed now. Can you re-test everything just to make sure there's no regressions? I've checked Pirates! and Stake, but want to make sure they're still fixed on your machine as well. |
3e3de08
to
5866d11
Compare
I was able to reproduce the issue reported by @theboy181 by enabling widescreen and 480p mode and running with Still a small problem when running with widescreen enabled in the dashboard but no avpack, the title screen of Pirates... wraps around. |
5866d11
to
87a879c
Compare
When widescreen is enabled but no avpack is set, Pirates ends up using a vga resolution of 704x480 with a vga line offset of 2560 (640x4). Added handling for this case, anytime the vga width is set larger than the pitch it will calculate the correct width and ignore the excess (matching the behavior of the GL surface bypass case) |
7f48bc5
to
2507ba0
Compare
9c29b9e
to
f05c0a7
Compare
Thanks for testing @ko81e24wy - can you double check? I just did a build of this branch and it seems to work for me: And for comparison purposes, here's a clean build: To my eye, the textures on the rocks in the 4x case are substantially sharper than the 1x, both on this fix branch and on |
yes,its sharper,but still has aliasing,master build is smoother. |
Ah, I see it now, along the character's arms. Hopefully just a simple mismerge, will look at it when I have a chance. |
f928340
to
a6c1e5f
Compare
Handles two edge cases: 1) CPU blits to the framebuffer without using 3D rendering. 2) Fullscreen PVIDEO rendering without any 3D rendering. In both cases this change prevents the pgraph code from returning early, bypassing the special case VGA handling in `sdl2_gl_refresh` and instead using a special framebuffer texture to render the contents of VRAM. Fixes xemu-project#652 Fixes xemu-project#1165 [Tests](https://github.com/abaire/nxdk_pgraph_tests/blob/main/src/tests/antialiasing_tests.cpp) [HW results](https://github.com/abaire/nxdk_pgraph_tests_golden_results/wiki/Results-Antialiasing_tests)
a6c1e5f
to
1bebdf6
Compare
@ko81e24wy mind testing again with the latest version? There was an issue with the merge and the original patch that I think are resolved now: |
Handles two edge cases:
In both cases this change prevents the pgraph code from returning early,
bypassing the special case VGA handling in
sdl2_gl_refresh
and insteadusing a special framebuffer texture to render the contents of VRAM.
Fixes #652
Fixes #1165
Tests
HW results