Const-me

To my taste, that’s too many pointer chases and mispredicted branches.

I once needed something like that which was performance sensitive. Specifically, deserializer of a custom binary format which used string tags for stuff, essentially a tree data structure with string keys. I didn’t have too many of these keys, a key represents a serializable field of some C++ type.

I restricted length of the strings to 16 bytes which was good enough for my use case, and zero padded them into 16 bytes SIMD vector.

On x86-64-v2 and newer AMD64 CPUs, comparing these vectors for equality takes two instructions, pxor and ptest; _mm_xor_si128 and _mm_testz_si128 in C++. That includes the load because pxor can fuse loading of one of the arguments. Searching for a key is then a linear scan over a small aligned block of memory which during de-serialisation is guaranteed to stay hot in L1D. No pointer chases, no inner loops, 2 very fast instructions per test.

“What makes glyphs hard” Another reason is hinting. Traditional text renderers like FreeType are aware of the pixel grid and they adjust the curves slightly, snapping them to that grid. For all methods in the article quite hard to do on GPUs.

“Chinese, Japanese, and Korean have tens of thousands of glyphs, and baking all of them at several sizes is a memory disaster” One possible solution is dynamic atlas built on CPU for visible glyphs only.

“The distance-field panels notch, where interpolating between stored samples no longer matches the true curve” Can’t it be fixed in the shader, using screen-space derivatives of the SDF? I think in theory, SDF value for pixel center combined with screen-space gradient vector of that number delivers enough data to compute partial coverage for the pixels on the edge.

> Can you name anything you've learned from an LLM?

Not GP, but here’s some of the things I have learned in the last couple weeks from LLMs while asking LLMs to review parts of my code and documentation. I wrote the code and documentation without LLMs.

Linux user permissions is a fake because by design, the owner has permissions to write these 3 bits. A good way to reliably deploy a readonly file is owner=root, assign the read permission to the group.

chown command follows links by default, -h switch disables that.

In Linux, resetting environment variable in a long-lived server process doesn’t erase much data because /proc/{pid}/environ is a snapshot taken on process startup.

If my server crashes (or manually killed by a root to test things on staging VM) and Alpine’s supervise-daemon restarts it, the start_pre() function from the OpenRC service script won’t be called again. A fix is use OpenRC to run a launcher shell script as root, in that script manually downgrade the account with `exec su-exec svc:svc /the/server/elf`

This last one is irrelevant to my use cases but still interesting. AES GCM may fail catastrophically when different message encrypted with same password and nonce. For 12 bytes of random nonce, the stuff is only safe up to approximately 4E+9 messages using the same password, beyond that birthday paradox ruins things.

I wonder why hasn’t the OP forked postmarketOS or some other Linux?

I totally get why they wanted a custom userland, built it myself for embedded devices. But IME Linux kernel is not terribly bad these days.

For the last few months, I’ve been working on a vendor-agnostic inference library. Have 3 backends so far: legacy D3D11 for compatibility, D3D12, and Vulkan 1.3. I have reasons to believe nVidia deliberately crippling Vulkan API for their consumer GPUs. Couple examples to be specific.

nVidia driver sets quite low number for VkPhysicalDeviceLimits::maxTexelBufferElements. I don’t think that’s a hardware limit because I have D3D12 backend doing the same thing on the same hardware.

Vulkan performance is not great on nVidia. On all AMD cards I am testing, Vulkan 1.3 is the fastest backend. On nVidia however, D3D12 is faster despite tensor cores (WMMA / wave matrix multiply accumulate / cooperative matrices) are only available through Vulkan, D3D12 is using shader cores exclusively.

I would add than SSE1 and SSE2 are now required parts of AMD64 instruction set. All 64-bit PC processors are required to support them both. For that reason, modern compilers are ignoring x87 FPU when building 64-bit binaries. Instead, they compile all float and double arithmetic into SSE1 and SSE2 instructions, respectively.

Before Vista, we did not have window previews in task bar and alt+tab. We didn’t have a good multimedia framework based on the hardware codecs: media foundation arriving with Vista wasn’t a coincidence. It was hard to capture and encode desktop for screen recording and presentations: despite MS only added desktop duplication API in Win8, technically Vista and Win7 graphics stacks could already do that, MS just neglected. Also, these aero translucency visuals in Vista and Win7 were nice, until Win8 ruined everything.

All that stuff would be hard to impossible with the older GDI architecture and no desktop compositor process.

“aren't truly using a fully shared memory pool” I think with AMD iGPUs I have here (GCN 5.1 and RDNA3 generations) it’s actually unified, at least on Windows 10. The difference between the reserved portion and the rest of the memory is cosmetic.

From Vulkan API POV, the reserved portion has device local and multi instance heap flags, the main heap doesn’t. However, the memory type is identical across all heaps, all of them have device local, host visible and host coherent property flags. And I can confirm VMA library from Vulkan SDK successfully allocates way more device visible memory than the size of that reserved portion.

There’s a reason why all modern desktop environments are designed the same way: power efficiency when multitasking.

Imagine you have 3 windows visible at the same time: a videogame rendering at the refresh rate of the display 144 Hz, a video player rendering frames at 30 Hz, and a text editor rendering blinking cursor at 2 Hz. Because the videogame wants to deliver frames at 144 Hz, the desktop compositor has to deliver the entire desktop at 144 Hz. Asking the video player and especially the text editor to also deliver frames at that frequency would be wasteful. Irrelevant for desktops with fast discrete GPUs, but directly translates to battery drain on laptops.

True, but many modern computers are using unified memory. On such systems all memory is almost equal, despite often reported differently.

For example, on my 5 years old laptop with integrated AMD GPU, windows 10 calculator in default state uses 33 MB system RAM, 9.6 MB dedicated VRAM. Maximized to FullHD screen, same app uses 36 MB system RAM, 13 MB dedicated VRAM. Maybe the OS counts VRAM as active private working set, maybe the app uses more than 1 buffer.

Regardless of the reason, it’s IMO unrealistic to expect a modern GUI app to consume less memory than required for the frame buffer for its window.

10 MB is not too bad for a GUI app. If the app is full screen, display is FullHD and has 8 bit depth, that's almost 8 MB memory for the back buffer alone. Enable HDR and pixels become 8 bytes RGBA16_Float instead of 4 bytes BGRA8_Unorm, twice as much memory.