You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dante is doing one of those blooms where it textures from one part of a framebuffer while drawing to another part of the same one, leading to copies. However, a lot of these copies are unnecessary since multiple draws are often executed where the source region does not overlap the destination., still we end up doing separate framebuffer copies per draw, which is very expensive since there are so many.
I believe there are a few other games similarly affected to various degrees.
The framebuffer where this processing happens is located at 110000, and it starts by doing a single draw into it, downscaling the main framebuffer which is located at 44000 or 00000, alternately. Then a sequence of draws start where texaddr = 110000 and framebuffer addr too, which is what we're talking about here, around draw 250-ish in the first scene.
Conveniently, these draws are all done in through mode, making it easy to keep track of texture and vertex coordinates without having to bother with transforms. So concievably, we could do dirty-rectangle tracking here.
Now, it does seem like some of these flushes could be skipped, which would reduce the need for said tracking. I haven't quite tracked down exactly why all of them happen yet.
But, the game actually helpfully does a CB000000 (TexFlush) instruction when this flush actually needs to happen (texturing from a part of the framebuffer that's just been drawn to), so maybe we could rely on that instead - causing a flush directly from that in this case.
The text was updated successfully, but these errors were encountered:
Actually, during this process, the game does shuffle around the texAddr to different locations within the framebuffer (110400, 110600, 130400 etc), while keeping the framebuffer address the same. Well, we already handle that by handling those addresses as texturing from an offset within the framebuffer, but it defeats simple checks like the one above (which indeed didn't seem to happen enough times per frame). Still, something else is causing the "unnecessary" flushes.
Hm, turns out the "unnecessary" flushes happen due to FinishDeferred. We don't flush in that in the other backends, only in Vulkan...
Though it might be better to not focus on minimizing the flushes, instead the abovementioned dirty rectangle tracking to avoid copies, or just reuse copies until a texflush or framebuffer change, is seeming more and more promising...
… instruction.
Fixes#17030 , or at least improves on it - for optimal performance that
big framebuffer used for bloom should be split like in Killzone, but it's not trivial.
The regression in 1.14 is fixed with this, at least.
I tried it with a few other games with no issues - it seems games are
using TexFlush when needed. But let's see if it really is safe to rely
on that...
There might also be other places we should call DiscardFramebufferCopy
in.
Broken out from #16638 .
Dante is doing one of those blooms where it textures from one part of a framebuffer while drawing to another part of the same one, leading to copies. However, a lot of these copies are unnecessary since multiple draws are often executed where the source region does not overlap the destination., still we end up doing separate framebuffer copies per draw, which is very expensive since there are so many.
I believe there are a few other games similarly affected to various degrees.
The framebuffer where this processing happens is located at 110000, and it starts by doing a single draw into it, downscaling the main framebuffer which is located at 44000 or 00000, alternately. Then a sequence of draws start where texaddr = 110000 and framebuffer addr too, which is what we're talking about here, around draw 250-ish in the first scene.
Conveniently, these draws are all done in through mode, making it easy to keep track of texture and vertex coordinates without having to bother with transforms. So concievably, we could do dirty-rectangle tracking here.
Now, it does seem like some of these flushes could be skipped, which would reduce the need for said tracking. I haven't quite tracked down exactly why all of them happen yet.
This is one that gets triggered, for example:
But, the game actually helpfully does a CB000000 (TexFlush) instruction when this flush actually needs to happen (texturing from a part of the framebuffer that's just been drawn to), so maybe we could rely on that instead - causing a flush directly from that in this case.
The text was updated successfully, but these errors were encountered: