-
Notifications
You must be signed in to change notification settings - Fork 4
Description
In my test cases for Compressonator.NET, I try to use CMP_ProcessTexture from CMP_Framework to compute BC6H images.
When computing using CMP_ProcessTexture, CMP_Framework will automatically try to CMP_CreateComputeLibrary for you and defaults to HPC.
However due to Compressonator.NET not including plugins at the moment, CMP_ProcessTexture ends up using the Non-Plugin version of HPC.
When using Plugin_CCPU_HPC it utilizes a block of code labeled ENABLE_MAKE_COMPATIBLE_API. This converts, the incoming texture data into a compatible buffer for the Compression Option.
Particularly, BC6H needs the incoming buffers to be HALF(Float 16s).As CCPU_HPC does not do this, but passes the image data to the same compression code as Plugin_CCPU_HPC, we end up with access violations
To help with the confusion here I've created a diagram:
graph TD;
CPT[CMP_ProcessTexture] -->CCL[CMP_CreateComputeLibrary];
CCL --> PL;
PL{Plugins Available?};
PL -- Yes --> PHPC;
PL -- No --> HPC
HPC[HPC Compression via CCPU_HPC];
PHPC[Plugin HPC Compression via Plugin_CCPU_HPC];
There are 2 other compression types but these are not used in the above diagram due to the path through CMP_ProcessTexture.
For added reference, here are some call stacks from the areas in question to show the differences in flow.
First, Compressonator CLI that does have plugins:
Secondly, here's the Callstack from CMP_ProcessTexture that does NOT have the plugins:
I think this can be fixed, by moving the ENABLE_MAKE_COMPATIBLE_API steps into CCPU_HPC from Plugin_CCPU_HPC. But this is too big of a change for our(Resonite's) current unit of work which is getting BC6H working via the flows Resonite uses.

