Hello!
As part of https://ossia.io, a media sequencer, I've had to implement a bit of color theory (https://github.com/ossia/score/blob/master/src/plugins/score-plugin-gfx/Gfx/Graph/decoders/Tonemap.hpp),
but in GLSL as my video pipeline is entirely GPU-based.
This is to enable zero-copy whenever we can (e.g. we get a video frame on the GPU straight from Vulkan or Metal's hardware video decoding pipelines, and make that available as a texture). This allows laptops to play quite efficiently with 4K+ HDR videos for instance (e.g., not only playing them back but also adding multiple shaders, effects, etc. necessary for VJ and video mapping use-cases).
Adding a single GPU <-> CPU roadtrip for the sake of using zimg adds an overhead that does not work ; besides, the software also supports GPU-first video formats such as HAP or DXV, which encode DXT / BCn GPU texture formats directly, which are quite inefficient to decode on CPU.
I'd love to be able to defer all of this to zimg, but alas, it is CPU-only so zero-copy would not work!
I would like to know if you would be interested in refactoring the core constants, matrices and transforms available in a .h, in a way that could work both for CPU and GPU. The goal would be be the existence of one single source-of-truth for C, C++ and C-adjacent languages. For instance, a good example of this is Adobe's recent release of OpenPBR which is compatible with C, C++ languages as well as shader langs (GLSL, MSL, HLSL...): https://github.com/adobe/openpbr-bsdf
Another good example of this pattern is NanoVDB (voxel data format) which has a header-file which compiles in C as well as shader langs: https://github.com/AcademySoftwareFoundation/openvdb/blob/master/nanovdb/nanovdb/PNanoVDB.h
Hello!
As part of https://ossia.io, a media sequencer, I've had to implement a bit of color theory (https://github.com/ossia/score/blob/master/src/plugins/score-plugin-gfx/Gfx/Graph/decoders/Tonemap.hpp),
but in GLSL as my video pipeline is entirely GPU-based.
This is to enable zero-copy whenever we can (e.g. we get a video frame on the GPU straight from Vulkan or Metal's hardware video decoding pipelines, and make that available as a texture). This allows laptops to play quite efficiently with 4K+ HDR videos for instance (e.g., not only playing them back but also adding multiple shaders, effects, etc. necessary for VJ and video mapping use-cases).
Adding a single GPU <-> CPU roadtrip for the sake of using zimg adds an overhead that does not work ; besides, the software also supports GPU-first video formats such as HAP or DXV, which encode DXT / BCn GPU texture formats directly, which are quite inefficient to decode on CPU.
I'd love to be able to defer all of this to zimg, but alas, it is CPU-only so zero-copy would not work!
I would like to know if you would be interested in refactoring the core constants, matrices and transforms available in a .h, in a way that could work both for CPU and GPU. The goal would be be the existence of one single source-of-truth for C, C++ and C-adjacent languages. For instance, a good example of this is Adobe's recent release of OpenPBR which is compatible with C, C++ languages as well as shader langs (GLSL, MSL, HLSL...): https://github.com/adobe/openpbr-bsdf
Another good example of this pattern is NanoVDB (voxel data format) which has a header-file which compiles in C as well as shader langs: https://github.com/AcademySoftwareFoundation/openvdb/blob/master/nanovdb/nanovdb/PNanoVDB.h