| 16 Apr 2021 |
 kvark | we don't support varying matrices right now, only scalars and vectors | 21:49:10 |
| 17 Apr 2021 |
 jimb | Hmm. Emacs's flycheck-mode runs cargo check in the background, and that sometimes seems to confuse clippy, such that clippy says all is well, but then cargo clean; cargo clippy has lots to say | 01:48:35 |
| jimb | So, panic! is frowned upon, but unreachable! is permitted? | 02:11:20 |
| kvark | correct | 04:10:52 |
 napokue | I am trying to make a Github Action that is able to verify our HLSL shaders. However, I see the dxc compiler requires a TargetProfile to be specified. This TargetProfile is specific to a shader stage and shader model version. As far as I could could there are about 50 different TargetProfiles.
Does someone maybe know if there is there any way to determine what TargetProfile to use with what HLSL shader? | 14:51:51 |
| kvark | napokue: you'd want a naming scheme, similar to how GLSL is tested. So anything.Vertex.hlsl is for the vs_6_0 profile | 15:01:09 |
| napokue | Is that best practice? So if I have a vertex shader that uses shadermodel 6, then it would be named like: XXX_vs_6_0.hlsl? | 15:02:43 |
| kvark | We currently do not include the profile versions in the snapshot names. Maybe we will, but today if you follow the other backends, you'd need xxx.Vertex.hlsl, and check shader model 6_0 always | 15:04:53 |
| napokue | Sure! So I can (for now) assume that we always compile against only shadermodel 6.0? | 15:05:54 |
| kvark | Yeah | 15:07:03 |
| kvark | The problem of profile selection is common across backends: there are multiple MSl versions, GLSL versions, even SPIRV versions | 15:07:51 |
| napokue | Yeah true, I never really worked in that detail with shaders. Do we actually some day want to support multiple versions? | 15:14:58 |
| napokue | Problem with HLSL is that with shadermodel 6, it will only work on dx12 as far as I can understand from their documentation. | 15:16:00 |
| kvark | We support multiple versions, just not in the snapshots today | 15:39:43 |
| kvark | In reply to @napokue:matrix.org
Problem with HLSL is that with shadermodel 6, it will only work on dx12 as far as I can understand from their documentation. Yeah, that should be our focus | 15:40:04 |
| napokue | Quick newbie question, but do all our makefile commands use linux commands? I guess for windows I have to use other syntax? | 15:40:53 |
| kvark | I haven't tried on Windows | 15:41:35 |
| napokue | None of the makefile commands works at my Windows system | 15:41:52 |
| napokue | * None of the makefile commands works at my Windows system | 15:42:35 |
| napokue | makefile targets* | 15:42:52 |
| kvark | Makefile in general is available on Windows, via "choco install make", iirc | 15:50:28 |
| kvark | Dunno if WSL makes it easier | 15:50:36 |
| napokue | Yes I have make installed via chocolately, but I don't have WSL installed. Will do some more research | 15:54:40 |
| kvark | Gfx CI invokes make, check it out | 15:58:11 |
| napokue | Thanks, was already doing that | 16:01:17 |
| jimb | kvark: The WGSL spec says, "The Entry point IO types include the following: ... Structures containing only built-in variables and user-defined IO. The structure must not contain a nested structure." Is Naga IR also intended to have that restriction? | 16:04:42 |
| kvark | Not today, no. I assumed that nesting is permitted. Nesting may be useful for return types. | 16:08:07 |
| kvark | Currently, not all backends work with neating, so if we want to restrict the IR on this front, it's ok to do | 16:09:11 |
 Ashley (expenses on gh) | Are there any plans for adding an optimiser to Naga? I don't think it's a huge priority at all but I was checking out the code for spirv-opt and it's pretty impenetrable c++, so long term it'd be nice to have an alternative | 17:59:53 |
| kvark | Not currently, no | 18:01:48 |
