Hi, I had a quick look at using libsquish and FasTC.
I didn't manage to build the libsquish repo¹ that Matt Turner pointed to before giving up. It looks like the SSE version of the compressor is using some MSVC-specific intrinsics which don't build with GCC. It seems to be using members of __m128i that don't exist. It looks like the non-SSE version has bit-rotted with the changes made in the -ccr repo and it's missing some functions that are only implemented in the SSE version. I had a quick peek at the original libsquish repo but it doesn't seem to have a BPTC compressor so it doesn't help. As mentioned in Ian Romanick's email, the FasTC repo that he found has a strange license with restrictions about commercial products. I think that makes the license technically not open source according the OSI's definition so I think that is pretty much a show stopper. However, there is also the original code drop by Intel in the webpage² mentioned by Ian and that seems to have a very liberal license. It doesn't have build files for Linux but it looks like it wouldn't be too tricky to just copy the source files into the Mesa tree. I've made a quick start on that in a branch on github here: https://github.com/bpeel/mesa/tree/wip/bptc-fastc I've only tried the non-SSE version of the code with no optimisation flags. It takes 47 seconds to compress the 599×541 doge image. I think there are still problems with the code that we would need to address if we wanted to go down this route: • It seems to be using some global variables to pass state between functions. This would presumably make the compressor break if you tried to use it in Mesa with multiple contexts in multiple threads. • The compressor seems to fail with an assertion if the source image is not opaque. I haven't looked into this much yet so to be fair it could be something that I've broken. • Neither libsquish nor either of the FasTC repos provide a BC6H compressor which we would need. It might not be too much effort to patch one in because the main difficulty is the algorithm to choose the endpoints and the partition. Presumably these could be reused from the BC7 compressor. • I'm not sure how portable the C++ code is which might cause issues for Mesa. None of these problems are insurmountable but my current thinking is that it's not really worth the effort. My current vote would be to just use the custom naïve compressor I wrote even for BC7 compression unless we can find a real use case for needing a quality online compressor. I've made a branch which uses this compressor for all formats along with some other fixes here: https://github.com/bpeel/mesa/tree/wip/bptc This is enough to pass all of the Piglit tests which I posted to the Piglit list. If we can agree that this approach is basically reasonable then I'll post the branch to the list for review. Otherwise I guess if we think we really need a real compressor then I'll carry on prodding the FasTC code. - Neil 1. https://github.com/Ethatron/squish-ccr 2. https://software.intel.com/en-us/vcsource/samples/fast-texture-compression _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
