9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Drawterm GPU (was: Software philosophy)
@ 2021-08-22 12:10 Stuart Morrow
  2021-08-22 12:29 ` sirjofri
  0 siblings, 1 reply; 27+ messages in thread
From: Stuart Morrow @ 2021-08-22 12:10 UTC (permalink / raw)
  To: 9fans

On 22/08/2021, Eli Cohen <echoline@gmail.com> 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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 12:10 [9fans] Drawterm GPU (was: Software philosophy) Stuart Morrow
@ 2021-08-22 12:29 ` sirjofri
  2021-08-22 13:44   ` Paul Lalonde
  0 siblings, 1 reply; 27+ messages in thread
From: sirjofri @ 2021-08-22 12:29 UTC (permalink / raw)
  To: 9fans


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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 12:29 ` sirjofri
@ 2021-08-22 13:44   ` Paul Lalonde
  2021-08-22 13:53     ` Eli Cohen
                       ` (3 more replies)
  0 siblings, 4 replies; 27+ messages in thread
From: Paul Lalonde @ 2021-08-22 13:44 UTC (permalink / raw)
  To: 9fans

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

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 <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-M5f5fc3eff26e802047dbc69d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 13:44   ` Paul Lalonde
@ 2021-08-22 13:53     ` Eli Cohen
  2021-09-01  0:29       ` kokamoto
  2021-08-22 14:57     ` sirjofri
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 27+ messages in thread
From: Eli Cohen @ 2021-08-22 13:53 UTC (permalink / raw)
  To: 9fans

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 <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.
>
> Paul
>
>
>
> On 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 / 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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 13:44   ` Paul Lalonde
  2021-08-22 13:53     ` Eli Cohen
@ 2021-08-22 14:57     ` sirjofri
  2021-08-22 16:45       ` ori
  2021-08-22 15:47     ` Bakul Shah
  2021-08-22 16:41     ` ori
  3 siblings, 1 reply; 27+ messages in thread
From: sirjofri @ 2021-08-22 14:57 UTC (permalink / raw)
  To: 9fans

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 <paul.a.lalonde@gmail.com>:

> 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 
> <sirjofri+ml-9fans@sirjofri.de[sirjofri%2Bml-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[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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 13:44   ` Paul Lalonde
  2021-08-22 13:53     ` Eli Cohen
  2021-08-22 14:57     ` sirjofri
@ 2021-08-22 15:47     ` Bakul Shah
  2021-08-22 16:23       ` Paul Lalonde
  2021-08-22 16:41     ` ori
  3 siblings, 1 reply; 27+ messages in thread
From: Bakul Shah @ 2021-08-22 15:47 UTC (permalink / raw)
  To: 9fans

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

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>
> 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

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 15:47     ` Bakul Shah
@ 2021-08-22 16:23       ` Paul Lalonde
  2021-08-22 19:04         ` Bakul Shah
  0 siblings, 1 reply; 27+ messages in thread
From: Paul Lalonde @ 2021-08-22 16:23 UTC (permalink / raw)
  To: 9fans

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

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> 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.
>
> Paul
>
>
>
> On 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.
>
>
>
> -- 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-M8658a330dbb6ca9a6e216777>
>

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

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 13:44   ` Paul Lalonde
                       ` (2 preceding siblings ...)
  2021-08-22 15:47     ` Bakul Shah
@ 2021-08-22 16:41     ` ori
  2021-08-22 17:29       ` sirjofri
  3 siblings, 1 reply; 27+ messages in thread
From: ori @ 2021-08-22 16:41 UTC (permalink / raw)
  To: 9fans

Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> 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.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 14:57     ` sirjofri
@ 2021-08-22 16:45       ` ori
  0 siblings, 0 replies; 27+ messages in thread
From: ori @ 2021-08-22 16:45 UTC (permalink / raw)
  To: 9fans

Quoth sirjofri <sirjofri+ml-9fans@sirjofri.de>:
> 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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 16:41     ` ori
@ 2021-08-22 17:29       ` sirjofri
  2021-08-22 18:25         ` ori
  0 siblings, 1 reply; 27+ messages in thread
From: sirjofri @ 2021-08-22 17:29 UTC (permalink / raw)
  To: 9fans


22.08.2021 18:41:06 ori@eigenstate.org:

> Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
>> 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.
>
> 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.

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).

