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

From: Stuart Morrow <[email-masked]>
Date: Sun, 22 Aug 2021 13:10:20 +0100

On 22/08/2021, Eli Cohen <[email-masked]> wrote:
> deep learning is another interest of mine too. hardware support is a
> big deal for that... some kind of support for GPUs would be nice.
> people have discussed that for years... hardware drivers are difficult
> and important to do correctly!

There's virtio_gpu, which I assume is less hairy and better-documented
than real hardware. I think it's graphics-purpose-only. Maybe you'd be
better-off just supporting cards that *only* do ML/NN acceleration?
There's open-source ones.

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.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M3cda662328b544acbd9fd894
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: sirjofri <[email-masked]>
Date: Sun, 22 Aug 2021 12:29:11 +0000 (UTC)

> going "some sort of GPU support would be cool to have".  That isn't

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

---

From: Paul Lalonde <[email-masked]>
Date: Sun, 22 Aug 2021 06:44:45 -0700

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

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M5f5fc3eff26e802047dbc69d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: Eli Cohen <[email-masked]>
Date: Sun, 22 Aug 2021 06:53:48 -0700

I wasn't aware of open-source cards only for ML/NN... that's interesting.

I was just poking through the # drivers... as I recalled there was
something specifically for using the FPU, but now I can't figure that
out... I'm not sure where I saw that or thought that... that was more
what I was thinking, though.

On Sun, Aug 22, 2021 at 6:46 AM Paul Lalonde <[email-masked]> 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 <[email-masked]> wrote:
>>
>>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mdcb928be475cb614573450f3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: sirjofri <[email-masked]>
Date: Sun, 22 Aug 2021 14:57:11 +0000 (UTC)

The benefit of a drawterm GPU implementation is that you can basically 
use the whole driver pipeline of the underlying host OS. Eg for the 
windows version you can just write the software that uses the GPU driver. 
All programming effort will just be writing a graphics implementation and 
a proper 9p interface. Basically just a driver bridge between 9p and 
OpenGL for example.

sirjofri

22.08.2021 15:44:45 Paul Lalonde <[email-masked]>:

> 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 
> <[email-masked][[email-masked]]> wrote:
>>
> *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-M5f5fc3eff26e802047dbc69d]

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M620f53eecae429a368d102bf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: Bakul Shah <[email-masked]>
Date: Sun, 22 Aug 2021 08:47:19 -0700

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 <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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.
> 
> On Sun, Aug 22, 2021 at 5:30 AM sirjofri <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 22.08.2021 14:10:20 Stuart Morrow <[email-masked] <mailto:[email-masked]>>:
> > Also:
> 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>
> 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-M5f5fc3eff26e802047dbc69d>

-- Bakul

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M8658a330dbb6ca9a6e216777
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: Paul Lalonde <[email-masked]>
Date: Sun, 22 Aug 2021 09:23:56 -0700

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 <[email-masked]> 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 <[email-masked]>
> wrote:
>
> *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-M8658a330dbb6ca9a6e216777>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M1a557f299e542dc652b550b8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: [email-masked]
Date: Sun, 22 Aug 2021 12:41:06 -0400

> experiment with Plan9-like interfaces to graphics hardware.

It seems like the interesting part of GPUs
is the general purpose computation. Writing
an interface for pure computation seems like
the way to go.

Hardware rendering is a restricted case of
software rendering; it seems like it would
be better to write code that could do software
rendering, and run it on the general purpose
compute engine of the GPU. The same goes for
basically everything else you may want to do
with a GPU.

It also seems like it may be both a more
useful and more long-lived tool.

Spitballing a while ago on the grid, I came
up with something that looked a bit like a
batch job interface, with a heirarchy that
looks something like this:

        /dev/compute
                new
                $func/new
                $func/$job/data
                $func/$job/result

