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

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

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