Don't high end GPUs have thousands of "cores"? Even high end CPUs don't have more than a few dozen cores to 128 or so. While each kind's cores are very different, seems to me GPU/CPU paths have diverged for good. Or we need some massive shift in programming languages + compilers. I lack imagination how. Still, the thought of the CPUs gaining the complexity of the graphics engine scares me!
-- Bakul > On Aug 22, 2021, at 12:09 PM, Paul Lalonde <paul.a.lalo...@gmail.com> wrote: > > I'm pretty sure we're still re-inventing, though it's the CPU's turn to gain > some of the complexity of the graphics engine. > > Paul > > On Sun, Aug 22, 2021, 12:05 PM Bakul Shah <ba...@iitbombay.org > <mailto:ba...@iitbombay.org>> wrote: > Thanks. Looks like Sutherland's "Wheel of Reincarnation > <https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland-design-of-display-processors.pdf>" > has not only stopped but exploded :-) Or stopped being applicable. > > -- Bakul > >> On Aug 22, 2021, at 9:23 AM, Paul Lalonde <paul.a.lalo...@gmail.com >> <mailto:paul.a.lalo...@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. >> >> Paul >> >> >> On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah <ba...@iitbombay.org >> <mailto:ba...@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.lalo...@gmail.com >>> <mailto:paul.a.lalo...@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 >>> >>> <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 <sirjofri+ml-9f...@sirjofri.de >>> <mailto:sirjofri%2bml-9f...@sirjofri.de>> wrote: >>> >>> 22.08.2021 14:10:20 Stuart Morrow <morrow.stu...@gmail.com >>> <mailto:morrow.stu...@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 >>> >>> <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Md3d5cd693c12f948ad4720bc> >>> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription >>> <https://9fans.topicbox.com/groups/9fans/subscription> >> >> >> >> -- Bakul >> > > 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/Tad29bfc223dc4fbe-M6309d0d2644e0651e74b9901> ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Me78513510ae4df2da186c73a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
