Reimplement bicubic upscaling.

[fp64]

Integrated code from #15774.

Only very lightly tested.

[fp64]

Hmm, running ./b.sh --headless && python3 test.py -g --graphics=software on my machine results in

277 tests passed, 2 tests failed.
Failed tests:
  rtc/arithmetic
  rtc/lookup

[hrydgard]

There's something weirdly flaky about the tests on ubuntu, that we need to look into.

[fp64]

There is some mildly suspicious stuff in Core/HLE/sceRtc.cpp, like using not fully zero-initialized tm, despite:

The Standard mandates only the presence of the aforementioned members in either order. The implementations usually add more data-members to this structure.

Though changing that specifically does not fix the tests.

[unknownbrackets]

It'd be ideal if you could follow the EditorConfig rules and just use tabs for indentation. I realize this is code you wrote externally, but best to just stay consistent.

Does const int MIN_LINES_PER_THREAD = 4; need to be changed to 8, or is it fine because it will clamp to y0/y1 anyway?

Might be the Rtc tests fail due to some local timezone thing. The sporadic failure needs to be looked into but is not likely related to Rtc...

-[Unknown]

[fp64]

Does const int MIN_LINES_PER_THREAD = 4; need to be changed to 8, or is it fine because it will clamp to y0/y1 anyway?

I think it refers to the source image's lines, so the number of destination image's lines (what upscale_cubic cares about) would be at least 8 for all slices except, possibly, last. Still, working on e.g. a 10-line slice would take same amount of work as 16-line, so this is not optimal.

[unknownbrackets]

Okay, got it. That sounds fine, then.

-[Unknown]

[fp64]

It'd be ideal if you could follow the EditorConfig rules and just use tabs for indentation. I realize this is code you wrote externally, but best to just stay consistent.

Done, I think.

[fp64]

I should probably mention, that it upscales with Catmull-Rom ('bicubic', that is, on the other hand 'hybrid' uses B-spline, because that's apparently what it wants), so it may look a bit sharper than the previous implementation (see table).

Feel free to adjust B, C coefficients, or even expose them to the user.

Addendum: the paper mildly recommends sticking to B+2*C=1, which would make it 1-parametric (easier to map to a slider?). Not that the other choices neccessarily look bad.

Subjective quality (from wiki)

Also, the values outside [0;1] are valid (e.g. the paper mentions "notch filter" with B=3/2, C=-1/4).

[fp64]

Did a bit of profiling from the actual emulator, and the results are consistent with the synthetic benchmark before: the speedup for bicubic upscaling is about 10x (unlike the previous benchmark, this also includes multithreading). This only counts the CPU upscaling itself though, not the time it takes to upload the resulting texture to GPU.
Encountered no issues with it so far, so can be merged at your discretion.

[hrydgard]

Great, thanks!