Meeting Agenda - 24 July 2019

[AlexEne]

This is the place to propose new agenda items and things to discuss in the next meetings.

Current agenda:

• Discuss status on issues.

Feel free to add subjects as a comment.

If you can't make it to the meeting don't worry as there are no decisions made in meetings. It's just a place to discuss ideas, check status of various ongoing things and the only actions taken as a result of a meeting would be: opening a issue or clarifying something on an issue

[kvark]

The state of math libraries?

[anderejd]

Semi off-topic:

Will you be recording the meeting? I would love to listen to/watch the discussion when I find the time. Btw, Rust Gamedev would make an awesome podcast!

[AlexEne]

I am super bad at this, used to have Zoom do this for me but when I needed some space on C: I accidentally deleted meeting recordings :/. I will do my best to record the future meetings.

[Lokathor]

Yeah, I don't think that hangouts has a built in recorder, but OBS works fine. However, they do get quite large.

[khionu]

OBS can record audio only, I'm pretty sure. If not, you can record a 1x1px space.

[jaynus]

The state of math libraries?

I'd like to drill this down a bit, and discuss the optimization (or lack thereof) state of math libraries.

[azriel91]

Exposing the type_name() intrinsic (https://github.com/rust-lang/rust/pull/60066) will allow for better diagnostic messages for specs on stable Rust.

[AlexEne]

Leaving this here for the math bit: https://bitshifter.github.io/2019/07/10/introducing-glam-and-mathbench/

[Lokathor]

I'm in love.

[distransient]

The state of math libraries?

Especially WRT const generics landing à la https://github.com/maplant/aljabar

[AlexEne]

If we are discussing rust math libraries, I would like us to also have a discussion about --ffast-math and the lack of an equivalent (as far as I can tell) for Rust.

I have found nothing besides this abandoned discussion: https://internals.rust-lang.org/t/pre-rfc-whats-the-best-way-to-implement-ffast-math/5740

I think this is a subject that the gamedev-wg should take a deeper look at, as speed of math libs is crucial for the success of Rust in game engines.

[Osspial]

I've made an issue to discuss where we want to head with math libraries: #25

[Lokathor]

I had cause to start a fresh project today.

• I wanted to be fully modern and future-proof and all that, so I wanted to use the latest winit alpha so that I could try the events 2.0 thing (good thing too, because events-loop-2.0 made my initial design thoughts essentially impossible to implement, so i would have painted myself into a corner if i'd used winit 0.19).
• I naturally wanted to also use a new-style GPU API so that's one of gfx-hal, rendy, or wgpu. I've used gfx-hal a tiny bit before and my needs for this project are quite simple so we can stick to the basics.
• This is where we started to hit some bumps: how does one go about making these things work together in a browser?
  • There are some examples, and they claim that they work with the gl backend, but examples aren't actually good as documentation.
  • It seems from the examples that maybe you need to use glutin instead of winit if you want to use WASM+webGL?
  • Or does the backend's Instance value handle GL context creation when the backend is the gl backend?
  • Or... what's the story there?

Meeting Issue: Modern Graphics In A Browser: What's The Story?

EDIT: turns out you can't even use gfx-hal with new winit properly because gfx-hal depends on winit, even though it should be the other way around. Maybe we can talk about getting that fixed since people from hal and winit are both in this group.

[kvark]

There appears to be enough material here to meet once a week...

[Lokathor]

@kvark get Discord and we'll all just chat continually in the Discord channel :P

[AlexEne]

@kvark Could you please lead this meeting and take notes? I will be unable to attend tomorrow.

[Lokathor]

I will be able to attend and record video and/or audio, but I would prefer to not be meeting leader

[kvark]

Ok, will do.

On Jul 23, 2019, at 17:25, Lokathor notifications@github.com wrote:

I will be able to attend and record video and/or audio, but I would prefer to not be meeting leader

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Lokathor]

Current agenda seems to be:

• state of math libraries
• getting windowing/graphics working on wasm
• refactor raw window handles proposal

[AlexEne]

• status of current issues please as it's item 0 on the agenda

[Lokathor]

oh right

[Lokathor]

Hangouts Call Link Reminder: https://hangouts.google.com/call/BgkpIXkZghZH92NqjNWsAEEI

[kvark]

Notes (please feel free to correct):

## refactor raw window handles proposal

K: https://github.com/rust-gamedev/wg/issues/26
O: problem is headless contexts
L: headless would use a specific WSI creation routines
K: headless is ambiguous
O: can't create real headless on GL
M: have a hidden window for function pointers and such, that's what gfx-rs is using
K: proceed without headless for now
L: who wants to start?
O: will start in rust-windowing org
L: want to support Linux kernel framebuffer
O: single function returning a single type is best design, no need for `enum` even. Enums will be inside a platform-specific version.
M: one function per platform, not per OS
L: break the enum of https://github.com/rust-gamedev/wg/issues/26#issuecomment-514050190
L: exhaustive is bad for semver

## math

K: https://github.com/rust-gamedev/wg/issues/25
K: mint helps, cgmath is still a pain point
O: cgmath may not need to be rewritten, it's still very popular. May need a simple library to be developed from the ground up. Main issue: all useful functions are in traits that are weirdly named, points vs vectors.
K: alternative is to duplicate some code
O: right, that's what "std" does, with help of some macros
K: what about "glam"
O: glam works in cases where we don't need to rely on memory layout. Basic math library should have 2 classes of types with some interop, don't have semi-defined layout, actually control the layout. The second set of types with unspecified memory layout, with some constructors, backed by SIMD. Need to expose both classes in the same library, both are used.
L: "glam" memory layout is fully specified. You can look at `Vec4` layout if you want.
O: repr(SIMD) is defined consistently on all architectures?
L: yes, relies on LLVM's definition. Neon and SSE use that packed layout. It's consistent across platforms. If another platform doesn't support it, it's the problem for Rust compiler, not the apps.
O: Vec3 wastes space? everything is aligned to 16 bytes?
L: type as a whole needs to be 16 bytes aligned.
O: can't do unsafe stuff with it?
L: correct. Have an example in the issue.
O: still wasting memory on the GPU.
K: downside of crowning "glam"?
L: Vec3 can't be sent to a GPU.
K: what kind of GPU structus are we discussing?
O: vertex buffer
M: for GPU I don't refer to math libraries, just deal with raw representations. I use nalgebra-glm. It's more intuitive than cgmath/nalgebra. If I need SIMD, I'll need to take care of the layout anyway. "glam" is not the best, e.g. `dot` product has a lot of instructions. Always a trade-off if you have only one instruction to take the benefit of SIMD. If I want to optimize, I'll use SIMD directly with the data laid out in the way I want.
K: this is the case against SIMD in a math library?
M: yes. SIMD doesn't work that well for general purpose.
L: nalgebra-glm is the target complexity level. Perspective support, very practical.
K: why not just using then?
L: I do use it and happy with it. Compile times are nasty, same for the whole graphics stack.
M: disadvantage that it's calling into "nalgebra" stuff, nasty compile errors. Passing everything by reference is not good. API is good though.
O: main issue - all the functions are free floating, which isn't a correct solution. Could be subjective.
K: HLSL is object oriented, GLSL is not
M: can also do free-standing in HLSL.
O: advantage is having all the things in one place, good for documentation
M: complex stuff in math libraries, it's hard to read the code. Fluid simulation. Hard to compare the code with the paper.
M: free-standing functions are easier to read in the code then
K: enumerate consensus: new library, GLM-like API with free-standing functions, no traits.
L: plus the fact GPU is not the same as CPU representation often
K: may need normalized types
O: could be in a separate crate
L: like to have the math library 100% contained

## getting windowing/graphics working on wasm

L: asking because I don't know. wgpu-rs is supposed to be browser-compatible. Can target WebGL via Glutin. Can we call "stdweb" and call into canvas? Do we have an answer to targeting the Web? Rendy has a backend.
K: isn't it gfx-backend-gl
L: Rendy is in a half-way state
J: GL backend for the Web is not using Glutin, we interact with WebGL context directly. Maybe what L is seeing is the Emscripten backend?
L: Yes. Winit supports both Emscripten and StdWeb
J: both for WASM. In fact, there are 3 approaches. More recently the community has settled around Wasm-bindgen.
J: Stdweb still goes through Emscripten. Hard to talk about it, since wasm32-unknown-unknown is still in flux(?)
J: hoping the ecosystem to use `winit`
L: there is work for other people to do: winit needs to merge better WASM support before it becomes practical. See https://github.com/rust-windowing/winit/tree/web

## backend selection

L: when making a new gfx-hal project, you need to set up the features right now. Icefoxen wanted to have all the backends available to be built, and one selected automatically. I want to select one at compile time.
K: multiple backends?
L: Linux/Windows always picks Vulkan, for example. Normal builds do the run-time selection.
M: for API side, we should be having a single Instance and expose physical devices
K: we are going to do this for wgpu: https://github.com/gfx-rs/wgpu/issues/252
L: abstracting between GL and non-GL is tricky. Icefox made a demo.
M: instance and surface are separate now in gfx GL backend, at least on Windows. Could be problematic on Wayland.
L: we could make a simple backend that works for 90% of cases (one canvas).
K: we want wgpu-rs to cover this for most users, not gfx-hal
L: need better awareness. Let's put a link to the blog in wgpu repos.

J = @grovesNL, K = @kvark, L = @Lokathor, M = @msiglreith, O = @Osspial

[distransient]

Ah, since only I dropped in to listen at the very end the notes are very appreciated. Thank you!

[Lokathor]

• good news: the video seems to have recorded properly, and we even hit almost exactly 1 hour (1:00:26) because going over time at the end was cancelled out by starting a little late
• bad news: the file is 1.2gb so i don't know how i can easily send it to someone else. For now I'll upload it to my youtube account for rust stuff. Youtube says that it will be live at https://youtu.be/5gIi_4CLVtU eventually (once it uploads and then youtube does the video processing thing; probably an hour from when this posts). I can also keep it around for a while if someone else has a plan to put it in a more official place later.

[AlexEne]

@Lokathor let's see if we can unify those and put them with other people (some seem to be on the official channel).

I will close this and open another issue for the next meeting. Thanks all for attending