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

[Chris McGee <newton688@gmail.com>]

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