Implement the PSP's equal-size mips "3D texturing"

[hrydgard]

See #6357. Basically, the PSP has a curious ability to have mipmaps with the same size and use mipmap interpolation to interpolate between them, essentially a very limited version of multitexturing or 3D texturing. This implements that using 3D textures.

This functionality is used heavily in Misshitsu no Sacrifice, and for the water effect in the Macross series.

Vulkan-only currently, though all the other backends except ES 2.0 without GL_OES_texture_3d can support it with some work. This is done, now works on all backends.

Potentially this could also replace the hack we use for Tactics Ogre translation's text, see #5350 - though we'd still need it as a fallback just for GLES 2.0 without 3D texture support.

Strangely I don't think it looks quite as smooth as on the real PSP. I'm wondering if the second level should somehow have its own CLUT, though I don't see how that would work given that the first level uses an 8-bit CLUT that covers the whole of CLUT memory. YES there's space for a 2nd CLUT!

Remaining work before merge (but mostly ready for review):

• Fix the flicker issue (probably give it its own uniform flag, just gotta be careful not to regress games that change the mip bias a lot like GT)
• Implement compatibility checks for OpenGL, disable if 3D textures are not available

[hrydgard]

There's some seriously suspicious stuff there in the CLUT uploads. It DOES set the mode to separate CLUTs, which we thought to be impossible with 8-bit color indices. Then it does two CLUT loads, one supposedly zero-sized, but there's an extra bit there (000040) which we currently ignore... Maybe it selects an unknown upper CLUT register for mip1, or it's just an extra bit for the size field (which would be the correct size for two 256-entry 8888 CLUTs), but then the second load seems redundant.

EDIT: OK had to check, there's nothing like this in Soul Calibur so that mystery still stands.

EDIT2: My theory seems to be correct, although I don't understand why the second CLUT load is needed.

[hrydgard]

Alright, this now looks completely right, though still Vulkan-only. Work on that after the release.

@LunaMoo why don't you have a go :)

[LunaMoo]

Sorry had to stay longer at work, soo far it seems to work great in Misshitsu, in Macross it works great initially, but after flying around fast it starts glitchin
including dumps of both games, but in macross it seems the dump is textureless at least where it uses mipmaps
DUMP.zip

and a video of macross water glitching(it happens after flying on the map some time passed, as if the animation desync)
https://user-images.githubusercontent.com/5485237/180888772-66725c29-da1b-4b29-b24c-03fd933532c7.mp4