> 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

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.

> Prototyping something like this as a 9p server
> on unix would be interesting. So would providing
> 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.

> 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.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 17:29       ` sirjofri
@ 2021-08-22 18:25         ` ori
  2021-08-22 18:50           ` sirjofri
  2021-08-22 21:10           ` Philip Silva via 9fans
  0 siblings, 2 replies; 27+ messages in thread
From: ori @ 2021-08-22 18:25 UTC (permalink / raw)
  To: 9fans

Quoth sirjofri <sirjofri+ml-9fans@sirjofri.de>:
> 
> 22.08.2021 18:41:06 ori@eigenstate.org:
> 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.

> 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.

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.

> 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 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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 18:25         ` ori
@ 2021-08-22 18:50           ` sirjofri
  2021-09-24  1:50             ` Frank D. Engel, Jr.
  2021-08-22 21:10           ` Philip Silva via 9fans
  1 sibling, 1 reply; 27+ messages in thread
From: sirjofri @ 2021-08-22 18:50 UTC (permalink / raw)
  To: 9fans


22.08.2021 20:25:12 ori@eigenstate.org:

> Quoth sirjofri <sirjofri+ml-9fans@sirjofri.de>:
>>
>> 22.08.2021 18:41:06 ori@eigenstate.org:
>> 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.
>
>> 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.
>
> 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.
>
>> 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 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.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 16:23       ` Paul Lalonde
@ 2021-08-22 19:04         ` Bakul Shah
  2021-08-22 19:09           ` Paul Lalonde
  0 siblings, 1 reply; 27+ messages in thread
From: Bakul Shah @ 2021-08-22 19:04 UTC (permalink / raw)
  To: 9fans

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

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> 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-M1a557f299e542dc652b550b8>

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

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 19:04         ` Bakul Shah
@ 2021-08-22 19:09           ` Paul Lalonde
  2021-08-23  4:13             ` Bakul Shah
  0 siblings, 1 reply; 27+ messages in thread
From: Paul Lalonde @ 2021-08-22 19:09 UTC (permalink / raw)
  To: 9fans

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

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> 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>
> 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> 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.
>>
>> Paul
>>
>>
>>
>> On 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.
>>
>>
>>
>> -- 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-M69dfd52c6b6d85727b06d9dc>
>

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

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 18:25         ` ori
  2021-08-22 18:50           ` sirjofri
@ 2021-08-22 21:10           ` Philip Silva via 9fans
  1 sibling, 0 replies; 27+ messages in thread
From: Philip Silva via 9fans @ 2021-08-22 21:10 UTC (permalink / raw)
  To: 9fans

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/)

> > 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.
>
> 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.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 19:09           ` Paul Lalonde
@ 2021-08-23  4:13             ` Bakul Shah
  2021-08-23  5:23               ` sirjofri
  0 siblings, 1 reply; 27+ messages in thread
From: Bakul Shah @ 2021-08-23  4:13 UTC (permalink / raw)
  To: 9fans

[-- 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 --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-23  4:13             ` Bakul Shah
@ 2021-08-23  5:23               ` sirjofri
  0 siblings, 0 replies; 27+ messages in thread
From: sirjofri @ 2021-08-23  5:23 UTC (permalink / raw)
  To: 9fans

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 <bakul@iitbombay.org>:

> 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> 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> 
>> 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> 
>> 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?
>>>
>>> …
>>>
>>>
>>>
>>> -- 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-Me78513510ae4df2da186c73a]

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 13:53     ` Eli Cohen
@ 2021-09-01  0:29       ` kokamoto
  2021-09-01  7:35         ` sirjofri
  0 siblings, 1 reply; 27+ messages in thread
From: kokamoto @ 2021-09-01  0:29 UTC (permalink / raw)
  To: 9fans


By the way, I made your drawterm-android on my ubuntu-20.04.2 machine.
My android is version 11, and made by Sony (SO-41B).
I now have drawterm.apk file on my home directory, like src/drawterm-android/drawterm.apk
(size=777151).

How I can install this to my android?
I'm a novise user of android...

Kenji


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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-09-01  0:29       ` kokamoto
@ 2021-09-01  7:35         ` sirjofri
  2021-09-02  5:01           ` kokamoto
  0 siblings, 1 reply; 27+ messages in thread
