It got complicated because there's no stable interface or ISA. The hardware evolved from fixed-function to programmable in a commercial environment where the only meaningful measure was raw performance per dollar at many price points. Every year the hardware spins and becomes more performant, usually faster than Moore's law. With 3D APIs hiding the hardware details there is no pressure to make the hardware interface uniform, pretty, or neat. And with the need for performance there are dozens of fixed function units that effectively need their own sub-drivers while coordinating at high performance with the other units. The system diagrams for GPUs look complex, but they are radical simplifications of what's really on the inside. Intel really pioneered the open driver stacks, but performance generally wasn't there. That might be changing now, but I don't know if their recently announced discrete product line will be driver-compatible. Paul On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah wrote: > The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the > "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+ > lines of source code. drm/amd over 2M lines of code. Intel's i915 seems to > be about 1/10th the amd size. AIUI, this is linux GPU driver code, more or > less unchanged (FreeBSD has shim code to use it). How did the interface to > an SIMD processor get so complicated? > > On Aug 22, 2021, at 6:44 AM, Paul Lalonde > wrote: > > I'd love to see GPU support for Plan9. This discussion falls right into > my professional capacity. I'll say that people generally *grossly* > underestimate the complexity of a modern GPU and of its supporting software > stack. The GPU driver is effectively a second operating system with shared > memory and DMA interfaces to the host. Even bringing up a modern GPU for > just compute tasks is a very large endeavour. > > That being said, if you want real hardware support, the best place to > start is currently AMD's open-source stack. Ignoring the Vulkan bit, > understanding their platform abstraction layer (PAL) and shader ISA ( > https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf) > is the base. The lower hardware levels are reasonably well-described in > linux's libdrm and its AMD support in amdgpu. > > Opinions on how to bring this to Plan9? I don't really have any - it's a > huge pile of work with minimal benefit. If you're looking for lightweight > graphics, WebGL is a doable path, and almost certainly the right way to > experiment with Plan9-like interfaces to graphics hardware. > > Paul > > > > On Sun, Aug 22, 2021 at 5:30 AM sirjofri > wrote: > >> >> 22.08.2021 14:10:20 Stuart Morrow : >> > Also: >> >> people have discussed that for years >> > >> > They have? I mean I might have seen occasionally someone vaguely >> > going "some sort of GPU support would be cool to have". That isn't >> > discussion. >> >> I've even heard of someone actually making GPU stuff work on plan 9. I've >> only heard from their partner, who made a cute glenda thing on a piece of >> cloth. I chatted with her a little and told her she should encourage her >> partner for some discussion about this in our channels. It looked like >> it's some academic work, but I don't know any details about it. >> >> Worst case, someone already has a proper and good GPU implementation for >> Plan 9 and nobody knows about it. >> >> sirjofri >> >> Btw if the said person reads this: it would be nice to learn some >> details. > > > > -- Bakul > > *9fans * / 9fans / see discussions > + participants > + delivery options > Permalink > > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M1a557f299e542dc652b550b8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription