Thanks. Looks like Sutherland's "Wheel of Reincarnation" has not only stopped but exploded :-) Or stopped being applicable.-- BakulOn Aug 22, 2021, at 9:23 AM, Paul Lalonde <paul.a.lalonde@gmail.com> wrote: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.PaulOn Sun, Aug 22, 2021 at 8:48 AM Bakul Shah <bakul@iitbombay.org> 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 <paul.a.lalonde@gmail.com> 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.PaulOn Sun, Aug 22, 2021 at 5:30 AM sirjofri <sirjofri+ml-9fans@sirjofri.de> wrote:
22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com>:
> 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.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c12f948ad4720bc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription-- Bakul