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

Replacement: Move IO checks to saving thread #15489

Merged
merged 5 commits into from
Apr 18, 2022

Conversation

unknownbrackets
Copy link
Collaborator

@unknownbrackets unknownbrackets commented Apr 18, 2022

Didn't check perf on Android, just that saving still works on Windows. For me, under Vulkan, saving worked fine with upscale (didn't reproduce #15488), but maybe that's other backends.

This fixes saving "fake mipmaps" that force a constant texture level to 0, and moves IO onto the thread. It does allow retrying saves every 5s, because before it intentionally repopulated deleted files. Even if this queues up a bunch of tasks, I expect it to be much lighter than before. That said, perhaps CPU_COMPUTE is a lie moreso now...

Further, on Vulkan, this moves decoding to a temporary buffer when saving texture data. For simplicity, this buffer matches the target decode aligned stride, and maybe could std::move() to the thread as a later optimization (I'm sure the IO and PNG encode are a more significant part of performance, though.)

This also disables the save checkbox if not replacing, which was already how it actually worked.

I didn't look at Direct3D 11, but it could probably have something similar done to avoid reading from the upload buffer. I think it's useful to save the upscaled data (at least when CPU upscaling), so I'd rather we not re-decode. That sounds messy and wasteful for performance, anyway.

Likely to help #15478.

-[Unknown]

This might be used for fonts, for example.  They could be replaced, so no
reason not to export.
This will spin up more threads that might not actually save, but it will
remember this in savedCache.
This does mean an actively saved texture won't recheck, but it's close to
the old behavior where you could delete a new texture and it'd soon be
resaved.  This was convenient sometimes.
For clarity, it's required.
@unknownbrackets unknownbrackets added this to the v1.13.0 milestone Apr 18, 2022
@hrydgard
Copy link
Owner

I will see separately if I can still reproduce #15488. I might have ended up both breaking it and fixing it again while working on #15487, so it might not be a real issue.

Moving the checks to the tasks should be good, yes.

Seems like a good workaround for the reading-upload-memory issue. I know that this can be an issue in D3D11 too (you commonly get write-combined memory when wrapping buffers for write there) but not sure in practice how many people it will affect or how badly...

Comment on lines -556 to -558
if (ignoreMipmap_ && level > 0) {
return;
}
Copy link
Owner

Choose a reason for hiding this comment

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

This check is probably what saved us before, removing it resulted in #15492 .

I know what's wrong though, code to detect the fake mipmap situation isn't quite right, fixing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It must be the break I removed in BuildTexture, I assumed it was just a mistake. This check is still there, just moved above the cachekey.

-[Unknown]

Copy link
Owner

Choose a reason for hiding this comment

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

Ah right. Well I just had a quick skim of this one after actually finding the real root cause. No fault of this PR.

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