Re: [9fans] Drawterm GPU (was: Software philosophy)

[Bakul Shah <bakul@iitbombay.org>]

[-- Attachment #1: Type: text/plain, Size: 6071 bytes --]

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.lalonde@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 <bakul@iitbombay.org <mailto:bakul@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.lalonde@gmail.com <mailto: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.
>> 
>> Paul
>> 
>> 
>> On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah <bakul@iitbombay.org <mailto: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 <mailto: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 <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-9fans@sirjofri.de <mailto:sirjofri%2Bml-9fans@sirjofri.de>> wrote:
>>> 
>>> 22.08.2021 14:10:20 Stuart Morrow <morrow.stuart@gmail.com <mailto: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 <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

[-- Attachment #2: Type: text/html, Size: 9424 bytes --]