Post B53mVuZw4nL18DPMK8 by azonenberg@ioc.exchange
 (DIR) More posts by azonenberg@ioc.exchange
 (DIR) Post #B53mVuLkvVzmQEm2Do by becomethewaifu@tech.lgbt
       0 likes, 0 repeats
       
       Weh. I have too many projects, but just had an idea for another one... Porting as many gnuradio function blocks to vulkan compute shaders as I can, as well as looking into a way to make a single block automatically pick "CPU vs GPU" based on their neighbors if they don't already have a mechanism for that. (to avoid extra copies between host and accelerator memory just for jellybean "intermediate" blocks, without incurring copies by making those blocks require the accelerator)(Unfortunately the only way I can think of is either "naive" and problematic if you have multiple "either" blocks next to each other, or relying on the flow graph compiler to know about buffer typing and alternate implementations. The logic would be that blocks that have a single impl can bind a chain of 'either' blocks to that impl, but "preferring" the GPU if you have a GPU->intermediates->CPU chain)
       
 (DIR) Post #B53mVuZw4nL18DPMK8 by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @becomethewaifu If you're going to do that, make them ngscopeclient filter blocks and finish the scopehal to gnuradio bridge we've wanted for a while (we have early UHD support).In our case, an AcceleratorBuffer can exist in pinned host memory, GPU memory, mirrored copies on both (which are not cache coherent), or unified memory on e.g. apple silicon or an APU. There's a few other edge cases like memory mapped files or non-pinned memory that we'll ignore for now as they're not used much if at all in the current implementations.
       
 (DIR) Post #B53mrf6UICKnVX0ODA by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @becomethewaifu Generally speaking, most of the existing blocks prefer GPU implementations as we are aggressively trying to go 100% GPU, and GPU memory bandwidth is so high that you are often better off copying data to the GPU and doing simple transformations there and only moving back to CPU at the last second if you need to do that at all.Simple intermediate blocks like basic math are very important to do GPU side even if there isn't much compute (like pairwise adding two waveforms) to avoid GPU-CPU-GPU paths incurring large transfer delays.Where it gets *fun* (a currently unsolved problem that is going to require a lot more rearchitecture) is going multi GPU and scheduling workloads when your data may be resident on different cards, moving data between them is expensive, and you need to schedule tasks based on predictions of how long it will take for a shader to run vs how long a copy will take to know whether you are better off submitting work to the GPU the data is resident on (to avoid a transfer) or another GPU (incurring a transfer but allowing both to be busy with shaders simultaneously).
       
 (DIR) Post #B53oMrlNNIEBhYZd8C by becomethewaifu@tech.lgbt
       0 likes, 0 repeats
       
       @azonenberg Makes sense to me. I've been meaning to play around with ngscopeclient at some point, so might as well start there. (It's also an excuse to learn about DSP stuff, given that the class on it that I tried to take in college was cancelled when the prof vanished...)
       
 (DIR) Post #B53oOTjNhG3BkKPRuC by azonenberg@ioc.exchange
       0 likes, 0 repeats
       
       @becomethewaifu we have a bunch of PLL work and IIR filters that I would love someone to figure out how to do, ideally on the GPU.Hop in the dev chat if you want to get more serious after initial familiarization, it'll be easier to discuss technical details in something more real time than mastodon lol