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

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

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

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

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

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

Re: [9fans] OAuth2 in factotum

Quoth Demetrius Iatrakis : > > type is text > dst is oauth > plumb to oauth > > to your plumber's rules file to create the oauth port. Ah -- right. This is in the plan9port side, and it's used to send the oauth verification request to the browser. (iirc, it's not currently used for anything on

Re: [9fans] OAuth2 in factotum

Quoth o...@eigenstate.org: > Quoth Demetrius Iatrakis : > > This is a preview of OAuth2 support in factotum, as part of this year's > > GSoC: > > https://github.com/Mitsos101/plan9front/pull/1 > > > > Installation, on 9front: > > > > git/clone https://github.com/Mitsos101/plan9front

Re: [9fans] OAuth2 in factotum

Thank you for your work. Don't forget to add type is text dst is oauth plumb to oauth to your plumber's rules file to create the oauth port. I have also added the authorization code flow to the factotum module (can be enabled by adding `flow=auth` to the key), but it requires the user to

Re: [9fans] OAuth2 in factotum

Quoth Demetrius Iatrakis : > This is a preview of OAuth2 support in factotum, as part of this year's GSoC: > https://github.com/Mitsos101/plan9front/pull/1 > > Installation, on 9front: > > git/clone https://github.com/Mitsos101/plan9front plan9front-oauth > cd plan9front-oauth > git/branch oauth

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

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 wrote: > Thanks. Looks like Sutherland's "Wheel of Reincarnation >

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

Thanks. Looks like Sutherland's "Wheel of Reincarnation " has not only stopped but exploded :-) Or stopped being applicable. -- Bakul > On Aug 22, 2021, at 9:23 AM, Paul Lalonde wrote: > > It got

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

22.08.2021 20:25:12 o...@eigenstate.org: Quoth sirjofri : 22.08.2021 18:41:06 o...@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

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

Quoth sirjofri : > > 22.08.2021 18:41:06 o...@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

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

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

Re: [9fans] git/{diff,import}: make it easier to handle manually-asembled patch emails

Quoth o...@eigenstate.org: > Oops, sent to the wrong mailing list -- sorry about the noise. > Also, as a side note, it seems like the 9fans mailing lists mangles patches -- if anyone ever sends patches, they'll need to be sent as attachments. -- 9fans:

Re: [9fans] git/{diff,import}: make it easier to handle manually-asembled patch emails

Oops, sent to the wrong mailing list -- sorry about the noise. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T403f90e3b0509704-M300dfe7499e5b62ca9db9bbf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] git/{diff,import}: make it easier to handle manually-asembled patch emails

Often, people (including myself) will write emails that can almost be applied with git/import. This changes git/diff and git/import so that things will generally work even when assembling diffs by hand: 1. git/import becomes slightly more lax: ^diff ... ^---

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

Quoth sirjofri : > 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

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

Quoth Paul Lalonde : > 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

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

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,

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

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

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

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

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

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

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

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

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

22.08.2021 14:10:20 Stuart Morrow : 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

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

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

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

On 22/08/2021, Eli Cohen 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,

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

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

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

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

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

22.08.2021 05:16:42 Eli Cohen : 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