From: sirjofri @ 2021-09-01  7:35 UTC (permalink / raw)
  To: 9fans


01.09.2021 02:29:42 kokamoto@hera.eonet.ne.jp:
> By the way, I made your drawterm-android on my ubuntu-20.04.2 machine.
> My android is version 11, and made by Sony (SO-41B).
> I now have drawterm.apk file on my home directory, like 
> src/drawterm-android/drawterm.apk
> (size=777151).
>
> How I can install this to my android?
> I'm a novise user of android...

You have to copy the apk file to your android system and install there. 
If you haven't already stuff like f-droid installed you'll have to enable 
unknown sources in android. This guide can help: 
https://www.lifewire.com/install-apk-on-android-4177185


(Note, there are different solutions for different versions, and you can 
install apps using the adb, the usb android debugger, but I don't assume 
you want to use it.)

If you need other guides look for "install apk android (version)" or 
similar.

Btw there's a small known bug: when opening a connection the first time 
the app crashes silently. Opening it a second time it works without 
issues.

And there's the mouse offset bug. In my version it's almost the same 
offset across the whole screen (y-axis), in the original the offset is 
different.

Good luck

sirjofri

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-09-01  7:35         ` sirjofri
@ 2021-09-02  5:01           ` kokamoto
  2021-09-02  5:21             ` Eli Cohen
  0 siblings, 1 reply; 27+ messages in thread
From: kokamoto @ 2021-09-02  5:01 UTC (permalink / raw)
  To: 9fans

> This guide can help: 
> https://www.lifewire.com/install-apk-on-android-4177185

My phone is version 11, and made for Japanese (all the messages are Japanese),
which makes me difficult to follow it.   However, I'll do it soon...


> And there's the mouse offset bug. In my version it's almost the same 
> offset across the whole screen (y-axis), in the original the offset is 
> different.

I downloaded your cersion from https://github.com/sirjofri/drawterm-android.git,
and made it, somewhat different size of 777790.

Thank you very much.

Kenji


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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-09-02  5:01           ` kokamoto
@ 2021-09-02  5:21             ` Eli Cohen
  2021-09-03 23:06               ` kokamoto
  0 siblings, 1 reply; 27+ messages in thread
From: Eli Cohen @ 2021-09-02  5:21 UTC (permalink / raw)
  To: 9fans

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

hey Kenji,

when I was putting the apk on my phone I used the "adb" tool. I don't
exactly remember the process... the phone has to be paired with the
computer running adb either over a USB cable or over wifi, then the apk can
be installed with adb. I do recall it being a bit difficult to get it
working right consistently...

- Eli

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

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-09-02  5:21             ` Eli Cohen
@ 2021-09-03 23:06               ` kokamoto
  0 siblings, 0 replies; 27+ messages in thread
From: kokamoto @ 2021-09-03 23:06 UTC (permalink / raw)
  To: 9fans

I put drawterm.apk onto my android device (SO-41B) successfully,
then, I tap that file on my device.
It does something for a while, I see graphic progress bar, and then, replied it did not
installed., which means failed to install.

By the way, android program should compile all for arm64, arm, x86 and x86_64?
I compiled it only for arm64, because my device has arm-A53 cpu.

Kenji
 
> hey Kenji,
> 
> when I was putting the apk on my phone I used the "adb" tool. I don't
> exactly remember the process... the phone has to be paired with the
> computer running adb either over a USB cable or over wifi, then the apk can
> be installed with adb. I do recall it being a bit difficult to get it
> working right consistently...
> 
> - Eli

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 18:50           ` sirjofri
@ 2021-09-24  1:50             ` Frank D. Engel, Jr.
  0 siblings, 0 replies; 27+ messages in thread
From: Frank D. Engel, Jr. @ 2021-09-24  1:50 UTC (permalink / raw)
  To: 9fans

Maybe /dev/gpgpu (general-purpose GPU) would be more to the point?


On 8/22/21 2:50 PM, sirjofri wrote:
>
> 22.08.2021 20:25:12 ori@eigenstate.org:
>
>> Quoth sirjofri <sirjofri+ml-9fans@sirjofri.de>:
>>>
>>> 22.08.2021 18:41:06 ori@eigenstate.org:
>>> 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.
>>
>>> 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.
>>
>> 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.
>>
>>> 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 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.
> 
> 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-Mb1c40d6c9d3bca972decad36
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 11:49         ` sirjofri
@ 2021-08-22 12:24           ` Chris McGee
  0 siblings, 0 replies; 27+ messages in thread
