Meeting 2020-10-29

[arirawr]

Previous meeting: #62

Time: 17:00 CET
Where: #rust-gpu voice channel on Ark Discord.

Agenda
(please edit/add)

• @khyperia project update
• @termhn has officially joined!
• How does open source feel so far?
• How do we think it is going towards converting most Ark shaders by December?

tech discussions, not everyone required:

• spirv-builder for single crate with multiple shaders, i.e. example-shaders crate that @repi has mentioned - @termhn
• Related to GPU-side layout/binding attributes #45, input/output/binding model to use for converting ark shaders? - @termhn
• Suggestion: Don't name everything after spirv. #128 bikeshed names (timeboxed) - @khyperia
• Tracking: Support for SPIR-V < 1.3 (and therefore Vulkan < 1.1) #164 and OpenGL compatibility #167 - documentation of unsupported-ness? (will add proper tests soon) - @khyperia
• glam status update (any compiler support needed? any new thoughts on Intercept calls to (rust) libm and emit a builtin instead of the soft impl #81?) - @repi
• how do we intend other repos (like Ark or Bevy) to use the rustc backend and crates - @repi
• Tracking: Support for SPIR-V < 1.3 (and therefore Vulkan < 1.1) #164 - what spir-v version do we target by default? currently 1.3 by arbitrary choice (intel_compute_runtime only supports <=1.3) @khyperia
• GPU-side layout/binding attributes #45 - I've completely forgot what we decided re: moving Output to return value, I'm leaning towards not implementing this (just waiting for binding rfc), is that okay? - @khyperia

[repi]

Meeting notes

Participants

• @repi
• @khyperia
• @VZout
• @Jasper-Bekkers
• @arirawr
• @XAMPPRocky
• @termhn
• @Jake-Shadle
• Additional guests from Discord, first open meeting!

Minutes

How did the open sourcing go / feel?

• "Only happy good feelings!" 💖

• @arirawr: Very positive, quite happy!

• @repi: Been awesome to see the positive response & interest, more than I expected!

• Discord channel got very busy and a bit chaotic first

  • But looks like it is calming down a bit, continue to discuss bigger things in issues
  • If needed could split rust-gpu channel into "#rust-gpu-users" and "#rust-gpudev" channels
  • Or move more general discussions into the "#opensource" channel?

• Lots want compute shaders

  • Probably from the wider Rust community, not graphics community
  • Will be supported, but graphics is first
  • Filed Compute shader support & basic example #180

• Some setup problems for new users

  • Unknown GPUs, Vulkan setup, complex Linux
  • Let's at least document what we use and focus on as guideline for other devs.
  • Let's start on a FAQ / base requirements listing for the book. @XAMPPRocky filed Documenting Platform Support #177

Converting our Ark shaders #36

• @termhn will start converting our basic engine shaders from GLSL to Rust GPU!

• Binding model will be one of the challenges

  • @khyperia: Not confident that can implement the new binding RFC-001 anytime soon
  • But can start using use the current system!
    • We have binding & location
    • Don't have textures & sampler types

• Phased approach:

  1. Find first simple graphics shaders to convert (mesh shader)
     • May need some smaller compiler support & fixes
     • Strip out Multiview extension support in our shaders? Or add it
  2. Shaders with textures & bindings
  3. Compute shaders

• Put all of our shaders in a single ark-shaders crate with multiple entrypoints, already supported!

"Don't name everything after spirv" (#128)

• Compiler backend and code generation is for SPIRV compiler, so target will remain SPIRV and low-level things named for it.

• Eventually compiler may support other outputs or be more general GPU-related and could rename then, but don't want to do it now, too early and speculative.

• Higher-level or more user-facing aspects can called "shader" or "GPU", but most will likely just be cross-platform Rust code (like glam)

SPIRV support before 1.3 (#164), and OpenGL (#167)

• How much do we support, what are our tiers?

• Too early to define proper tiers, but can do later on similar to Rust (but quite complex due to OS / driver / vendors)

• Define what we (Embark) support and care about, what we will use in Ark in the short- & mid-term

• Could have optional not-fully supported other targets from community, like OpenGL support

• What happens when we require Vulkan memory model, require or make it optional? For now it is based just on our own needs, have to be able to move fast.

• Define in the book what we are currently focus on so it is more clear for everyone what should work and is a priority

  • Vendors, capability levels, drivers and operating systems
  • File new issue and discuss, @XAMPPRocky filed Documenting Platform Support #177

• Decision: Staying & focusing on SPIRV 1.3 by default

Glam update (#134)

• @repi: Made some really good progress, our shaders are working with it now on both CPU and GPU!

• Some clippy issues remaining, may skip

• How to expose further intrinsics and SPIRV specifics? 3 levels/approaches for it:

  1. core::intrinsics::* - Rust core intrinsics, these are easy to map 1 to 1 with SPIRV intrinsics and we do this already
  2. libm replacement - for f32 functionality missing in core::intrinsics
     • implement using Rust libm and replace in compiler backend with SPIRV intrinsics.
     • glam no_std CPU is using libm also (no_std support bitshifter/glam-rs#5, branch)
  3. unknown - for SPIRV intrinsics we want to use that neither core::intrinsics nor libm implements.
     • @JasperBekkers will file issue and start listing what intrinsics we want to use. Support additional shader intrinsics #197

• @khyperia: Should we pursue the libm replacement as next step?

  • Required for glam tan
  • Decision: yes

• Do we also have a f32x4 "built-in" simd type?

  • Decision: No for now, not needed as any crate can define their own instead

How to build & distribute rustc_backend_spriv for other repos?

• Our spirv-builder is the easiest, is used today already but some issues with "Cargo in Cargo"

• Can have separate shader folder and .cargo/config to build for right target with. @repi been doing this locally and nice with no "Cargo in Cargo" issues and works with more tools.

• Ideally want to just cargo install the backend, or long term on have it part of rustup & Rust in general

• @Jake-Shadle Can't do cargo install for dylibs/dlls today, that would have been nice

  • Could be solved, cargo install a library as .dll / .so file rust-lang/cargo#8317 cargo install <library_name> --library rust-lang/cargo#2552
  • Or have a wrapper binary program
  • Or add support in Cargo/rust for it in cargo/rustup

• @khyperia Another option is to to have a wrapper rustc.exe that includes and uses our backend and calls the real rustc

• We'll discuss and experiment further but have a few approaches that can work

Other

• @VZout: While loops are now in! 🎉 #

• Decision: And not going to move input/output values (GPU-side layout/binding attributes #45)