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-M604519740dfb2b0d95fa42a8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
