Meeting 2020-08-28

[repi]

Previous meeting: #15

Rough agenda: TBD (please add!)

• General status update - @khyperia
• @VZout is getting up to speed on project, are there specific areas he can contribute to to accelerate the prototype? - @repi
• Discuss potential consultants, internships & master thesis students contributing (possible? who, how, when) - @repi
• Discuss bindings proposal Bindings proposal #19

[Jasper-Bekkers]

• Viktor is trying his hands on a loop structurizer in spirv-tools (we're in contact with David Neto about how to do this properly within spriv-tools).
• One potential intern for this is in final interviewing rounds in TT. Also @maxded expressed interest in contributing here after he's done with his WASM stuff.

[repi]

Meeting notes

Participants

• @repi
• @khyperia
• @VZout
• @Jasper-Bekkers

Minutes

Discussed potential additional candidates for the team

• Master thesis student in Breda to focus on going deeper on optimization algorithms and/or Rust language features?
• Focus on getting the first prototype up before the team can expand more, but keep discussing with potential candidates due to lead time

@khyperia status update

• Things are slowly moving forward, hitting quite a few difficult problems
• Guessing will have libcore compiling in 1-2 weeks
• What features can we use?
  • Pointer offsets are not supported in some shader model
    • Rust compiler occasionally spits it out
  • @Jasper-Bekkers: Banning most stuff that is difficult is likely a good idea as a start
• Goal right now is to dump out a compiling libcore, even if not compiling correctly
• Then when have it as a base one can have more people working on it

@VZout started converting the relooper algorithm from WASM to SPIRV #24

• Being done in the spirv-tools project, will do PR there
• So uses the C++ codebase, looks easier to work with than our Rust rspriv for now, sorta like LLVM light. Can fit into existing spirv-opt.
• Also getting more up speed with the rust-gpu project also to contribute and help @khyperia after initial work

Discussed bindings proposal #19

• Globals for binding?

  • @Jasper-Bekkers: Rust doesn't really have proper globals
  • @khyperia: We can compile it however we want though
  • @Jasper-Bekkers: also made it positional, unclear if good idea
  • SPIRV declares global inputs and outputs, and the entrypoints references them
  • We could require bindless on GPUs, may change this quite a bit
  • Start with simple binding model though for our first use cases
  • Map out the binding landscape more
    • Add to design document of options we have
    • What are the hw/API requirements between the binding types?
    • @Jasper-Bekkers can start on it

• Define Ark use case phases further

  • Will help to target our work and discussions by knowing which phase it is focusing on
  • Something like:
    1. First initial port of single Ark shaders to Rust and compile to SPIRV, plug straight into Ark without changes to runtime code and bindings
    2. Port all current Ark shaders, only vertex and pixel shaders but a bit wider binding support
    3. First Ark proper rendering pipeline, will require compute shaders and more advanced shader bindings such as indexing of resources for clustered forward
  • @repi will write up sketch in more detail, filed #25

• @khyperia will talk to the shader witch about her shader binding preferences and experiences :)

[khyperia]

Ramblings from Freya on bindings and other topics, speedily and roughly transcribed by me:

on bindings:

1. globals are nice, parameter route can get really unweildly and gross when passing lots of stuff
2. shader "headers" don't care about it being globals/parameters, you're going to pass in data anyway
3. instancing gets weird - unity at least has macros to access instanced variables, and so do we want to also have that style of "different data accessor for instanced stuff" or do we build it in
4. interpolators needing to specify TEXCOORD0, 1, 2, COLOR0, etc., is really annoying, can we not? (matters for mesh data inputs, but vert->frag is meh)

library design themed stuff:

1. space transformations should be more built in - e.g. mat4*vec3 needing to specify 0 or 1 for the w component, feels like you're doing archaic garbage and clunky
2. treating transform matricies as transforms is good, rather than just raw matricies - e.g. "I want to get the x axis scale" requires wonky shenanigans requiring lots of knowledge around how matricies work
3. "my general problem with a lot of these things it that it feels like you're writing math, and not shader code - they're super interlinked, but I think there's an important difference in design"
4. "inverse lerp should be built in" :P

random things!

1. I want to know when I put something in an interpolator that will cause it to skew, and if I should put it in the fragment shader. Ashley thinks this is really difficult to analyze, Freya doesn't think so :P (Run the shader on the CPU with a handful of points, and see if it skews when in vertex vs. fragment shader)
2. "If you can run things on the CPU, there's a lot of neat things you can do", like above, and lots of debugging stuff.
3. If we do do a tight cpu<->gpu binding layer, having information about what exactly happened to the bindings is really useful - e.g. if two vec2 interpolators got merged into a single vec4. (Unity does this, and it's obscure and bad)