Meeting 2020-08-20

[repi]

Previous meeting: #6

Rough agenda

• Give technical overview of project to @pcwalton - @khyperia
• Potential questions/discussion topics with @pcwalton
  • What's the probability of getting language features in? e.g. designs for pointer address spaces (anywhere from tweaking things to make an intrinsic wrapper struct ergonomic, to actual syntax in e.g. ref type decls) - @khyperia
  • Areas to collaborate on and how?
• Discuss first sketches on converted Rust shaders Sketch simple shaders #14
• Light RFC process (RFC template #18) and/or markdown design docs?

[repi]

Meeting notes

Participants

• @repi
• @khyperia
• @MaikKlein
• @Jasper-Bekkers
• @pcwalton

Minutes

• We have some first converted example pseudo-Rust graphics shaders to start discussions about syntax Sketch simple shaders #14

  • Great to also get @h3r2tic feedback about shaders, should continue to poll people outside the pod for feedback! Initially internally at Embark, but later wider in the community
  • @pcwalton: the Rust shader conversions is very similar to the work did in pathfinder_simd.
    • makes vector SIMD code very easy to write and read
    • the shaders in Sketch simple shaders #14 would almost compile. Things like splat is close to identical
    • has swizzles
      • Implemented as functions
      • Generated the swizzle functions, not that much code
    • euclid was quite verbose
    • Typing Vec4::new gets really old, created just a vec4 func
    • Had a distinction between to and as for casts

• Need to get a bit further on the SPIRV backend that @khyperia is working on, before @Jasper-Bekkers and more can help

• @pcwalton mentioned he worked with Eric Holt (twitter) earlier in 2013 on an LLVM PTX backend

• Should list previous Rust GPU attempts and related initiatives, added List previous Rust on GPU initatives and related projects #20

Tech overview & discussion

• @khyperia did a quick overview of the current technical parts of the project and backend
• Approach
  • Current: rustc_codegen_ssa helper library
  • Other approaches: LLVM spirv backend
    • @pcwalton: why not to use it?
    • @khyperia: out of tree, very specialized (only kernel functions), doesn't support shaders
    • Kernel behaviors do not need structured control flow
  • Cranelift backend
  • Straight-from-MIR, no rustc_codegen_ssa
• Current big problems and questions we are facing
  • How to handle pointer address spaces
  • How to convert to SPIRV structured control flow Structured control flow #9
    • SPIRV uses it, MIR and codegen-ssa does not
    • Contribute a structorization pass to SPIRV
    • Have to have a restructuring pass somewhere
      • Algorithm like relooper (Alon - https://github.com/kripken, @pcwalton used to work with/next to him).
      • spirv has some weird quirks around it
    • Can contribute pass to spirv-opt, we need to run it anyway to optimize codgen (mem2reg)
    • @Jasper-Bekkers been casually discussing if we could remove SPIRV requirement on structured control flow eventually in SPIRV
      • May work for some architectures, but not in geneeral
      • Intel drivers and mobile drivers likely still require it though
      • So seems unlikely
• Could there be any concerns putting spirv-opt, a C++ library, into mainline Rust eventually?
  • Pretty basic input/output in it
  • bindgen with Rust chain wouldn't be hard
  • @pcwalton: likely fine, how mature is spirv-opt?
    • Potential concern: loosing LLVM level optimizations?
    • @Jasper-Bekkers: quite mature, required dependency for DXC and SPIRV, Vulkan games use it so production quality
    • Also shader driver stacks do further optimizations on the SPIRV

Future

• @repi: Should this project target CPU SIMD code as well?

  • Very similar syntax for CPU SPMD and GPU SPMD (a la ISPC but with Rust)
  • Current consensus: Could eventually, but focus on GPU code first
  • @pcwalton: one of the hardest is managing different memory spaces
    • In metal const and constant are different keywords
  • @pcwalton: Not too happy with how Metal made vs & ps functions with many attributes.
    • "they are not really functions"
    • @Jasper-Bekkers: been thinking that graphics shaders could be modelled as channels / pipelines
      • Johan: how deep do we go with wave intrinsics executable
  • Johan: we can target a very specific modern gfx/compute subset, skip vertex attributes / input layouts
    • @pcwalton: webgpu is considering that
  • Johan: having nice high-level crates that with the algorithms that work on multiple targets is very valuable.
    • Even if actual implementation in graphics, compute shaders, CPU using the shared crates have to look quite different
    • Build great ecosystem of algorithm crates

• @Jasper-Bekkers : long term goal of project to get integrated into Rust, challenges to get to eventual Tier 1?

  • @pcwalton: likely based on community demand. if there is demand for it, it will happen
  • @pcwalton: most important to get people excited about it and using it
  • Johan: Would require testing hardware across GPUs
    • @pcwalton: Microsoft could be ideal for it
    • CPU testing can cover some, but need GPU also
    • @MaikKlein did testing of shaders using a compute path with RLSL

• @pcwalton about the project in general

  • Everything sounds interesting, all of the stuff :)
    • compiler, vector libraries, how does it slot into engine
    • making sure you can implement important things as SSAO, TAA, PBR
  • SPIRV makes this actually viable & good base
    • Skip the full codegen of backends
  • Continue with the weekly meetings and async repo discussions
  • @repi and @pcwalton to follow up more on how we can collaborate

• When should we go open with the project?

  • Earlier or later when we have a proof of concept?
  • @MaikKlein : did it public from the beginning with RLSL, but in hindsight probably should waited until a bit later. Got too many people connecting about it too early
  • Will be a lot of opinions and excited users that want to use it, so better have something
  • Minimum: Have a clear design docs & direction in the repo
  • Current focus: have a concrete prototype / proof of concept, good design docs, be able to use it
  • Want an early spark to excite users
    • Ark open source games
    • "shadertoy.rs"!
      • have great integration with crates and docs.rs
      • @pcwalton: will go viral!
    • three.js / babylon.js web engine integration?
  • Target users (in order)
    1. Embark & Ark - dog food our own stuff, if it is not usable for us at all, unlikely usable by anyone else
    2. Rust enthusiasts - other Rust engines and hobbyists
    3. (once it is quite good) Web community with WebGPU and SPIRV->WSL conversion

• Who else should we talk to and interact with?

  • For Rust language features - likely talk to Manish
    • @pcwalton: people are probably not going to care too much about GPU specifics. probably not a problem
    • @khyperia: gut feeling that we mostly need smaller esoteric GPU things
  • @pcwalton will think about if there are others later
    • Often talk to Niko about GPU stuff, certainly interested

Other ideas & later goals

• Benchmark suite with Rust shaders will later help motivate IHVs to fix codegen issues (correctness and performance)
• High-level render graph to tie it all together and operate over passes and kernels Render graph design #21

@khyperia @Jasper-Bekkers @MaikKlein @pcwalton anything incorrect or missing (if so add!), any new issues we should file and link here?

[repi]

@khyperia do we have an issue we can link around the "How to handle pointer address spaces"?

[khyperia]

Don't think so, no, I'll make one tomorrow if someone else doesn't do so by then.

[Jasper-Bekkers]

@Jasper-Bekkers been casually discussing if we could remove SPIRV requirement on structured control flow eventually in SPIRV

• Two other points I forgot to mention during the meeting
  • The vulkan memory model relies heavily on the assumption that control flow is structured
  • Wave ops make it more or less a requirement on AMD and NVIDIA too (since one needs to keep track of exec mask state there)

[khyperia]

@khyperia do we have an issue we can link around the "How to handle pointer address spaces"?

#23