22.08.2021 18:41:06 o...@eigenstate.org:
Quoth Paul Lalonde <paul.a.lalo...@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
