Use the GPU for texture compression instead of the CPU

[jonnyawsom3]

Is your feature request related to a problem? Please describe.

Resonite uses AMD's Compressonator under the hood to compress textures into GPU formats, but currently it only uses the CPU. When setting local high resolution textures to BC7, this results in many minutes of 100% CPU usage, making the system barely responsive.

Describe the solution you'd like

The library supports GPU encoding with a fallback to CPU (in the command line tool at least...) meaning compatibility shouldn't change. In testing, the GPU encoding was 7x faster than CPU with equal or higher quality, so it should be a healthy trade-off while also lessening the CPU load of Resonite.

Describe alternatives you've considered

Not using high quality formats such as BC7, or making sure to first save textures in the inventory, to offload to the asset variant system.

Additional Context

No response

Requesters

jonnyawsom3 draycethevoidangel

[Frooxius]

We could try this as an option maybe.

My concern is that this will cause severe stuttering, particularly when running in VR, since GPU's aren't nearly as good as CPU's at multitasking, so this could end up in a lot worse user experience.

With CPU encoding, we can better constrain it to fewer threads to reduce impact on the framerate.

[gameboycjp]

Pretty sure this is a dupe of #1983, it's something I've been paying close attention to. The stuttering is an issue on CPU too because it gets hammered so hard anyways.

[jonnyawsom3]

I was going to reference that issue but couldn't remember the name or number.

Currently most users are at a CPU bottleneck anyway, so it could be less of an issue after the performance update. Ideally we could have an option like Froox said between CPU and GPU, with Thread Count to avoid the lockup (Maybe 'Auto' for Physical Cores only?). Then people can change it depending on their own hardware

[Frooxius]

The CPU bottlenecking doesn't necessarily pose a problem here - usually users being CPU bottlenecked doesn't mean that CPU is fully at 100 % - there can be free cores and free time on cores, which can be used at low priority, which will generally not interfere much.

In comparison GPU doesn't really allow for multi-tasking the way CPU's do, so it can be much harder to make it not impact user's smooth experience, even with they are CPU bottlenecked.

[gameboycjp]

The CPU gets hardlocked at 100% on every thread for minutes at a time, and, at least in my experience, causes unbearable stuttering in steamvrs compositor, and makes the rest of the system fairly unresponsive.

[Frooxius]

Yes, that might be the current behavior, but my point is - that can be changed relatively easily - we constrain the computation to smaller number of threads and give it a lower priority, so it doesn't take away from other higher priority processes.

GPU's generally don't have such concepts. It will block everything until it's done, which makes it much harder for GPU accelerated processes to not interfere as much.

[kulzae]

I haven't experienced my system locking when flipping through compression settings. Perhaps the locking is related to the same issue causing https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1983 ? As having the system lock up is something I haven't seen untill somewhat recently

Oh just saw 1983 was already mentioned in the comments

[FlameSoulis]

This may introduce another related issue, but one of Resonite's greatest issues is the immediate application of a selection, even if merely viewing said option is a requirement. Maybe a delay or 'apply' button may be needed for those conditions. I'll do some Git surfing later on to see if such a ticket exists.

[CybrixTheProot]

We could try this as an option maybe.

My concern is that this will cause severe stuttering, particularly when running in VR, since GPU's aren't nearly as good as CPU's at multitasking, so this could end up in a lot worse user experience.

With CPU encoding, we can better constrain it to fewer threads to reduce impact on the framerate.

The whole game stutters. I don't think stuttering during a stutter will effect the user experience that much.

[Frooxius]

We could try this as an option maybe. My concern is that this will cause severe stuttering, particularly when running in VR, since GPU's aren't nearly as good as CPU's at multitasking, so this could end up in a lot worse user experience. With CPU encoding, we can better constrain it to fewer threads to reduce impact on the framerate.

The whole game stutters. I don't think stuttering during a stutter will effect the user experience that much.

Read the whole comment (or the whole chain) please, that's something that's already addressed.

To reiterate - with CPU encoding we can constrain things more easily so it does not stutter. By switching to GPU encoding we might loose that ability to remove/reduce the stuttering.

[Zyro1331]

Someone in the Discord mentioned the idea of applying this to Headless servers instead, as that use-case would make the GPU much less of a priority. It could help keep some things free for the main process, accelerate the compression speeds, and not be much of a disruption due to the GPU not being used actively for rendering.

I'm not entirely sure how often the Headless is relied upon to handle texture compression, but this would be an interesting consideration.

[Frooxius]

There's to main problems with that:

• Headlesses often run on hardware that doesn't necessarily have (good) GPU acceleration necessary for this
• Headless only compresses the textures in some cases - ones that would not help here. If you're having stutters, then it means that headless is already NOT compressing the textures - you are. Meaning having headless use GPU to compress would do nothing to help.