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