which you could use from a script like so:

        #!/bin/rc
        # example:
        #
        # runs the neural net for finding cats,
        # which is compiled using some sort of
        # compiler backend that generates spirv,
        <[3=1] <>/dev/compute/new{
                # upload the code which can then
                # be run by the compute engine;
                # statically allocating resources
                # can simplify the driver.
                #
                # protocol would look something
                # like:
                #       "config param\n"
                #       "config param\n"
                #       "code\n"
                #       <spirv-oid bytecode>
                #       EOF
                filtdir=/dev/compute/`{sed 1q}
                echo alloc 8g
                echo code
                cat /bin/spir/catfinder

                # then launch a job, sending it
                # the arguments over the data
                # channel.
                #
                # it's up to the submitter and
                # the compute job to agreee on a
                # format; in this case, a single
                # uncompressed plan9 image is
                # written, and the result file
                # could contain a single string:
                # 'cat', 'not cat', or 'rifle'
                <>$dir/new{
                        jobdir=/dev/compute/`{sed 1q}
                        jpg -9 $i >$jobdir/data
                        cat $jobdir/result >[3]
                }
        }

Prototyping something like this as a 9p server
on unix would be interesting. So would providing
this kind of cpu interface in software.

Vmx could be extended with device passthrough
if you want to fit the entire thing on one box,
and then you may be able to find someone with
a bunch of time on their hands to write a basic
driver... maybe.

Hooking this up to devdraw would probably be
interesting for doing "hardware" rendering, though
latency may be an issue if it's not implemetned as
a local '#' device.

Anyways, this is fun to consider, but I've got
other more quotidian tools to work on before I even
think about thinking about this more :)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mc5753788883d2ed17e4acdbd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: [email-masked]
Date: Sun, 22 Aug 2021 12:45:27 -0400

Quoth sirjofri <[email-masked]>:
> Basically just a driver bridge between 9p and 
> OpenGL for example.

While that may be a neat hack, I think the way
forward is to *ignore* everything but the ability
to run arbitrary code. The alternative binds us
tightly to complex interfaces that we are unable
to control, and unwilling to implement ourselves.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M669861f673e387c2799da01b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: sirjofri <[email-masked]>
Date: Sun, 22 Aug 2021 17:29:14 +0000 (UTC)

> basically everything else you may want to do

Basically do software rendering on the GPU?

Well, it's totally possible. Even Nanite (the new system in Unreal Engine 
5) has its own rasterizer and I believe even its own base pass. Also 
Lumen does software rendering for global illumination.

But for serious 3d AAA stuff we'd have to consider: Lumen is for next-gen 
GPUs and Nanite for newer GPUs. We'll never reach their quality in 
realtime if we don't use the GPU features (built-in rasterizer, ...) to 
have enough free power for crazy software calculation.

On the other hand, getting _any_ GPU computation running on Plan 9 would 
be great, even if it's just compatible pure-CPU implementation (aka gpufs 
without a GPU).

> looks something like this:

I like that /dev/compute approach, but may I suggest putting it below 
another directory /dev/gpu/compute so we have the ability to add 
/dev/gpu/{vertex,geometry,fragment,tessellation,pixel} later?

I haven't looked at your sample script in more detail, but on the first 
glance it seems solid.

> this kind of cpu interface in software.

This is also a great idea, instead of tweaking drawterm. I don't have a 
linux machine with a GPU (I'm full 9front and only windows for work), but 
I guess if this prototype uses OpenGL (or alt) it could also work with 
software GPU emulation.

I'd really like to try something like that, but writing filesystems is 
(still, sadly) new to me and I also don't have much time, being a 
full-time game developer.

If someone else wants to try it please make development open source so we 
can provide patches, and I'm also happy to at least test things.

> latency may be an issue if it's not implemetned as

I'm not sure about the latency (I would just try it once it's done), but 
can't we use the hwdraw stub function for interfacing with this? I also 
doubt we'll draw many complex shaders for /dev/draw.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mf5ef60c88b77f937e3cd7c38
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: [email-masked]
Date: Sun, 22 Aug 2021 14:25:12 -0400

> Basically do software rendering on the GPU?

Yes. Or software neural net evaluation on the GPU.
Or software video decoding on the GPU. Or software
image transforms on the GPU. Or software signal
processing on the GPU.

If there's an interface to be selected, it needs
to be tractable to implement, *and* general purpose
enough for everything that wants to use it.

> have enough free power for crazy software calculation.

By the time any code is written, next-gen GPUs will be
previous-gen GPUs.

General compute is what any hardware you buy a few years
from now will be doing -- and it's far more intersting
in terms of what capabilities it allows.

> /dev/gpu/{vertex,geometry,fragment,tessellation,pixel} later?