From: Chris McGee @ 2021-08-22 12:24 UTC (permalink / raw)
  To: 9fans

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

I was thinking that another way to get access to GPU across other OSes,
chipsets, etc. might be WebGL. I was going to try with one of the web
frontend drawterms out there (maybe aiju's) would be a reasonable starting
point to expose a gpufs and model how it would work such that someday it
could be implemented directly with Plan 9 drivers in the Plan 9 way.

On Sun, Aug 22, 2021 at 7:50 AM sirjofri <sirjofri+ml-9fans@sirjofri.de>
wrote:

> I should mention I thought about the layout of a GPUfs some time ago. I
> just lack lots of knowledge about this, the gist was to write shader
> (code or compiled?) into some files, also write image data and mesh data
> to other files, abd reading results from other files. But as I said, I
> lack lots of knowledge about how GPUs work and never wrote any OpenGL
> code myself, only shader code. It always seemed like it's hundreds of
> hundreds of lines of code to draw a triangle (which is the basic hello
> world program).
>
> sirjofri
>
> 22.08.2021 12:04:41 Frank D. Engel, Jr. <fde101@fjrhome.net>:
>
> > While not necessarily unwelcome as a possibility, I don't think
> > GPU-based drawing/gaming is as relevant to this discussion (or as
> > important of a goal for Plan 9 / 9front) as is GPU compute (GPGPU).
> >
> > The ability to leverage GPU resources across CPU servers for
> > computation purposes would be of great benefit to the platform, and
> > working out a driver interface by starting the process remotely via
> > drawterm seems like a sensible step in that direction.
> >
> > On 8/22/21 3:07 AM, sirjofri wrote:
> >>
> >> 22.08.2021 05:16:42 Eli Cohen <echoline@gmail.com>:
> >>> 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!
> >>>
> >>> I always really liked the "XCPU" and drawterm type ideas of using
> >>> other OSes for their existing strengths along with Plan 9. maybe
> >>> drawterm could have a GPU device driver or something... that being
> >>> said I have sometimes found it ends up surprisingly easier doing it
> >>> all on Plan 9...
> >> That's also something I thought about a few times already: drawterm
> >> with GPU support. The only issue I see is, for realtime applications
> >> like games the draw times would be network bound and thus pretty slow.
> >> It would work for heavy GPU applications where almost no draw calls
> >> will exist (no textures, very low poly meshes, ...), but for heavier
> >> stuff we'd need to address that.
> >> That's the benefit of a native driver: you could calculate the server
> >> side (heavy CPU calculations) on a cpu server, the client/frontend
> >> side (including draw calls) on a terminal and the pure graphics on the
> >> GPU.
> >> I'd still give the drawterm GPU a shot. Maybe I can set drawterm up
> >> for compilation on my work PC (two GTX 1080Ti) and try figuring out
> >> how to do all that stuff. However, I've never done graphics
> >> applications on windows or somewhere else that uses OpenGL or DirectX
> >> (I'd try OpenGL because portability), only written shaders so far.
> >> I'll surely need some time (which is always rare as a game developer).
> >> Btw I don't know the exact specifications for GPU usage for neural
> >> networks. I assume it's all compute shaders? Maybe it's even a kinda
> >> blackbox, put stuff in (draw call), read things out. I assume this can
> >> work perfectly fine for draw times, depending on the data.
> >> sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T65ec64adb5137874-M2811fbdfd8c6710bf58ff059
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22 10:04       ` Frank D. Engel, Jr.
@ 2021-08-22 11:49         ` sirjofri
  2021-08-22 12:24           ` Chris McGee
  0 siblings, 1 reply; 27+ messages in thread
From: sirjofri @ 2021-08-22 11:49 UTC (permalink / raw)
  To: 9fans

I should mention I thought about the layout of a GPUfs some time ago. I 
just lack lots of knowledge about this, the gist was to write shader 
(code or compiled?) into some files, also write image data and mesh data 
to other files, abd reading results from other files. But as I said, I 
lack lots of knowledge about how GPUs work and never wrote any OpenGL 
code myself, only shader code. It always seemed like it's hundreds of 
hundreds of lines of code to draw a triangle (which is the basic hello 
world program).

sirjofri

22.08.2021 12:04:41 Frank D. Engel, Jr. <fde101@fjrhome.net>:

> While not necessarily unwelcome as a possibility, I don't think 
> GPU-based drawing/gaming is as relevant to this discussion (or as 
> important of a goal for Plan 9 / 9front) as is GPU compute (GPGPU).
>
> The ability to leverage GPU resources across CPU servers for 
> computation purposes would be of great benefit to the platform, and 
> working out a driver interface by starting the process remotely via 
> drawterm seems like a sensible step in that direction.
>
> On 8/22/21 3:07 AM, sirjofri wrote:
>>
>> 22.08.2021 05:16:42 Eli Cohen <echoline@gmail.com>:
>>> 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!
>>>
>>> I always really liked the "XCPU" and drawterm type ideas of using
>>> other OSes for their existing strengths along with Plan 9. maybe
>>> drawterm could have a GPU device driver or something... that being
>>> said I have sometimes found it ends up surprisingly easier doing it
>>> all on Plan 9...
>> That's also something I thought about a few times already: drawterm
>> with GPU support. The only issue I see is, for realtime applications
>> like games the draw times would be network bound and thus pretty slow.
>> It would work for heavy GPU applications where almost no draw calls
>> will exist (no textures, very low poly meshes, ...), but for heavier
>> stuff we'd need to address that.
>> That's the benefit of a native driver: you could calculate the server
>> side (heavy CPU calculations) on a cpu server, the client/frontend
>> side (including draw calls) on a terminal and the pure graphics on the
>> GPU.
>> I'd still give the drawterm GPU a shot. Maybe I can set drawterm up
>> for compilation on my work PC (two GTX 1080Ti) and try figuring out
>> how to do all that stuff. However, I've never done graphics
>> applications on windows or somewhere else that uses OpenGL or DirectX
>> (I'd try OpenGL because portability), only written shaders so far.
>> I'll surely need some time (which is always rare as a game developer).
>> Btw I don't know the exact specifications for GPU usage for neural
>> networks. I assume it's all compute shaders? Maybe it's even a kinda
>> blackbox, put stuff in (draw call), read things out. I assume this can
>> work perfectly fine for draw times, depending on the data.
>> sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T65ec64adb5137874-M5c847fafe65a91d8e47e9b63
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22  7:07     ` [9fans] Drawterm GPU (was: Software philosophy) sirjofri
@ 2021-08-22 10:04       ` Frank D. Engel, Jr.
  2021-08-22 11:49         ` sirjofri
  0 siblings, 1 reply; 27+ messages in thread
From: Frank D. Engel, Jr. @ 2021-08-22 10:04 UTC (permalink / raw)
  To: 9fans

While not necessarily unwelcome as a possibility, I don't think 
GPU-based drawing/gaming is as relevant to this discussion (or as 
important of a goal for Plan 9 / 9front) as is GPU compute (GPGPU).

The ability to leverage GPU resources across CPU servers for computation 
purposes would be of great benefit to the platform, and working out a 
driver interface by starting the process remotely via drawterm seems 
like a sensible step in that direction.

On 8/22/21 3:07 AM, sirjofri wrote:
>
> 22.08.2021 05:16:42 Eli Cohen <echoline@gmail.com>:
>> 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!
>>
>> I always really liked the "XCPU" and drawterm type ideas of using
>> other OSes for their existing strengths along with Plan 9. maybe
>> drawterm could have a GPU device driver or something... that being
>> said I have sometimes found it ends up surprisingly easier doing it
>> all on Plan 9...
> 
> That's also something I thought about a few times already: drawterm
> with GPU support. The only issue I see is, for realtime applications
> like games the draw times would be network bound and thus pretty slow.
> It would work for heavy GPU applications where almost no draw calls
> will exist (no textures, very low poly meshes, ...), but for heavier
> stuff we'd need to address that.
> 
> That's the benefit of a native driver: you could calculate the server
> side (heavy CPU calculations) on a cpu server, the client/frontend
> side (including draw calls) on a terminal and the pure graphics on the
> GPU.
> 
> I'd still give the drawterm GPU a shot. Maybe I can set drawterm up
> for compilation on my work PC (two GTX 1080Ti) and try figuring out
> how to do all that stuff. However, I've never done graphics
> applications on windows or somewhere else that uses OpenGL or DirectX
> (I'd try OpenGL because portability), only written shaders so far.
> I'll surely need some time (which is always rare as a game developer).
> 
> Btw I don't know the exact specifications for GPU usage for neural
> networks. I assume it's all compute shaders? Maybe it's even a kinda
> blackbox, put stuff in (draw call), read things out. I assume this can
> work perfectly fine for draw times, depending on the data.
> 
> sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T65ec64adb5137874-Ma12c6e769699f5c3b561fbf2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [9fans] Drawterm GPU (was: Software philosophy)
  2021-08-22  3:16   ` Eli Cohen
@ 2021-08-22  7:07     ` sirjofri
  2021-08-22 10:04       ` Frank D. Engel, Jr.
  0 siblings, 1 reply; 27+ messages in thread
From: sirjofri @ 2021-08-22  7:07 UTC (permalink / raw)
  To: 9fans


22.08.2021 05:16:42 Eli Cohen <echoline@gmail.com>:
> 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!
>
> I always really liked the "XCPU" and drawterm type ideas of using
> other OSes for their existing strengths along with Plan 9. maybe
> drawterm could have a GPU device driver or something... that being
> said I have sometimes found it ends up surprisingly easier doing it
> all on Plan 9...

That's also something I thought about a few times already: drawterm with 
GPU support. The only issue I see is, for realtime applications like 
games the draw times would be network bound and thus pretty slow. It 
would work for heavy GPU applications where almost no draw calls will 
exist (no textures, very low poly meshes, ...), but for heavier stuff 
we'd need to address that.

That's the benefit of a native driver: you could calculate the server 
side (heavy CPU calculations) on a cpu server, the client/frontend side 
(including draw calls) on a terminal and the pure graphics on the GPU.

I'd still give the drawterm GPU a shot. Maybe I can set drawterm up for 
compilation on my work PC (two GTX 1080Ti) and try figuring out how to do 
all that stuff. However, I've never done graphics applications on windows 
or somewhere else that uses OpenGL or DirectX (I'd try OpenGL because 
portability), only written shaders so far. I'll surely need some time 
(which is always rare as a game developer).

Btw I don't know the exact specifications for GPU usage for neural 
networks. I assume it's all compute shaders? Maybe it's even a kinda 
blackbox, put stuff in (draw call), read things out. I assume this can 
work perfectly fine for draw times, depending on the data.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T65ec64adb5137874-Mf41fbd4cbe7a7366feb7901a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2021-09-24  1:51 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-22 12:10 [9fans] Drawterm GPU (was: Software philosophy) Stuart Morrow
2021-08-22 12:29 ` sirjofri
2021-08-22 13:44   ` Paul Lalonde
2021-08-22 13:53     ` Eli Cohen
2021-09-01  0:29       ` kokamoto
2021-09-01  7:35         ` sirjofri
2021-09-02  5:01           ` kokamoto
2021-09-02  5:21             ` Eli Cohen
2021-09-03 23:06               ` kokamoto
2021-08-22 14:57     ` sirjofri
2021-08-22 16:45       ` ori
2021-08-22 15:47     ` Bakul Shah
2021-08-22 16:23       ` Paul Lalonde
2021-08-22 19:04         ` Bakul Shah
2021-08-22 19:09           ` Paul Lalonde
2021-08-23  4:13             ` Bakul Shah
2021-08-23  5:23               ` sirjofri
2021-08-22 16:41     ` ori
2021-08-22 17:29       ` sirjofri
2021-08-22 18:25         ` ori
2021-08-22 18:50           ` sirjofri
2021-09-24  1:50             ` Frank D. Engel, Jr.
2021-08-22 21:10           ` Philip Silva via 9fans
  -- strict thread matches above, loose matches on Subject: below --
2021-08-18 22:00 [9fans] Software philosophy Eli Cohen
2021-08-22  2:46 ` kokamoto
2021-08-22  3:16   ` Eli Cohen
2021-08-22  7:07     ` [9fans] Drawterm GPU (was: Software philosophy) sirjofri
2021-08-22 10:04       ` Frank D. Engel, Jr.
2021-08-22 11:49         ` sirjofri
2021-08-22 12:24           ` Chris McGee

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).