| 3 Jul 2020 |
 Walther | but: correct me if i'm wrong, wgpu compute stuff requires you to write your logic in a shader language instead of rust? | 19:33:29 |
 kvark | Walther: wgpu currently works with SPIR-V, it doesn't care how you are generating it. In the future, it will work with WGSL | 19:36:03 |
| kvark | so yeah, generally, you aren't writing the shaders in Rust, unless trying https://github.com/MaikKlein/rlsl which is sorta abandoned AFAIK | 19:36:34 |
 cwfitzgerald | tbh I wouldn't want to be writing shaders in rust, that sounds kinda aweful actually | 19:37:40 |
| cwfitzgerald | maybe something rust inspired, but not rust itself | 19:37:48 |
| Walther | oh for sure perhaps for graphics it wouldn't make sense to write shaders in rust itself | 19:38:54 |
| Walther | but i was thinking strictly in terms of compute - i've been writing some compute stuff in rust, and would like to keep it in rust because rust is fun and great, and would love to try and get it running on a gpu instead | 19:40:39 |
| Walther | and yeah i found rlsl as linked, as well as emu-core, both seem interesting and quite experimental | 19:41:07 |
| Walther | one random thought i also had was that there's already great tooling for turning rust into webassembly, and wasm could maybe be an easier target to port - wonder if there could be something like wasm to spirv compute some day, if that would end up being easier than rust itself? | 19:42:17 |
| Walther | in more abstract terms: rust has great support for massively parallel compute, including making sure you handle your memory correctly. in theory, that could make for a great match for gpus, right? and with helpers like rayon and others, splitting up that compute shouldn't be too difficult even across a ton of cores / compute units | 19:44:07 |
| kvark | there is certainly a lot of potential there | 19:44:39 |
| cwfitzgerald | (keep in mind if you're used to something like CUDA, compute shaders are significantly more restrictive than it is) | 19:46:25 |
| Walther | and there's a weird gap currently in that if you want to do something on a gpu, you kinda have to learn and use the specific tools and languages that exist for those gpus, usually shader languages (spirv, glsl, etc) whereas on the cpu for decades now you've been able to use a ton of different languages even for the "business logic" of your app itself | 19:46:44 |
| Walther | not used to CUDA, my previous graphics experience is in writing GLSL shaders, and while it was useful for the purpose it wasn't exactly 100% enjoyable in terms of tooling | 19:47:47 |
| Walther | and right now i have some rust code i'd love to have "gpu-accelerated" and the idealistic naive optimist in me is thinking "wouldn't it be great if there was an abstraction / compiler / tooling for running your rust on gpu" | 19:48:25 |
| Walther | of course for getting things performant (or even possible) could require you to make sure you structure your code in certain ways | 19:48:59 |
| cwfitzgerald | I've always been a bit skeptical about any kind of "automated" conversion to gpu acceleration | 19:51:39 |
| cwfitzgerald | there are a lot of factors, even in wgpu, that make gpu acceleration very close to useless for a lot of jobs | 19:52:32 |
| cwfitzgerald | https://github.com/cwfitzgerald/wgpu-heterogeneous-compute-benchmark was my first real attempt to benchmark the overhead of sending a job to the gpu and getting the result back | 19:54:28 |
| cwfitzgerald | and the results were not pretty if you have a discrete gpu | 19:54:47 |
| cwfitzgerald | https://cwfitz.com/5k5ERM.png for things that are memory bandwidth bound, it is never worth it to port to the gpu (on discrete) | 19:56:11 |
| cwfitzgerald | * https://cwfitz.com/5k5ERM.png for things that are memory bandwidth bound, it is never worth it to port to the gpu (on discrete) | 19:56:21 |
| cwfitzgerald | and even then there is a 2ms overhead to even getting the result back at all | 19:56:44 |
 m4b | What do you think of work like taichi? https://github.com/taichi-dev/taichi | 19:57:35 |
| m4b | Their original paper on it was fascinating. I wish the codebase was more accessible. It’s pretty annoying to build and get running tho. C++ and python probably my least favorite combo ever | 19:58:26 |
| cwfitzgerald | honestly haven't heard of it | 19:59:19 |
| cwfitzgerald | looks pretty similar to cuda in concept | 20:00:48 |
| m4b | It’s a little different. It’s more about data structures and auto data parallel compilation, sort of what was talked about above: this is the paper that’s quite good: http://taichi.graphics/wp-content/uploads/2019/09/taichi_lang.pdf | 20:02:36 |
| cwfitzgerald | I'll take a look at it in a bit | 20:02:58 |
| Walther | the more down-to-earth specific practical example is that i've been writing a raytracer in rust, based on the raytracing.github.io tutorial. It would be fun and nice to make it work on a GPU, but i'm not particularly interested in rewriting it in glsl/spirv/etc | 20:17:34 |
