HNHacker News
TopNewBestAskShowJobs

krogue

11 karma · joined June 8, 2024

submissionscomments
krogue··on Ask HN: What are your most regretted tech purchases?
Here in Finland, the only light bulbs to buy are LED light bulbs. They are so much more freaking expensive that old school light bulbs; as for color, there are warmer light options but it is different than old style light bulbs. They tend to last longer and use less power (as advertised), but my understanding is that the old practice of turning off a light if it is not in use for an hour is not worth the bother for LED's; I remember reading that their lifetime is two numbers: number of hours on and number of times it is turned on and off.

Heaven help you if you have a small child in the house that loves to flip the lights on and off.

krogue··on Ask HN: What are your most regretted tech purchases?
Cheap 2-port KVM switches. I have, in the past, needed a 2-port KVM so I have bought a cheap one (typically via Amazon). Every time, it is bad and it does not work reliably.
krogue··on Rust GPU: The future of GPU programming
> No Metal support is IMO no problem. I and most of the rest of the games industry couldn’t care less about MSL. Nobody uses it. I’ve seen numbers from Apple that say upwards of 80% of developers they asked target Metal via SPIR-V Cross and HLSL from DXC.

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.

krogue··on Rust GPU: The future of GPU programming
From a PR standpoint, this page encourages the viewpoint that Rust fans are too often Rust fanatics.

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).

krogue··on Morphing Arbitrary Paths in SVG
The astral renderer released as open source on https://github.com/InVisionApp/astral-renderer does all sorts of path morphing.

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.