-
Notifications
You must be signed in to change notification settings - Fork 180
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
Color buffer copy to RDRAM in async mode is partially broken? #1630
Comments
Async copy color buffer to RDRAM will always be broken. I'm very surprised that it works correctly in async mode on my branch when threaded video is off. |
How much of a performance difference are you seeing in the threaded build with |
That depend of the game and number of effects in the screen (fog, gassy, smoke, light sparkles, shines, etc). In the particular area of my tests, with Normal code, master vs The average on master HLE with The average on master HLE with The average on master LLE with The average on master LLE with
The average on master HLE: The average on master LLE: The parameters in master are very stable, in threaded are very chaotic. |
Those are very low VI/s that you are getting. For perspective, my Android phone can get full speed in most games. You have a big bottleneck somewhere. I find it hard to believe that the before storage commit was the cause of your performs drop even when that feature is disabled. Also, HLE should give you much better performance than LLE. Are you running the latest version of your video driver? |
glxinfo
I going to try to upgrade the GPU BIOS. Soon... |
Updating the GPU BIOS probably won't help. What you describe with the VRAM I think could only happen under strange scenarios. It sounds like your texture cache size for some reason is very small. In Textures.cpp find this code:
Replace it with this:
|
Nope, I don't see changes u.u Edit: |
What do you mean? Your can't find the code in Textures.cpp? Can you try making the change above and see if it helps? |
I did the changes, I don't saw improvement. |
What is your GPU, BTW? |
He posted that earlier: https://0x0.st/CHU.txt I don't really understand this problem. |
@Jj0YzL5nvJ Can you try forcing OpenGL ES mode? In this file: https:/gonetz/GLideN64/blob/master/src/Graphics/OpenGLContext/opengl_GLInfo.cpp Change
to
Then in this file Change
to
|
Currently there are a lot of regressions in Mesa with ATI / AMD hardware, so I downgraded some of my repositories (mesa, xorg, kernel) and uninstall all my custom builds and ...all the same, nothing happened ...except that VA-API now works for some strange reason. Now I can compare it with VDPAU. Thanks to the downgrade, I can now give you a less boring result, related to the forced OpenGL ES mode. Before the downgrade: gliden64.log In the mupen64plus launch:
And not work... After the downgrade: Some warnings with GCC: In the mupen64plus launch:
And it works, lagged like the normal code and more glitchy, but works. I can reproduce the "Core Error" by recompiling zlib and libpng in the current versions. After the downgrade a new corona bug appeared in Perfect Dark, now the sun is always visible in LLE mode. Current glxinfo: |
That's normal behavior, AFAIK. Depth buffer stuff is pretty broken in LLE. |
That not happen with Mesa 17.3.0-devel, but I can't assure you that that version worked correctly at all. So, is only a mention with reference purposes (not bug report). |
Color buffer copy to RDRAM in async mode is partially broken, at least in Banjo-Kazooie (the intro effect on the jigsaw puzzle). And the problem is old, is present in bc00985 too.
I test this meticulously in deaf612 and in
3cf7377 threaded_GLideN64
(I can't find it now) branch of @fzurita, with and without the changes sugested by @loganmc10 (#1561 (comment)) as part of my research problem in #1561.I think you will find my results very interesting.
The broken jigsaw puzzle effect:
The correct jigsaw puzzle effect:
The broken jigsaw puzzle effect is always present in this master branch with
EnableCopyColorToRDRAM = 2
and works correcly withEnableCopyColorToRDRAM = 1
, in HLE and LLE alike. By another hand, the thing become interesting in the @fzuritathreaded_GLideN64
branch.In
threaded_GLideN64
withThreadedVideo = False
andEnableCopyColorToRDRAM = 2
, all works correctly. But with thebufferStorage = false
change in the code the thing works exactly like the master branch.With
ThreadedVideo = True
the thing become more weirder. In HLE mode and the normal code, it works like the master branch. But in LLE mode all works again.But with
ThreadedVideo = True
and thebufferStorage = false
in the code, the thing broke like if EnableCopyColorToRDRAM were set to 0 (the classic black puzzle).Like in the master branch,
EnableCopyColorToRDRAM = 1
always works "correctly". But I think thatThreadedVideo = True
is broken withEnableCopyColorToRDRAM = 1
, the performance is worst that withThreadedVideo = False
and uses less CPU... I don't know.In general, the
threaded_GLideN64
branch works best on my system. Even with my current lag problems...This morning I did a quick test, apparently is all the same with d8ac5a7 and fzurita@ba1c93d. I not sure.
The text was updated successfully, but these errors were encountered: