Heaven help you if you have a small child in the house that loves to flip the lights on and off.
11 karma · joined June 8, 2024
Heaven help you if you have a small child in the house that loves to flip the lights on and off.
That is a real, real shame with respect to performance. A number of algorithms one can do with MSL (or really because of tile based rendering) so much faster (nearly no main memory bandwidth consumption). Atleast there is GL_EXT_shader_pixel_local_storage for GL. For Vulkan it appears that there is VK_EXT_shader_tile_image, but I do how widespread it is on Android.
There are other nice features that are Metal-ish only as well (tile shaders are a big deal) but typically the memoryless textures tops my list.
As for ultimate usefulness, I am not really convinced. The big selling point on Rust is no memory leaks, no use after free and so on. These issues do not exist in shaders; one cannot allocate memory in shaders really, so that point of Rush seems, well, pointless. I would also never put bounds checking into a shader either; that harms performance a great a deal. I guess if you like Rust's syntax this is a useful, though doing bits that are natural in typical Rust would likely be far from ideal on GPU code. This happens also with current shading languages too, but I strongly suspect this makes it worse.
As a point against usefulness: it is somewhat useless on Apple platforms since one will need to translate into Metal (and yes, there are tools for that), but that drops so many capabilities of targeting Apple devices. Apple GPU's, because of their nature, can do things other GPU's cannot (and also the other way) and to make this useful to me (or any performance minded project that targets Apple GPUs), will require shoe-horning those features somehow into this.
But I guess, it is nice for those who like the syntax of Rust (I confess I do not like Rust's syntax) and are targeting Vulkan as it gives one another shading language to write in; which I guess means a point for SPIR-V (and the interface language idea in general).
It is a C++ library, builds for native (MacOS, Linux and MS-Windows via msys2/ming2 and WebAssembly). It also included a some-what user hostile demo to allow one to make their own animated paths (and save them and load them).
As an example try running
./create_animated_path-release load demo_data/animated_path/example_insane.bin
after you build it for release.
If you download the SVG-Tiger (say from https://upload.wikimedia.org/wikipedia/commons/f/fd/Ghostscr...) you can see it animate an SVG to its reflection too:
./svg-release file ./Ghostscript_Tiger.svg reflect_direction_x 1 reflect_direction_y 1
The library is not really worked on at all since I (the author) left InvisionApp quite some time ago; that and InvisionApp announced that they are shutting down by the end of 2024.
Because it targeted WebGL2 (which is jut GLES 3.0) it could not use compute so some portions of how path filling are handled become CPU bound instead of GPU bound once the GPU is too powerful; a Mac-Mini with an M1 was generally the sweet spot.