Render to tex improvements #70
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of copying at the end of every command queue flush, copy the EFB to the texture only when the texture stops being a render target. Unfortunately SDL invokes the SetRenderTarget() method after having updated the render target pointer, forcing us to keep our own copy of it.
If we are rendering to a texture, we must avoid writing to the XFB, because the image we are rendering might not be intended to be shown as-is on the XFB. So, when clearing the display, pay attention to whether we are rendering to a texture and, in that case, do not copy the EFB to the XFB. Instead, copy it to the texture itself (not that we care a lot about this copy, since the texture will anyway be overwitten once it stops being a render target; but we do care about this operation causing a full clearing of the EFB).
It can happens that the client program immediately calls SDL_DestroyTexture() after draawing it. Luckily for us, SDL is smart enough to realize that the texture has been used in a draw operation and issues a SDL_RenderFlush() so that all the operations get executed. But this means that on our side, we must also make sure that when we return from OGC_RunCommandQueue() the texture data is no longer needed. The call to GX_DrawDone() does exactly this.
Indeed, the situation where a rendering to texture operation begins after the EFB has already been painted can happen. In order not to lose the existing EFB contents, make a copy of them into a texture (using the same size of the render-to-texture target) and then restore them by redrawing the saved texture over the EFB, once the render-to-texture operation has completed. Note that it's important that any calls to GX_SetPixelFmt() happen in the appropriate order: 1. Save the current EFB contents 2. Change the EFB format (by calling GX_SetPixelFmt()) 3. Perform all the render-to-texture drawing operations 4. Save the EFB into the target texture 5. Restore the EFB format 6. Restore the EFB contents by drawing the texture saved in step 1 Swapping the 5th and 6th steps does not cause any visible issues in Dolphin, but causes the EFB to be painted back with wrong colors on a real Wii.
This is needed to avoid visual artifacts on the saved texture.
The documentation says that this is needed, though in practice I haven't yet seen any issue with not using it.
Because the GPU doesn't go through the cache and if the CPU has touched that memory before you do the copy then it will get corrupted when those cache lines get evicted. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here's a few changes that fix various issues I've met with a game I'm writing, which makes extensive use of the "render to texture" feature.
Easier to review commit by commit (please don't squash them into merging, since the addressed issues are all slightly different).
I honestly haven't understood why the commit "ogc: invalidate current texture contents before copying the EFB onto it" is needed, but without it I do see (minor) random corruption on the generated texture.