Rust wgpu now has a
-
@cr1901 @aparrish @mntmn it does seem like periods of many, many years pass between the popular FPGA chips changing in literally any substantial way at all. this said, wq was talking a few weeks ago about how atypical changes in "preferred" commodity FPGA chips *are* actually happening kind of rapidly right now due to "wars are happening in the vague zone between Yemen and Estonia" related issues
-
-
@ireneista @r @MaddieM4 @mcc @decay @amarioguy they don't bother teaching you why it's useful. https://mastodon.social/@hyc/116947095099572153
-
@decay @riley @MaddieM4 @ireneista @amarioguy That's very interesting, but presumably the reason GPU companies don't do this already is because committing to a fixed ISA makes it much harder to rev architectures.
But it is the case that if I attempted an OSS GPU, in step one the "shader units" would almost certainly just be compiling the shader programs to RISCV plus one of the vector extensions, grabbing a RISCV softcore, and splatting twenty of them on the fabric.
-
@ireneista @r @MaddieM4 @mcc @decay @amarioguy they don't bother teaching you why it's useful. https://mastodon.social/@hyc/116947095099572153
@hyc @ireneista @r @mcc @decay @amarioguy It's such a common error. If anything you should be LEADING with the why.
My pet conspiracy theory why they don't, is that most curricula are designed by committee and lean toward including everything that sounds like it might be useful. This lack of discretion means that most of the material IS pointless for the students, and "well you might need it some way" is cover for "we can't explain why because there IS no good answer behind the curtain." And in situations where there IS a good answer, there's so much bad faith precedent that the students can't tell the difference.
This is why I think project-centered education would be revolutionary. It leads you to discover things in contextualized, justified, concrete ways.
-
@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
-
Please be assured that the so-called "Mr. Stabby" update only got through the software release process through a fluke.
We've taken steps to improve our development process by making all our programmers watch 18 hours of our in-house-developed "Don't write bugs!" motivational videos. We are also planning to hire a software tester, someday.
-
@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 there is also no escaping just how much of this was developed/invented for.... war
-
@decay @riley @MaddieM4 @ireneista @amarioguy That's very interesting, but presumably the reason GPU companies don't do this already is because committing to a fixed ISA makes it much harder to rev architectures.
But it is the case that if I attempted an OSS GPU, in step one the "shader units" would almost certainly just be compiling the shader programs to RISCV plus one of the vector extensions, grabbing a RISCV softcore, and splatting twenty of them on the fabric.
@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.
-
@hyc @ireneista @r @mcc @decay @amarioguy It's such a common error. If anything you should be LEADING with the why.
My pet conspiracy theory why they don't, is that most curricula are designed by committee and lean toward including everything that sounds like it might be useful. This lack of discretion means that most of the material IS pointless for the students, and "well you might need it some way" is cover for "we can't explain why because there IS no good answer behind the curtain." And in situations where there IS a good answer, there's so much bad faith precedent that the students can't tell the difference.
This is why I think project-centered education would be revolutionary. It leads you to discover things in contextualized, justified, concrete ways.
@MaddieM4 @hyc @ireneista @mcc @decay @amarioguy my old university indeed threw out the earlier parts of their signals-and-systems curriculum and replaced it with something project-centered
-
@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 @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
-
@MaddieM4 @hyc @ireneista @mcc @decay @amarioguy my old university indeed threw out the earlier parts of their signals-and-systems curriculum and replaced it with something project-centered
@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"
-
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.