I think supporting those is a cost we should not pay. It's
fundamentally solving a less general problem, and adds a
lot of complexity for the potential of a small performance
boost.

We already have zero people sinking time into the slim
interface; sinking time into a fatter interface seems
like a bad idea.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M9436d5323abdd3522e9996aa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: sirjofri <[email-masked]>
Date: Sun, 22 Aug 2021 18:50:33 +0000 (UTC)

> interface; sinking time into a fatter interface seems

Gotcha.

Maybe I'll find some time to implement some kind of gpufs or /dev/gpu (if 
it's general purpose I'd suggest renaming compute to gpu since "compute" 
could be anything. The computer does compute, wow.).

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M3c0e76a0b437dd9071c6f579
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: Bakul Shah <[email-masked]>
Date: Sun, 22 Aug 2021 12:04:00 -0700

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> 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-M1a557f299e542dc652b550b8>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M69dfd52c6b6d85727b06d9dc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: Paul Lalonde <[email-masked]>
Date: Sun, 22 Aug 2021 12:09:03 -0700

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 <[email-masked]> 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
>
> <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M69dfd52c6b6d85727b06d9dc>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M6309d0d2644e0651e74b9901
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: "Philip Silva via 9fans" <[email-masked]>
Date: Sun, 22 Aug 2021 21:10:30 +0000

Vulkan (at least its promises) looks interesting though. As far as I understand it's more like a Meta API, really low-level and it claims to be very portable. But as mentioned before, the Hello Worlds are really long, apparently it's rather >1000 lines instead of "just" >100 for OpenGL.

On the other hand for driver development it might be less effort but seems to have its own pitfalls. (This is the only article I found about the driver aspect of it: https://lwn.net/Articles/702021/)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Mc570eb4778bbb92d838c9b3c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

---

From: Bakul Shah <[email-masked]>
Date: Sun, 22 Aug 2021 21:13:53 -0700

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 22, 2021, at 9:23 AM, Paul Lalonde <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> 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

---

From: sirjofri <[email-masked]>
Date: Mon, 23 Aug 2021 05:23:14 +0000 (UTC)

Good morning,

GPUs are SIMD processors. The hundreds of cores are great for highly 
parallel calculation.

In GLSL/HLSL I can write a program which is calculated for a very small 
set of pixels (usually 2x2 or 1x1). So if you have  a resolution of 10x10 
the program is basically run 5x5=25 or 10x10=100 times in parallel. Boost 
the resolution to more real values like 1080p you see how the many cores 
benefit the whole calculation.

This high parallelization can only really happen because most stuff is 
independent. For example, when raytracing each ray is (almost) 
independent of other rays.

Still, the 2x2 matrix is often calculated dependently because for 
texturing (and mip mapping) you need the "distance" between two pixels in 
a fragment shader. This is why (for texturing) you may end up having 
slower programs and some waiting time between some threads, because 
sometimes you need the value of the neighbor thread and have to wait 
until it's calculated.

Well, these are very language-specific details that are important for 
graphics, but apply similarly to other use cases. I can imagine that for 
neural networks you can just write the code for one node nad execute it 
500 times for 500 nodes in parallel. Imagine having this beast on the CPU 
with just 4 cores...

I hope this helps you understand how GPU cores ("shaders") work.

Vulkan would indeed be interesting. Since we are only interested in the 
compute part it might even make our programs really small, the "hello 
world" part of drawing triangles would be the "client" side (writing a 
rasterizer, raymarcher, tracer, whatever). It could still be a lot lines 
of code, but maybe we still benefit from the 10% speedup.

I still have to understand how all this "shader compilation" stuff works. 
In webgl it's like, "here's my code, make a shader from it, then I tell 
you it's a fragment shader". Shader compilation happens automatically. In 
UE shader compilation takes a long time, and I believe also in blender 
shaders are stored in a precompiled binaries.

sirjofri

23.08.2021 06:13:53 Bakul Shah <[email-masked]>:

> 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
>
>> Thanks. Looks like Sutherland's "Wheel of 
>> Reincarnation[https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland-design-of-display-processors.pdf]" 
>> 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. 
>> 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
>>
>>
>>> 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?
>>>
>>> …
>>>
>>>
>>>
>>> -- Bakul
>>>
>
>
> Permalink[https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Me78513510ae4df2da186c73a]

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M40ea45711a1551fd53807b84
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription