Rust wgpu now has a
-
Anyway, I spent the last week writing documentation for Redox. The Redox project seems to be happy for my documentation patches. One thimble full of water, out of the sinking boat.
@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
-
@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
@mcc something I was surprised to discover when I picked up pygame to fart around with a few years ago, is there was a lot of documentation effort put forth towards dispelling old best practices that weren't necessary anymore, because CPUs are just so much faster now than they were in the early 2000s, and we don't really need to do dirty rects and stuff for most things to get good performance anymore.
-
@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 i want to make a simple FPGA design for a CPU peripheral that can render flat-shaded triangles from a list directly to HDMI SERDES and make a game where two tanks across from each other on a tennis court fire orbs at each other and then have to recover and fire them back on a timer, and then make a fake Activision Atari-looking boxart for it saying
TANK TENNIS
ELECTRONIC VIDEO ENTERTAINMENT EXPERIENCE
FOR RISC-V🄯 SYSTEMSADVANCED 3D GRAPHICS
-
@mcc something I was surprised to discover when I picked up pygame to fart around with a few years ago, is there was a lot of documentation effort put forth towards dispelling old best practices that weren't necessary anymore, because CPUs are just so much faster now than they were in the early 2000s, and we don't really need to do dirty rects and stuff for most things to get good performance anymore.
@mcc and I found that also to be true with mollytime. CPUs have been very fast for a long time. I thought mollytime's somewhat naive internals would only be practical on semi-recent hardware, but it seems to work reasonably well on 20 year old hardware as well.
-
@aeva i want to make a simple FPGA design for a CPU peripheral that can render flat-shaded triangles from a list directly to HDMI SERDES and make a game where two tanks across from each other on a tennis court fire orbs at each other and then have to recover and fire them back on a timer, and then make a fake Activision Atari-looking boxart for it saying
TANK TENNIS
ELECTRONIC VIDEO ENTERTAINMENT EXPERIENCE
FOR RISC-V🄯 SYSTEMSADVANCED 3D GRAPHICS
@aeva …but I'm not doing that. I'm doing things that I want to do less than that
-
@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 @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.
-
@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
-
@mcc and I found that also to be true with mollytime. CPUs have been very fast for a long time. I thought mollytime's somewhat naive internals would only be practical on semi-recent hardware, but it seems to work reasonably well on 20 year old hardware as well.
@mcc I think the broader tech industry managed to convince itself that CPUs were just inherently incurably slow and just kinda forgot that they've been fast for a long time, which is maybe fortunate because if these perpetual GPU shortages we've been having since crypto currency scams became a thing (and only have gotten worse), then if CPUs are unfashionable but secretly very fast, well, maybe I can learn to live with that.
-
@radgeRayden @aeva There is some background context here. Aeva is more looking to write a 3D rendering environment than she is looking for a 3D rendering environment to use.
Also, I spent some years making a commercial video game in a 3D variant of LÖVE , although it did not ship https://www.youtube.com/watch?v=HLBAjKQNmFI
-
@MaddieM4 @hyc @ireneista @mcc @decay @amarioguy that was probably the right move, for people *already* "doing engineering"
maybe this is wishful thinking, but i was hoping it was possible to teach (or at least.... make accessible?) the ideas to people who haven't yet realized they are "doing" "engineering"
-
@radgeRayden @aeva There is some background context here. Aeva is more looking to write a 3D rendering environment than she is looking for a 3D rendering environment to use.
Also, I spent some years making a commercial video game in a 3D variant of LÖVE , although it did not ship https://www.youtube.com/watch?v=HLBAjKQNmFI
-
@radgeRayden @aeva Yes, I did. Or rather Bjorn Swenson did. And then I used his renderer
-
@ireneista @mcc @decay @riley @amarioguy Right. And you don't even need to do it very "live", since you really just need primitives for messing with VRAM (including uploading code) and creating a reusable lowered piece of code, handwave handwave.
-
@mcc I think the broader tech industry managed to convince itself that CPUs were just inherently incurably slow and just kinda forgot that they've been fast for a long time, which is maybe fortunate because if these perpetual GPU shortages we've been having since crypto currency scams became a thing (and only have gotten worse), then if CPUs are unfashionable but secretly very fast, well, maybe I can learn to live with that.
@mcc it's too bad that the kinds of things I want to make are more in the "what if the gamecube also had real vertex & fragment shaders" territory and not "doom mod" territory or I'd be having an easier time of it right now
-
@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
