3.8 KiB
← Back to Twitter thread index
title: "https://trickybitsblog.github.io/2024/02/25/timestamps.html is a nice related re" author: "NOTimothyLottes" handle: "@NOTimothyLottes" post_url: "https://x.com/NOTimothyLottes/status/2060191401883619479" post_id: "2060191401883619479" timestamp: "2026-05-29 02:48:01" post_count: 12 reply_count: 1 repost_count: 0 like_count: 5 view_count: 242
@NOTimothyLottes — https://trickybitsblog.github.io/2024/02/25/timestamps.html is a nice related re
Post 1 (2026-05-29 02:28:17)
Took perhaps a 5 month vacation from at home programming, but getting back in the grove with 1hr/day. Polishing up my WIN32 and Linux system call interfaces. Perhaps working towards a demo of GPU-side audio and network processing.
Post 2 (2026-05-29 02:39:47) — reply to Post 1
Today's topic was Sleep [crap] vs NtDelayExecution [good], does seem useful to be able to NtAlertThread while a thread is sleeping (an analog to signaling while nanosleeping on Linux).
Post 3 (2026-05-29 02:43:22) — reply to Post 2
Futex users, there is the WakeByAddressAll and WaitOnAddress in Windows. But why use those when you can just directly call https://ntdoc.m417z.com/rtlwaitonaddress - but haven't tried that yet, and are the docs correct, why PLARGE_INTEGER for ms, when NtDelayExecution does the 100ns unit thing?
Post 4 (2026-05-29 02:48:01) — reply to Post 3
https://trickybitsblog.github.io/2024/02/25/timestamps.html is a nice related read, also I'm a little late to the https://ntdoc.m417z.com/system_hypervisor_user_shared_data party, but will have that sorted soon as well
Post 5 (2026-05-29 02:52:57) — reply to Post 4
Other thought, I typically mmap an extra LOG file, and write via atomic to grab a fixed width line. No stdout. The log wraps around and exists for multiple executions or even parallel processes. It's the way to do it ... BUT ...
Post 6 (2026-05-29 02:55:54) — reply to Post 5
... I think I'm going to just move the LOG file into the first N KiB of the CART file. So mmap'ed on CPU and GPU, and I can just bank on how "less" doesn't actually load the entire file while printing, so I can still see output on a console if needed for debug.
Post 7 (2026-05-29 03:02:52) — reply to Post 6
And another random thought, can you force de-power the CPU by abusing the https://www.felixcloutier.com/x86/pause instruction for things that are not spin-loops :) Going to have to try this one at some point.
Post 8 (2026-05-29 03:05:57) — reply to Post 7
Pushing data to GPU is really a no-brainer (write-combined stores), minus possibility of non-atomic write visibility, so I do simple stuff like always having a ring buffer of packets available where the GPU can validate each entry with a HASH, taking the latest valid one to use
Post 9 (2026-05-29 03:09:32) — reply to Post 8
Also AMD exports non-cached memory in VK, so it's possible to poll on data the CPU pushes (via write combined stores to VRAM) on AMD a few times per frame even.
Post 10 (2026-05-29 03:10:49) — reply to Post 9
The workaround for NVIDIA is if one wants to read N times per frame, then the CPU needs to duplicate the packet ring to N separate lines. Then the GPU is free to poll, but using separate cachelines each time.
Post 11 (2026-05-29 03:14:46) — reply to Post 10
The route back for IO that needs to be routed through the CPU {audio out, network out} is a lot more unfun. AMD again has the nice uncached memory support, so that part is easy. NVIDIA well, would have to take the crappy mid-frame L2 writeback (likely) making CPU-read available
Post 12 (2026-05-29 03:19:53) — reply to Post 11
Those who have tread here before with driver side logic (DMA transfers/etc) got screwed, Win+Linux driver idiots and their CPU interrupt based scheduling = completely useless. So getting the driver out of the picture is the way to go