Skip to content
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

Fix rendering in dolphin #365

Merged
merged 2 commits into from
Feb 24, 2023
Merged

Conversation

Jcw87
Copy link
Contributor

@Jcw87 Jcw87 commented Feb 20, 2023

This PR fixes rendering in dolphin by calling glBindSampler(0, 0) in Video::postHwRenderReset()

@Jamiras
Copy link
Member

Jamiras commented Feb 20, 2023

Works great for the first game loaded, but loading a second game (even for a different system) has the no-video problem. Is there some sort of corresponding "reset" that needs to occur between games?

@Jamiras Jamiras linked an issue Feb 20, 2023 that may be closed by this pull request
@Jcw87
Copy link
Contributor Author

Jcw87 commented Feb 23, 2023

I used RenderDoc to see why it was failing after a second boot, and it looks like the texture that Dolphin was rendering to gets cleared immediately after rendering was finished. It attempts to bind a framebuffer before the clear, but it ends up binding the same framebuffer it was already rendering to. This appears to be happening inside the dolphin core. I will need to spend some time debugging this further.

image

@Jcw87
Copy link
Contributor Author

Jcw87 commented Feb 23, 2023

Ok, I figured out what is happening. The dolphin libretro code makes use of the framebuffer provided by the frontend by overwriting a framebuffer that dolphin creates and deletes. Deletes being the key word. If I switch cores and load an NES game, dolphin does nothing. When I load the dolphin core a second time, it deletes all of the framebuffers it allocated, including the one that the libretro code overwrote, which means it deletes the framebuffer that was allocated by the frontend. Then, when dolphin allocates the EFB framebuffer, it gets the same handle as the framebuffer used by the frontend.

The obvious question though, is why doesn't this happen in RetroArch? RetroArch calls retro_hw_render_callback::context_destroy when it shuts down dolphin, and RALibretro does not

So, to summarize, there are 2 bugs working together to ruin everyone's fun. The dolphin core destroys a resource that doesn't belong to it, and RALibretro doesn't tell dolphin to clean up the GPU resources when it shuts down.

@Jcw87
Copy link
Contributor Author

Jcw87 commented Feb 24, 2023

I added the call to free GPU resources, and now you can boot multiple dolphin games and not get a black screen. There are some graphical glitches that can occur when switching games, which is probably due to more OpenGL state shenanigans, but that is a problem for another time.

Copy link
Member

@Jamiras Jamiras left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirmed the fix(es). Thanks!

@Jamiras Jamiras added this to the 1.5.1 milestone Feb 24, 2023
@Jamiras Jamiras merged commit 41a843b into RetroAchievements:develop Feb 24, 2023
@Jcw87 Jcw87 deleted the dolphin-render branch February 24, 2023 20:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants