Rust wgpu now has a
-
What I mean is, my daydream GPU was going to be designed to be good for the kinds of 2D acceleration you need to like, run a web browser, scroll a window, move a window around. Want to do anything 3D? It's slow or it kicks you back out to MESA software rendering. I just wanted a computer I can use in a day to day way that felt like it was mine and I owned it.
There are a few rudimentary open source GPUs, but none with this focus, and critically, *none I know that support Vulkan*.
@mcc modern GPUs have no dedicated 2D acceleration hardware, it's all done in 3D shaders.
I'd think it's relatively easy to do dedicated 2D acceleration in an FPGA these days. Aside from a Blitter what other functional units do you need to implement? It would be enough to run X11 without more recent extensions.
-
@mcc modern GPUs have no dedicated 2D acceleration hardware, it's all done in 3D shaders.
I'd think it's relatively easy to do dedicated 2D acceleration in an FPGA these days. Aside from a Blitter what other functional units do you need to implement? It would be enough to run X11 without more recent extensions.
@hyc Your first paragraph answers your second. It's not enough to make fast 2D blitting/compositing/blending. You have to do it in a way that can talk to the 3D APIs modern compositors and userspace software speaks.
-
Here's where we get to the funny part:
When I was looking at making an OSS GPU, I had this idea. Instead of supporting Vulkan, which is really a quite large API surface, I imagined a GPU that natively speaks WebGPU. WebGPU is designed as a simplified API covering the shared subset between Metal, DirectX, and Vulkan. Imagine instead of Vulkan I just make a hacked wgpu that connects directly to my open-source toy "RISCV GPU". My estimation as a moderate domain expert is that saves a *lot* of time
@mcc What's the smallest API and implementation necessary to accelerate a GUI so that it feels good? What's the minimum amount of hardware to support that acceleration?
Like, could you do 10% of WebGPU on top of CPU SIMD (or whatever) extensions to make the GUI not painful? This is well below the level I have ever worked at, so I won't be surprised if the answer is "no".
-
Servo rests atop wgpu. Therefore, if my OS's entire GUI layer is servo, and I believe that implementing webgpu is easier than implementing vulkan, I can increase my chances of writing a working video-acceleration driver if I simplify it so *the driver supplies wgpu*, instead of trying to support the full scope of DRI/DRM or OpenGL/Vulkan or whatever this entails.
Two things I want, in both cases wgpu provides a critical, project-saving step.
And oh, I think wgpu might be slop now. Never mind!
I am not the only person who wants what I want: Software by humans for humans, the ability to "use a computer" without participating in this horrible thing that AI companies are trying to build out of what used to be society. Everybody's grabbed the task closest to them. I know of a slopfree book ereader. I know of a slopfree password manager. We're all dependent on stuff further down the stack, and the stack became tall at some point, and only a few items in the stack have a slopfree principle.
-
I am not the only person who wants what I want: Software by humans for humans, the ability to "use a computer" without participating in this horrible thing that AI companies are trying to build out of what used to be society. Everybody's grabbed the task closest to them. I know of a slopfree book ereader. I know of a slopfree password manager. We're all dependent on stuff further down the stack, and the stack became tall at some point, and only a few items in the stack have a slopfree principle.
This thread is probably meandering and maybe solipsistic. My point is this: My weird background means I can look at this staircase full of missing stairs, identify one step, and go, "I can fix that". But I don't know if there's enough of me to fix multiple steps. I haven't decided what to do from here. Pick a step and fix it anyway? Pick a "fun" project, like the GPU [which face it, even if I finished it chances are not high more than 3 people would ever use it]? Give up and learn electric bass?
-
This thread is probably meandering and maybe solipsistic. My point is this: My weird background means I can look at this staircase full of missing stairs, identify one step, and go, "I can fix that". But I don't know if there's enough of me to fix multiple steps. I haven't decided what to do from here. Pick a step and fix it anyway? Pick a "fun" project, like the GPU [which face it, even if I finished it chances are not high more than 3 people would ever use it]? Give up and learn electric bass?
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.
-
People who are making FPGA GPUs are usually hardware folks and usually interested in like, running a game or something. I'm not a hardware folk. But I'm familiar enough with 3D APIs and OS midlayers I could, with a lot of work, make a GPU that doesn't just run demos but connects all the way up to Linux or some other desktop OS. And then we've finally got the open source laptop entire stack bottom to top, motherboard cpu gpu libreboot linux.
Except then Linux went finally, undeniably corporate.
@mcc for completeness, i already had a PoC of this btw that i'm planning to revive https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.html
-
Servo rests atop wgpu. Therefore, if my OS's entire GUI layer is servo, and I believe that implementing webgpu is easier than implementing vulkan, I can increase my chances of writing a working video-acceleration driver if I simplify it so *the driver supplies wgpu*, instead of trying to support the full scope of DRI/DRM or OpenGL/Vulkan or whatever this entails.
Two things I want, in both cases wgpu provides a critical, project-saving step.
And oh, I think wgpu might be slop now. Never mind!
@mcc Mesa does make implementing Vulkan somewhat easier, I think in some of the same ways that just implementing webgpu directly would, in that a lot of the redundant API surface is provided by shared code. And in particular you probably want to use Mesa for the compiler framework it provides, something that would be a pretty big lift otherwise. I think it doesn't have a WGSL frontend but that doesn't seem like it would be too hard to write.
-
@mcc What's the smallest API and implementation necessary to accelerate a GUI so that it feels good? What's the minimum amount of hardware to support that acceleration?
Like, could you do 10% of WebGPU on top of CPU SIMD (or whatever) extensions to make the GUI not painful? This is well below the level I have ever worked at, so I won't be surprised if the answer is "no".
@sabrina Yes, exactly. This is exactly the question I am posing. But here is the hard part:
Imagine identifying the operations you need for a fast 2D desktop. Can you implement those operations in FPGA? Trivially. This would be a fun, fast project. *The software you want to run would not be written to use those operations*. Modern software is doing its 2D by sitting atop OpenGL or Vulkan. So the difficult part is *identifying parts of Vulkan and OpenGL* that in practice a 2D program uses.
-
Rust wgpu now has a .agents/skills, a .claude/skills, an AGENTS.md, and a CLAUDE.md.
Increasingly wondering if my goal of living in a way that I never benefit from the actions of generative AI users and generative AI users never benefit from the actions of me is going to inherently mean never using hardware-accelerated video on a computer again.
@mcc got bad news about the hardware itself
-
@mcc got bad news about the hardware itself
@rcombs For thoughts on hardware, see the entire rest of the thread. I could use a RISCV CPU implementation made before 2025, if only I could display a triangle.
-
@mcc Mesa does make implementing Vulkan somewhat easier, I think in some of the same ways that just implementing webgpu directly would, in that a lot of the redundant API surface is provided by shared code. And in particular you probably want to use Mesa for the compiler framework it provides, something that would be a pretty big lift otherwise. I think it doesn't have a WGSL frontend but that doesn't seem like it would be too hard to write.
@crzwdjk That's some good clear thinking, thank you.
I am not sure but I think the bridge-to-GPU layer in Linux goes through a middle step named "DRI" or "DRM", and I think Redox plans to adopt this wholesale. I don't know to what extent DRI/DRM is about just *configuring* displays and to what extent if you've implemented the DRI/DRM layer then Mesa just does the rest for free.
-
People who are making FPGA GPUs are usually hardware folks and usually interested in like, running a game or something. I'm not a hardware folk. But I'm familiar enough with 3D APIs and OS midlayers I could, with a lot of work, make a GPU that doesn't just run demos but connects all the way up to Linux or some other desktop OS. And then we've finally got the open source laptop entire stack bottom to top, motherboard cpu gpu libreboot linux.
Except then Linux went finally, undeniably corporate.
@mcc I was thinking of making a 2D GPU, it's something I might still take up one day if I end up with a lot of free time for whatever reason.
-
Rust wgpu now has a .agents/skills, a .claude/skills, an AGENTS.md, and a CLAUDE.md.
Increasingly wondering if my goal of living in a way that I never benefit from the actions of generative AI users and generative AI users never benefit from the actions of me is going to inherently mean never using hardware-accelerated video on a computer again.
@mcc In 2043 mcc creates the last truly slop-free, hardware-accelerated video game using Vulkan SC on a retired 737 Cockpit Display System. Worldwide only four systems remain capable of running the game as intended after the FAA and EASA finally embraced Generative AI and the population learned to accept the catastrophic loss of %0.018 of flights.
-
@mcc
Well, maybe not simultaneously, but I think you could do both if you wanted to.@brouhaha I don't know how many years I have and I don't know how many years I'm able, constitutionally, to go without reaching a goal. If doing A does not achieve my goal without B, can I actually get all the way to the end of A knowing that I've still got to do all of B when I'm done? What if writing both A and B takes so many years together that the definition of what you need for A and B to work shifts in the meantime?
-
@mcc (probably this requires never upgrading to any piece of hardware released past ~2024 or so)
@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 Redox needs to be broken up a bit so we can do some mix-and-matching.
@khleedril A thing I have seen discussed in Redox space is running Linux in a VM so it can steal Linux's kernel modules.
-
@hyc Your first paragraph answers your second. It's not enough to make fast 2D blitting/compositing/blending. You have to do it in a way that can talk to the 3D APIs modern compositors and userspace software speaks.
@mcc Most of the software I want to use doesn't need a modern compositor.
But I'd love to see an accelerator API that you can use standalone, without having to build all of Xorg mesa first.
-
Servo rests atop wgpu. Therefore, if my OS's entire GUI layer is servo, and I believe that implementing webgpu is easier than implementing vulkan, I can increase my chances of writing a working video-acceleration driver if I simplify it so *the driver supplies wgpu*, instead of trying to support the full scope of DRI/DRM or OpenGL/Vulkan or whatever this entails.
Two things I want, in both cases wgpu provides a critical, project-saving step.
And oh, I think wgpu might be slop now. Never mind!
@mcc wgpu is a slightly simpler API to use, but I'm not sure I'd categorize it as easier to implement. Basically it means doing a whole bunch of extra work in the driver. Whereas vulkan itself has a bunch of shared implementation in e.g. Mesa, and a huge test suite, and also much of it is optional anyway.
-
People who are making FPGA GPUs are usually hardware folks and usually interested in like, running a game or something. I'm not a hardware folk. But I'm familiar enough with 3D APIs and OS midlayers I could, with a lot of work, make a GPU that doesn't just run demos but connects all the way up to Linux or some other desktop OS. And then we've finally got the open source laptop entire stack bottom to top, motherboard cpu gpu libreboot linux.
Except then Linux went finally, undeniably corporate.
@mcc instead of going with an fpga have you looked at some of the simpler GPU cores (like the powervr ones)?
