Try to handle more block transfer / tex render cases #6300
Conversation
Trying to keep it cautious in case our sizes are wrong.
Assume we'd be better off reading ram.
|
the Sakura's video is still no change. |
|
Darn. What if you change Maybe it's using the wrong format to clear the buffer... -[Unknown] |
|
-1, it works. |
This already excludes CLUTs.
|
Okay, then this ought to work. I just hope it doesn't have any major regressions. -[Unknown] |
|
Should this be tested for performance/functionality regressions? Just wondering, it looks like a modification to the Texture Cache functionality. |
|
Well, it should not have any special potential to affect performance, although anything can of course. It will mainly change functionality for render-to-texture stuff. -[Unknown] |
| const u64 cacheKey = (u64)addr << 32; | ||
| // If it has a clut, those are the low 32 bits, so it'll be inside this range. | ||
| // Also, if it's a subsample of the buffer, it'll also be within the FBO. | ||
| const u64 cacheKeyEnd = cacheKey + ((u64)(framebuffer->fb_stride * MAX_SUBAREA_Y_OFFSET) << 32); | ||
| u64 cacheKeyEnd = cacheKey + ((u64)(framebuffer->fb_stride * MAX_SUBAREA_Y_OFFSET * bpp) << 32); | ||
| if (addr >= 0x04000000 && addr < 0x04110000) { |
There was a problem hiding this comment.
Maybe I'll just validate more like the stride and stuff.. I'm just worried about mistreating textures that are in memory right after (or potentially even inside due to power of two) an oversized framebuffer.
-[Unknown]
Try to handle more block transfer / tex render cases
Maybe one of these will help that Sakura game's video. @daniel229, any good?
I think detaching makes sense if there's no rendering one way or another. I also think there might be cases of deep offsets into a tall texture, hoping to catch them with the ugly 0x04110000 heuristic. Could break something worst case...
-[Unknown]