Rust wgpu now has a
-
@mcc @decay @riley @ireneista @amarioguy And yet it's hard to imagine a GPU not have on-board controller silicon capable to take LLVM IR or even a higher-level bytecode and lower it down to board-specific machine code.
@MaddieM4 @ireneista *is* that done on on-board controller silicon? I would have assumed it's done in a CPU-driven userspace thing installed in to the regular operating system alongside the driver.
Like I'm certain they *could* do it with on-board controller silicon, if they wanted, but even then I suspect that on-board controller silicon would look a lot like a small ARM running a CPU-based compiler in a tiny Linux
-
@ireneista @MaddieM4 @mcc @decay @amarioguy the "traditional" curriculum (or at least, mostly generalizing from my own experience) is approximately:
1. some general engineering math (complex exponentials, linear algebra)
2. fourier series, fourier transforms
3. convolution
4. sampling
5. discrete time fourier transforms, discrete fourier transforms
6. laplace transforms, z transforms
7. filters, "various properties" (pole/zero, causality, stability, bandwidth, etc.), "various design tools" (bode plots, root locus analysis, known/established filter designs, etc.)
8. multiple-input and multiple-output systems
9. newer "state space" techniques
10. linear-time-varying systems, nonlinear systems, stochastic systems, and beyondwith "digital signal processing" as an offshoot that lives somewhere vaguely around step 7 with some ideas from later steps
this is..... an *extremely* theory-heavy and tbqh rather old (in terms of absolute-time) approach, very much within the "electrical engineering"-owned-and-controlled part of the conceptual space
@ireneista @MaddieM4 @mcc @decay @amarioguy anyways, i _really_ struggle to actually *talk with* people who don't do well with this approach, and with social reach in general, so i haven't invested too much into this, but some patterns i've noticed nonetheless:
* some people just.... don't.... like.... symbols??? (i've been realizing how difficult a concept "abstraction" really is, and how much of the "cabal of Elite
️ universities" pressure (and toxicity) is in part an attempt to force you to learn their particular style of doing abstraction. but, otoh, the part i _really_ don't get is that there seem to exist people who don't like symbols in "equations" but are perfectly happy with symbols in computer code or on a graph)* a lot of this is insufficiently physical (even a project-based curriculum *run by the EE department* doesn't usually have as many fiddly doohickeys as "musicians" seem to like)
* everything is connected to everything else. this is either spelled out in *too much* detail or *too little* detail, never "just right". at the same time, everything is either too much "you are smart, you can do the computer-y bits by yourself" or else too much "here is something to plug into the computer", never "just right" either. (in case examples help: using pencil-and-paper to do the derivation from FT->DTFT->DFT is *really cool*, but unless you're already in the "right" mindset it just looks like shuffling a bunch of very similar very confusing symbols. afterwards, you either _never_ mention e.g. the python-scientific-stack or else you hand everyone a pile of python/matlab code for homework (where you need to fill some part in) )
-
@mcc the problem of my desire for fast 3D rendering being in apparent conflict with my desire for a portable slop free human-sized computing environment has been weighing on me pretty hard. i've been thinking it might be worthwhile to investigate software rendering systems, since they can probably be made more performant than llvmpipe by not emulating a full general purpose gpu api, but idk where i'd start with that
@aeva @mcc if you want to start from historic, fatmap.txt is a pretty fun read (and you can then make your renderer look like it’s genuinely old and needs small polygons and has ordering issues and no perspective divide, which is also fun, but at the same time don’t actually have to optimize *that* much)
-
@ireneista @MaddieM4 @mcc @decay @amarioguy there is also no escaping just how much of this was developed/invented for.... war
@r @MaddieM4 @mcc @decay @amarioguy thank you!
very helpful list
sigh, yes. maybe we can beat some swords into paintbrushes though...
-
@MaddieM4 Well, actually, music is so slow that a multi-gigahertz processor could probably do enough DSP for real-time music processing just on its fancy FPU.
@riley @MaddieM4 @ireneista @mcc @decay @amarioguy exactly. I do music on embedded because it has become so nice with even cheap silicon with minimal peripherals.
-
@MaddieM4 @ireneista *is* that done on on-board controller silicon? I would have assumed it's done in a CPU-driven userspace thing installed in to the regular operating system alongside the driver.
Like I'm certain they *could* do it with on-board controller silicon, if they wanted, but even then I suspect that on-board controller silicon would look a lot like a small ARM running a CPU-based compiler in a tiny Linux
-
@aeva @mcc if you want to start from historic, fatmap.txt is a pretty fun read (and you can then make your renderer look like it’s genuinely old and needs small polygons and has ordering issues and no perspective divide, which is also fun, but at the same time don’t actually have to optimize *that* much)
-
@ireneista @MaddieM4 @mcc @decay @amarioguy anyways, i _really_ struggle to actually *talk with* people who don't do well with this approach, and with social reach in general, so i haven't invested too much into this, but some patterns i've noticed nonetheless:
* some people just.... don't.... like.... symbols??? (i've been realizing how difficult a concept "abstraction" really is, and how much of the "cabal of Elite
️ universities" pressure (and toxicity) is in part an attempt to force you to learn their particular style of doing abstraction. but, otoh, the part i _really_ don't get is that there seem to exist people who don't like symbols in "equations" but are perfectly happy with symbols in computer code or on a graph)* a lot of this is insufficiently physical (even a project-based curriculum *run by the EE department* doesn't usually have as many fiddly doohickeys as "musicians" seem to like)
* everything is connected to everything else. this is either spelled out in *too much* detail or *too little* detail, never "just right". at the same time, everything is either too much "you are smart, you can do the computer-y bits by yourself" or else too much "here is something to plug into the computer", never "just right" either. (in case examples help: using pencil-and-paper to do the derivation from FT->DTFT->DFT is *really cool*, but unless you're already in the "right" mindset it just looks like shuffling a bunch of very similar very confusing symbols. afterwards, you either _never_ mention e.g. the python-scientific-stack or else you hand everyone a pile of python/matlab code for homework (where you need to fill some part in) )
@ireneista @MaddieM4 @mcc @decay @amarioguy oh also
* digital modeling of analog systems is *fiendishly* hard (or at least interdisciplinary), which makes it hard to fit into an EE-department-run curriculum. but musicians seem to have a *particular* interest in doing this
* ime the EE department (or at least ones that have, uh "communications" (and "war" of course) heritage) really focuses on various forms of accuracy and optimality. we have been discovering that, apparently, musicians *do not*. this implies that "optimizations and hacks" are not covered
-
@MaddieM4 @ireneista *is* that done on on-board controller silicon? I would have assumed it's done in a CPU-driven userspace thing installed in to the regular operating system alongside the driver.
Like I'm certain they *could* do it with on-board controller silicon, if they wanted, but even then I suspect that on-board controller silicon would look a lot like a small ARM running a CPU-based compiler in a tiny Linux
@mcc @ireneista it's not currently done with on-board silicon, it's just that there's capacity. Conventional GPUs work more like you're describing, doing that kind of work within the driver on the CPU.
I think it *should* be translated on the GPU controller, and that the reasons not to are more about proprietary economics than technology. I also think Linux is overkill for this, but Linux-compatible microcontrollers are so cheap at this point that it wouldn't be an insane way to implement it. To me, part of the point is establishing a stable (but extensible) binary standard for both programs and high level control commands, so that GPUs are a standardized micro-appliance. To me it's not so different from microcode allowing many generations of AMD64 with different microarchitecture to all speak AMD64.
-
@mcc @decay @amarioguy @MaddieM4 Fourier and wavelet transforms are really important though, even though most programs don't do them. but you raise a good point.
@ireneista @mcc @decay @amarioguy @MaddieM4 Fourier transforms will also happily run at GB/s rates on any modern GPU.
VkFFT is awesome.
-
@ireneista @MaddieM4 @mcc @decay @amarioguy oh also
* digital modeling of analog systems is *fiendishly* hard (or at least interdisciplinary), which makes it hard to fit into an EE-department-run curriculum. but musicians seem to have a *particular* interest in doing this
* ime the EE department (or at least ones that have, uh "communications" (and "war" of course) heritage) really focuses on various forms of accuracy and optimality. we have been discovering that, apparently, musicians *do not*. this implies that "optimizations and hacks" are not covered
@ireneista @MaddieM4 @mcc @decay @amarioguy oh, and, the "rest of the fucking owl" *software engineering* of computer music is essentially *not culturally connected* to this cluster of EE at all. this is before we get to the part where a bunch of this is """just""" convention and so the "cabal of Elite
️ universities" don't value itthink things like:
* "what is VST?" (what is an "API" more generallly?)
* "what is a real-time system?"
* "what is MIDI?"
* "what is DMX?"
* "how do i get signals from the real world into and out of my computer?"
* "what is a protocol, more generally?" -
@ireneista @mcc @decay @amarioguy @MaddieM4 Fourier transforms will also happily run at GB/s rates on any modern GPU.
VkFFT is awesome.
@ireneista @mcc @decay @amarioguy @MaddieM4 the big advantage of simd on modern cpu/gpu systems is very small inner loops and things like memcpy where the overhead of going to GPU and back overcomes the speed benefits
-
@ireneista @MaddieM4 @mcc @decay @amarioguy oh, and, the "rest of the fucking owl" *software engineering* of computer music is essentially *not culturally connected* to this cluster of EE at all. this is before we get to the part where a bunch of this is """just""" convention and so the "cabal of Elite
️ universities" don't value itthink things like:
* "what is VST?" (what is an "API" more generallly?)
* "what is a real-time system?"
* "what is MIDI?"
* "what is DMX?"
* "how do i get signals from the real world into and out of my computer?"
* "what is a protocol, more generally?"@r @ireneista @MaddieM4 @mcc @amarioguy me, perking up from behind my behringer x32
-
@ireneista @mcc @decay @amarioguy That's a good particular example. A part of computing freedom that I think is pretty important is "being able to make music with computers, ideally in realtime." I have that on my list of vital user stories for my someday project microkernel OS. The arts are the kind of thing that make computers worth doing.
A lot of realtime music plugin stuff depends of Fourier transforms and SIMD in general.
@MaddieM4 @ireneista @mcc @decay @amarioguy Music, as well as speech synthesis!
-
@MaddieM4 @decay @riley @ireneista @amarioguy *rubbing eyes* is SPIR-V an ISA? I thought it was literally a fork of LLVM IR
That is a very different abstraction level with very different forward compatibility commitment risks
@mcc @MaddieM4 The original SPIR was a fork of LLVM IR. SPIR-V is more or less "GLSL encoded as an SSA-based VM bytecode". @decay @riley @ireneista @amarioguy
-
@ireneista @mcc @decay @amarioguy @MaddieM4 the big advantage of simd on modern cpu/gpu systems is very small inner loops and things like memcpy where the overhead of going to GPU and back overcomes the speed benefits
@ireneista @mcc @decay @amarioguy @MaddieM4 like in ngscopeclient we ended up deleting a significant amount of the AVX code because it was slower than doing it on the GPU and was just one more implementation to keep in sync with everything else when we made changes, test, etc.
-
@r @ireneista @MaddieM4 @mcc @amarioguy me, perking up from behind my behringer x32
@decay @ireneista @MaddieM4 @mcc @amarioguy it's *still* wild to me that there exists audio gear that costs more than something like an eNodeB
-
@mcc @decay @riley @ireneista @amarioguy Architecture revision is a very reasonable good faith assumption to make, which GPU companies IMHO do not even slightly deserve. It's just an IP protection thing.
SPIR-V would not exist, in an extremely successful way, if GPU ISAs were a bad idea for technical reasons. It exists nestled into Vulkan as a compromise with IP protection.
@MaddieM4 @mcc @decay @riley @ireneista @amarioguy GPU shader processor architectures did go through a few different evolutions so there was something to that but I think they've more or less stabilized on what is and isn't a good idea (access memory through a plain pointer, do SIMD between shader invocations, not within one, that sort of thing). But even so there are a lot of subtly different approaches to things like flow control or sampler state to give just two examples.
-
@decay @ireneista @MaddieM4 @mcc @amarioguy it's *still* wild to me that there exists audio gear that costs more than something like an eNodeB
@r @ireneista @MaddieM4 @mcc @amarioguy our production kit is built around a Behringer x32 Producer which is not cheap but not crazy expensive, but you're basically talking a mildly chunky computer attached to a shitload of power amps that has to be able to bounce around in the back of a truck for a substantial amount of its life and work perfectly as soon as power is applied, which is really what you're paying for. Not quite aerospace but close
-
@r @ireneista @MaddieM4 @mcc @amarioguy our production kit is built around a Behringer x32 Producer which is not cheap but not crazy expensive, but you're basically talking a mildly chunky computer attached to a shitload of power amps that has to be able to bounce around in the back of a truck for a substantial amount of its life and work perfectly as soon as power is applied, which is really what you're paying for. Not quite aerospace but close