Edit: a bit longer video, I thought it's caused by flying fast then by time, but I guess not as I waited long time with nothing glitching and then walked around just a bit and it triggered the problem: It's weird as in this instance it actually loaded the stage with glitching water and(I guess depends on animations the stage starts with, after a moment it corrected itself. It never wants to correct itself later on, but it seems glitching varies after some walking around.
https://user-images.githubusercontent.com/5485237/180891861-44d010d9-553b-4004-b961-865f5e5eefaf.mp4

[unknownbrackets]

Hm, I think we should create more tests for the second CLUT, clearly. I guess I must've forgotten to test that since I don't see any tests? So many GE features to test, so many assumptions to validate...

Not sure why the textures wouldn't dump correctly?

-[Unknown]

[hrydgard]

Definitely needs testing yeah, but heh, not hard to miss testing that, I haven't seen any speculation anywhere before that the CLUT memory might be larger than 1024 bytes, so this is a brand new discovery.

[hrydgard]

@LunaMoo Thanks for testing! That glitching does look weird yeah, and the conditions for it happening are odd... but I have a theory. We might have to set clamp instead of wrap mode on the Z dimension of the texture, for this case.

[LunaMoo]

I had a thought dump might be textureless because of some settings I used in my textures.ini, but even without textures folder it doesn't dump mipmap textures.
ULJS00321_0008.zip

As for the glitching I can now reproduce by simply unthrottling in one spot, so maybe it does happen over time. If there will be any changes I could test for that I will, but in few hours I'm going to work^_^;.

[LunaMoo]

Unfortunately still glitching by just using unthrottle in one spot for a while.

Noticed one thing through, the glitching is less noticeable in stages that has less water, like a river instead of the ocean, it looks like it just starts switching quickly instead of blending together. Maybe a texture cache issue or hash failure, but I tried different hashes and it didn't affect it.

[hrydgard]

Hm, maybe a bug with state tracking of the mip bias constant... I'll clean that code up later and see if I can get it fixed. Thanks for testing so far!

[LunaMoo]

With the latest updates to this branch the glitching still happens on vulkan, also OGL behaves weirdly not drawing some mipmap textures at all depending on the player location on the map:

ULJS00321_0012.zip

[hrydgard]

Yeah, I haven't actually done any new fixes, just rebased it upon the latest code. I've been cleaning house and refactoring a lot.

More work is coming on this one soon.

[hrydgard]

I've now implemented it for all the backends.

[hrydgard]

@LunaMoo can you test Macross again? If it looks good now, let's get this in.

(Also please test on multiple backends. If the movement is slightly different, like slightly choppier, on D3D9, that's expected for now, but should be identical to Vulkan in OpenGL and D3D11).

[LunaMoo]

Works great in both vulkan and OGL, the glitching is fixed, in both d3d modes it's missing textures/bugged in same way:

(which part of the terrain are missing change while walking)

[hrydgard]

Thanks for testing, that is super weird! Could you get a savestate of a situation where that happens? If lucky might be able to get a frame out of one even if the GE dump doesn't work...

[LunaMoo]

Sure, made one right after starting the stage:
PPSSPP_STATE.zip

Edit:
BTW it's the same thing which happened in OGL when I tested before it was implemented on all backends(#15727 (comment)), just back then in OGL ther was a pale color, in d3d modes now it's black, maybe that's a hint where it broke.

Also additional note: effect is working where it does show textures:). As for smoothness in d3d9 maybe a bit less smooth, but hardly noticeable and in misshitsu series it's pretty much same and doesn't have any issues.^_^

This effect might be a little less smooth on all backends than I remember on real PSP, but will have to move my saves back to psp to check, also since it works same as in software renderer I suppose it's all just because PSP's I have suffer from screen ghosting and post shader simulating it would make it look exactly same.;3
Edit after PSP test: yeah it works same now:), the slight ghosting makes it subtly smoother, but can be seen it's nothing more than that:).

[LunaMoo]

A video might give a better hint how d3d fails:

ULJS00321_2022-07-31_15-11-45.mp4

[hrydgard]

Thanks, will look into it some more soon. Likely some ordering issue in binding the 3D texture (d3d is kinda picky sometimes), or something...

[hrydgard]

Alright, that should take care of it, I think.

[hrydgard]

Also I just realized that to make this work with max quality filtering (auto gen missing mipmaps), for the animation to work we really need to mipmap-filter the levels separately (and not have them mush together in the distance as 3D mipmaps would), which means array textures plus manual filtering in the depth direction is probably the way to go instead of 3D textures. This would only be available on Vulkan and D3D11. Anyway, that's for another day...

[LunaMoo]

Works great now.:) Thanks!

[hrydgard]

Thanks for your testing!

[unknownbrackets]

The dump from #15727 (comment) looks strangely dark. I guess this must be from the second CLUT being ignored by GE frame dump recording.

Anyway, software does render this dump slightly incorrectly. Here's the PSP output:

The software output (it's visually very close):

The same dump looks like this on Vulkan:

This already suggests to me that the second CLUT theory isn't true on the real PSP (confirming my prior attempts to reproduce it.) If I revert the secondary CLUT change I get (Vulkan):

That said, it's been reported that it looks better and I'm not against enhancements. I'll just make this a bit safer in case some game accidentally triggers this behavior unintentionally...

-[Unknown]