So it seems we need something like kernel mode setting, but then for older hardware that doesn't support KMS would still need something in user land.
Idk if this abstraction fully applies to plan9. And then something for a direct rendering manager... At least this is what I reflect from how Linux does it and that might not be the best approach here. On Fri, Nov 28, 2025, 12:24 PM <[email protected]> wrote: > Quoth Clout Tolstoy <[email protected]>: > > This talks loops back to my hopes for the gpufs, but the drivers are in > the > > way. Maybe matrox cards could be a good entry point for proper driver > > support? > > Intel cards seem to be the best documented, for example this > seems to have links to fairly complete manuals: > > > https://cdrdv2-public.intel.com/772631/graphics-for-linux_developer-reference_1.0-772629-772631.pdf > > including register references. > > AMD is less well documented, but also has docs: > > > https://gpuopen.com/amd-gpu-architecture-programming-documentation/ > > Their docs focus almost exclusively on the instruction set, and say > very little about the graphics pipeline and modesetting, however, > there is an open source driver, and there are old docs for old 2010 > era cards that can serve as a starting point. > > But in the the end, someone motivated needs to sit down and write > code; There is no simple, easily obtained, fast, and well documented > hardware out there. We get a couple of the checkboxes, and then some > motivated soul need to start working through the rest. > > Even modesetting would be valuable. > > But it's stil a lot of work, and it won't get done until someone > actually sits down and starts wiggling their fingers. > > On Fri, Nov 28, 2025, 10:05 AM Paul Lalonde <[email protected]> > > wrote: > > > > > I'm going to be Debbie Downer here. > > > > > > I worked on GPUs most of my career, from the early days of graphics > > > acceleration to the first 3D games consoles, to the start of shader > > > processing through to modern Nvidia architectures. > > > > > > A GPU is *absurdly* more complex than is visible from its API surface, > > > which itself is maddenly complex. Vulkan gives an inkling of what has > to > > > be going on under the hood and what kinds of constraints exist to make > a > > > performant graphics engine work. > > > > > > The reason that plain compute looks more attractive is that the > hardware > > > surface is so much smaller. You don't have to worry about texture > engines, > > > rasterizers, tiling, ROPs, in-order completion rules, and > > > myriad constraints on the memory subsystem to satisfy all these > hardware > > > units. Yes, compute leaves half the functionality that makes graphics > > > possible on the floor, but it also leaves all of its complexity there. > > > > > > I like the 9p approach to 3D graphics - retained mode APIs have a long > > > history because of their usability. I'd be happy to use such a thing > on > > > Plan9. But a driver for *any* modern GPU is not an achievable target > for a > > > small band of independent developers. > > > > > > Paul > > > > > > On Fri, Nov 28, 2025 at 8:03 AM Shawn Rutledge <[email protected]> > wrote: > > >> > > >> On Nov 28, 2025, at 13:50, [email protected] wrote: > > >> > > >> Quoth ron minnich <[email protected]>: > > >> > > >> A very quick test > > >> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ GOOS=plan9 > GOARCH=amd64 > > >> go build . > > >> package github.com/hajimehoshi/ebiten/v2/examples/snake > > >> imports github.com/hajimehoshi/ebiten/v2 > > >> imports github.com/hajimehoshi/ebiten/v2/internal/inputstate > > >> imports github.com/hajimehoshi/ebiten/v2/internal/ui > > >> imports github.com/hajimehoshi/ebiten/v2/internal/glfw: build > constraints > > >> exclude all Go files in /Users/rminnich/Documents/ebiten/internal/glfw > > >> (base) Rons-Excellent-Macbook-Pro:snake rminnich$ pwd > > >> /Users/rminnich/Documents/ebiten/examples/snake > > >> > > >> So there's a glfw issue, whatever that is :-) > > >> > > >> > > >> GLFW is, IIRC, an OpenGL-based library. > > >> > > >> a portable language doesn't help when all graphical toolkits > > >> rely on interfaces that are not available :) > > >> > > >> > > >> GLFW is one of the lightest libraries for wrapping OpenGL rendering > into > > >> a real window in a cross-platform way, and handling input. > > >> https://www.glfw.org/ > > >> > > >> The Plan 9 community needs to start at the bottom IMO: get serious > about > > >> supporting GPUs in some way. So far the talk about GPUs has been > > >> hand-waving along the lines of using it as some sort of parallel > computer > > >> for limited “compute” use cases, as opposed to the original > application of > > >> rendering graphics. But sure, if you can make it into a general > parallel > > >> computer, and then still develop shader kernels (or whatever we call > them > > >> in that kind of paradigm) that can render certain kinds of graphics, > maybe > > >> it would be possible to accelerate some of the draw operations. At > least > > >> we have a chance to be original, ignore accepted wisdom about how to > make > > >> graphics fast, and do it another way which might be more general. > Maybe. > > >> > > >> There is also the idea that if GPUs turn out to be indispensable for > > >> general computing (especially AI), we won’t want to “waste” their > power on > > >> basic graphics anymore. Nearly every computer has a GPU by now, and > if you > > >> run Plan 9 on it, you are letting the Ferrari sit there in the garage > doing > > >> nothing for the rest of its life: that’s a shame. But if you could > use it > > >> for serious computing, but actually use it only for drawing 2D > graphics, > > >> that’s like using the Ferrari only for short shopping trips: an > improvement > > >> over total idleness, but also a bit of a shame. If you find out that > you > > >> can make money by racing the Ferrari, or something, maybe you don’t > drive > > >> it to the store anymore. We won’t mind wasting the CPU to draw > rectangles > > >> and text if it turns out that the real work is all done on the fancy > new > > >> parallel computer. I’m not sure how that will turn out. I’ve always > > >> wanted a GPU with a long-lived open architecture, optimized for 2D; > but > > >> gaming was the main market selling GPUs until Bitcoin and LLMs came > along, > > >> so we have that kind of architecture: more powerful than we need in > the > > >> easy cases, but also less convenient. Given that, I suppose finding > the > > >> most-general API to program them would make some sense. > > >> > > >> Probably someone could pick a relatively easy target to start with: a > GPU > > >> that is sufficiently “open” to have a blob-free mainline Linux driver > > >> already, and try to get it somehow going on 9. None of them are > really > > >> open hardware, but for example there are enough docs for the > videocore IV > > >> on raspberry pi’s, maybe other embedded ones like imagination tech, > Radeon > > >> and Intel on PCs, etc. (And I also don’t have any such low-level > > >> experience yet, I just read about it and think: if only I had more > lives, > > >> maybe I could find time for that…) > > >> > > >> You could use draw to render fancy graphics already (I guess that is > what > > >> you are thinking), but it would be lots of CPU work, consequently > slow, and > > >> without antialiasing (except for text). Draw can render lines and > polygons > > >> at any angle, and Bézier curves, but thou shalt not antialias them, > because > > >> that would be a change and we don’t like change - that’s the vibe I’m > > >> getting from the community. So someone could go ahead and port > ebiten, but > > >> it might be a lot of work, and it won’t look as good even if you put > up > > >> with the speed, I suspect, unless they already have a CPU renderer. > Do > > >> they, or is it OpenGL-only? But you can maybe find such a rendering > engine > > >> that can draw vector graphics with AA. At that point, you just > generate > > >> each frame (pixmap) using such an engine, and blit it afterwards. Not > > >> really in the spirit of the mainstream accelerated graphics approach > > >> (OpenGL and Vulkan), nor how Plan 9 typically does things either. I’d > > >> rather have full AA support with draw API, and get help from the GPU > to do > > >> it, somehow. > > >> > > >> With APIs like draw, you assume you can draw when you want. For > > >> accelerated graphics, you wait for a callback to prepare a series of > draw > > >> calls, which need to be minimized in number and maximized in data: > don’t > > >> draw one primitive at a time, try to group them as much as possible. > > >> (60FPS is 16 ms per frame: you don’t have time for too many draw > calls; > > >> but the GPU is highly parallel and doesn’t mind if you throw in lots > of > > >> data with each call.) So the coding style has to change, unless the > > >> “turtle" API is used only to queue up the commands, and then batches > are > > >> generated from the queue. I.e. build a scene graph. If you take for > > >> granted that there will be a scene graph, then IMO it works quite > well to > > >> use a declarative style. What you really wanted to say was “let > there be > > >> rectangle, with these dimensions” (and other primitives: text, images, > > >> paths at least) rather than “go draw 4 lines right now". Switch to > > >> retained mode. Then it can go directly into the scene graph, > optimization > > >> of the draw calls can be done algorithmically, and you don’t spend > time > > >> redrawing anything that doesn’t need it. But everybody seems to like > > >> immediate mode better. They keep doing it on GPUs too, and those > programs > > >> always seem to take a constant few percent of CPU just to maintain a > static > > >> scene, because they keep redoing work that was already done. > > >> > > >> I will keep working on my 9p scene graph approach, and then I can > write > > >> renderers with any technology on any OS, as long as a 9p client is > > >> available (either integrated into the renderer, or by mounting the > > >> filesystem on the OS). Maybe I or someone could try ebiten for > that. At > > >> least that way it can make good use of the GPU on platforms where it’s > > >> supported. But I do fear that 9p may become a bottleneck at some > point: I > > >> just want to see how far it’s possible to go that way. > > >> > > >> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > > > <https://9fans.topicbox.com/groups/9fans> + participants > > > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > > > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > > > < > https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-M1213743d46bd247dc794bece ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T33e3d4a8f04a347f-Mc9914aba952fd0a65f996d0d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
