Rust wgpu now has a
-
@amarioguy @mcc I mean I feel about modern GPUs and their intentionally prohibitive feature span the way I do about web standards: "that's a nice miracle you destroyed the ecosystem with. Undoing the damage is probably a multi-decade job and none of the normal folk will understand why feature reductions are needed. Won't stop me from patiently pushing in the right direction, though."
@MaddieM4 @amarioguy a mental tool i keep using is
"this standard is too large" +
"if i make my own standard, no one will use it"
=>
"can i find a subset of the too-large standard which is tractable to implement, so i can target the subset, and at least the things i create will be usable by users of the 'large' standard" -
@poetaster @MaddieM4 "joy was too big so instead we carried misery"
-
@mcc @sabrina does "fast 2D desktop" include something like video playback at modern screen resolutions, or is a desktop stack from, say, the late 90s acceptable? I've been putting a little time here and there into rewriting Window Maker, and it seems to work perfectly well with only a few calls to the X server, which could do everything in software and probably work fine. But modern Web browsers and media players ask for a lot.
@trurl @sabrina If a goal is to make the task small enough you can complete it, accelerated video may be one of the first things that has to go.
However also people *want* accelerated video. So if you build everything *else*, maybe someone pops up to contribute that piece.
(Also: One question I'd ask is whether dedicated video acceleration ASICs still exist. As recently as ~2010 it was not expected your video acceleration and your rendering acceleration would be the same piece of silicon.)
-
As recently as like, a year ago, I believed that we couldn't trust hardware companies. I thought the biggest concern was that we'd get locked into a situation where at least for handheld devices like phones, if you want to buy one you get locked into a duopoly where you have to use one of two corp operating systems and you have to accept all kinds of DRM and identity tracking and such. I wanted a solution. So I was very interested in RISCV and I was trying to imagine the GPU version of RISCV.
@mcc On a tangent..
Wasn't RISC-V itself conceived as the kind of processor that can be so simple that you could smoosh 128 of them together as an array of GPU shaders?
So a complete system would have RISC-V units of different complexities and scale depending on their role.
-
@trurl @sabrina If a goal is to make the task small enough you can complete it, accelerated video may be one of the first things that has to go.
However also people *want* accelerated video. So if you build everything *else*, maybe someone pops up to contribute that piece.
(Also: One question I'd ask is whether dedicated video acceleration ASICs still exist. As recently as ~2010 it was not expected your video acceleration and your rendering acceleration would be the same piece of silicon.)
-
@trurl @sabrina If a goal is to make the task small enough you can complete it, accelerated video may be one of the first things that has to go.
However also people *want* accelerated video. So if you build everything *else*, maybe someone pops up to contribute that piece.
(Also: One question I'd ask is whether dedicated video acceleration ASICs still exist. As recently as ~2010 it was not expected your video acceleration and your rendering acceleration would be the same piece of silicon.)
@mcc @sabrina I am 100% sympathetic to the line of thinking you've shared here, and it's inspiring. (Redox has come a long way since I last looked. I should try it out.)
I'm asking about what I consider the basics need because hardware acceleration of some stripe may actually be necessary these days, given screen resolutions and expectations about tearing. I haven't peered that deeply into the stack lately, and things in X that seem like simple blitting may actually do more these days.
-
@amarioguy @mcc I mean I feel about modern GPUs and their intentionally prohibitive feature span the way I do about web standards: "that's a nice miracle you destroyed the ecosystem with. Undoing the damage is probably a multi-decade job and none of the normal folk will understand why feature reductions are needed. Won't stop me from patiently pushing in the right direction, though."
@MaddieM4 @mcc honestly, very fair point, was definitely something i was considering as well, and i personally would be VERY happy with a fully properly no slop open sourced GPU even if it had a limited audience and/or limited scope, GPU land has felt so prohibitively closed for so long that i'd definitely be chomping at the bits to try it out
-
@MaddieM4 @mcc honestly, very fair point, was definitely something i was considering as well, and i personally would be VERY happy with a fully properly no slop open sourced GPU even if it had a limited audience and/or limited scope, GPU land has felt so prohibitively closed for so long that i'd definitely be chomping at the bits to try it out
@amarioguy @MaddieM4 i am far from the only person to think about this. someone will do it eventually. the question is when we hit one that has riscv levels of Go Juice.
-
@poetaster @MaddieM4 I continued writing OpenGL in C *from* the 1990s all the way up until last year and I would like to stop now.
@mcc Ok, you didn't take breaks! No wonder. I move around a lot to keep the fatigue at bay.
-
@lispi314 @froge i am writing this on a computer from 2016 and i cannot imagine wanting a better computer than that. i don't know what the point would be. if any computer i purchase after this is from later than 2016 it will be for the sole reason that computers from 2016 are not being made anymore.
in fact, if i could, i'd probably go further back, to 2014, when S3 sleep still existed, and it was therefore possible to run Linux.
@mcc@mastodon.social @froge@social.glitched.systems Yeah, I’m also using decade+ old hardware for most things other than the gaming machine.
It works and does the job so it’s fine. Although on one of them spare part availability at remotely acceptable prices is slowly becoming a problem (amusingly it’s not the 20+ years old one).
The follow-up model on that one is from 2014~ish (unfortunately that runs into ECC DDR4 prices issues, but hopefully that’ll die down before I have to deal with it).
when S3 sleep still existed, and it was therefore possible to run Linux.
I don’t think I ever had hardware on which hardware sleep wasn’t broken.
Only one machine has crossed the two-decades cap so far, that one does visibly struggle with modern SSH initialization/handshake, has no virtualization support and wireguard is heavier than it should be so it has limited tasks.
The SSH issue was mitigated by some configuration to improve efficiency, mostly around session persistence and multiplexing. Paying the cost of the heavy handshake once instead of every single Ansible task is a noticeable improvement.
-
@erincandescent My desktop is from 2016 and I see zero, literally zero, reason to upgrade it. There is no reason to use a piece of hardware released past 2024 except for the fact that eventually the pre-2024 hardware will wear out. Anyway the remainder of the thread is substantially about RISCV
@mcc @erincandescent If one doesn't play (new) games (or ones that refuse to support older hardware) or use software with fussy hard requirements on newer features, the need gets much lesser indeed. -
@MaddieM4 @amarioguy a mental tool i keep using is
"this standard is too large" +
"if i make my own standard, no one will use it"
=>
"can i find a subset of the too-large standard which is tractable to implement, so i can target the subset, and at least the things i create will be usable by users of the 'large' standard"@mcc @amarioguy a wise approach, honestly.
-
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.
The words "hardware-accelerated video on" in that first entry are doing a lot of heavy lifting...
-
@mcc @erincandescent If one doesn't play (new) games (or ones that refuse to support older hardware) or use software with fussy hard requirements on newer features, the need gets much lesser indeed.
@lispi314 @erincandescent one problem is i want to *create* games and those are by nature new. and that creates nonzero complications
-
Meanwhile, look at the other staircase I want to climb.
I *don't* have an open-hardware laptop. I have a Lenovo with an AMD chipset. I want a slopless operating system. Redox the OS is slopless, but much of the GUI running atop it is just ports of Linux software, and much of that is slop. The project I've been thinking about *this* year is hacking Redox to boot direct into Servo (the web browser). As I explore this idea, suddenly my "wgpu direct to hardware" idea becomes relevant again:
@mcc@mastodon.social Redox depending on implementation-defined Rust where the main tooling is being slopped if not Rust itself does seem like a problem.
Have or are they considering pinning the Rust dependency to a pre-slop version?
(Honestly the language needs a hard fork that solidifies on a proper specification and then goes specification-driven. These problems will keep happening while it hasn’t.)
-
@amarioguy @MaddieM4 i am far from the only person to think about this. someone will do it eventually. the question is when we hit one that has riscv levels of Go Juice.
@mcc @amarioguy @MaddieM4 there's also a thing where...
our friends who do CPU stuff don't seem to think riscv is going to be outside of the systems of oppression that cause trouble, and we do for sure see how stuff like core layout and fabrication are bottlenecks that allow hegemony to form...
by all means a GPU that's as open as riscv is would be awesome, but there's more to aspire to
-
@lispi314 @erincandescent one problem is i want to *create* games and those are by nature new. and that creates nonzero complications
@mcc @erincandescent It certainly does indeed, though it does also put you in the position to evaluate how hostile the engine or framework you intend to use is to older hardware.
(Granted depending on what you want them to do exactly, there are limits to that.)
Presumably given your no-slop & older computing habits, you'd be intent on something quite friendly.
That does leave you with the problem that the groundwork needed to get started needs to be done. A rather unfortunate setback. -
@mcc@mastodon.social Redox depending on implementation-defined Rust where the main tooling is being slopped if not Rust itself does seem like a problem.
Have or are they considering pinning the Rust dependency to a pre-slop version?
(Honestly the language needs a hard fork that solidifies on a proper specification and then goes specification-driven. These problems will keep happening while it hasn’t.)
@lispi314 I don't think they're discussing this. This is I believe a very big problem but not my concern at the current time because (1) you need a programming language; that's not optional (1.5) i no longer acknowledge the existence of C (2) there are already at least four Rust backends and at least two frontends (3) i am much more confident i can create an independent Rust implementation than I am confident that I can do literally *any* of the projects described in the thread above.
-
@lispi314 I don't think they're discussing this. This is I believe a very big problem but not my concern at the current time because (1) you need a programming language; that's not optional (1.5) i no longer acknowledge the existence of C (2) there are already at least four Rust backends and at least two frontends (3) i am much more confident i can create an independent Rust implementation than I am confident that I can do literally *any* of the projects described in the thread above.
@lispi314 I do think something is wrong with our framing of the disussion that people are perpetually concerned about slop in Rust but are not concerned about same in C when GCC and clang are both slopped and, in fact, LLVM is the main slop contributor to the Rust implementation at the current time. "But Rust?" is not really a useful objection unless you plan to write an OS in Zig. And as described above, we don't even have an OS in Rust yet.
-
@lispi314 I do think something is wrong with our framing of the disussion that people are perpetually concerned about slop in Rust but are not concerned about same in C when GCC and clang are both slopped and, in fact, LLVM is the main slop contributor to the Rust implementation at the current time. "But Rust?" is not really a useful objection unless you plan to write an OS in Zig. And as described above, we don't even have an OS in Rust yet.
@mcc@mastodon.social Oh GCC is fucked as well.
We (disgruntled GCC users) are talking about alternative C compilers, and for x86_64/i686 the situation is relatively not that bad if one doesn’t use a lot of GCC/CLANG extensions.
(Other hardware though? Not good.)
The problem has also reached some Common Lisp implementations. But I don’t need to use SBCL, when ECL, ABCL & others exist and will work with any compliant program written with portable libraries (it’s seen quite negatively to write implementation-specific libraries unless they’re explicitly named after and targeting a feature of a specific implementation, which will have people avoid it).
Zig is actively looking to move away from LLVM. Zig also being implementation-specified annoys me too. (It does for every language, for me.)
