| 14 Apr 2021 |
 jasperrlz | I should try to revive my new WebGPU backend... not looking forward to the WGSL stuff tho :/ | 01:32:21 |
| jasperrlz | * I should try to revive my new WebGPU backend... not looking forward to the WGSL stuff tho :/ | 01:32:30 |
|  @drrenardscd:matrix.org joined the room. | 07:30:17 |
| @drrenardscd:matrix.org joined the room. | 09:42:13 |
| @drrenardscd:matrix.org left the room. | 09:44:51 |
|  leldorado joined the room. | 10:14:58 |
|  boundry joined the room. | 13:15:07 |
 jgilbert | I made https://jdashg.github.io/misc/md-minutes-to-details.html to make adding minute comments to github easier for myself, fyi. Not super robust but I think it did this week's minutes correctly! Let me know if you see broken links | 20:09:04 |
| jgilbert | (I use markdown export from our gdocs) | 20:09:28 |
| 16 Apr 2021 |
 hugoam | I'm kind of wondering about the purpose of unfilterable float. How is a WebGPU user supposed to know that some formats can only go with unfilterable float sample type ? | 21:47:57 |
| hugoam | * I'm kind of wondering about the purpose of unfilterable float. How is a WebGPU user supposed to know that some formats can only go with unfilterable float sample type ? | 21:48:17 |
 kainino | https://gpuweb.github.io/gpuweb/#texture-format-caps | 21:48:26 |
| hugoam | I was reading just that, but is the user supposed to just reimplement this table in code ? Because this sounds kind of silly but I'm probably missing something | 21:49:06 |
| hugoam | * I was reading just that, but is the user supposed to just reimplement this table in code ? Because this sounds kind of silly but I'm probably missing something | 21:49:20 |
| kainino | Wait I can't find the actual part of that I wanted to quote | 21:49:39 |
| kainino | Redacted or Malformed Event | 21:49:48 |
| kainino | Redacted or Malformed Event | 21:50:05 |
| kainino | sigh I have already forgotten how this works | 21:50:16 |
| hugoam | haha | 21:50:23 |
| kainino | oh nvm found it, it's r32float, rg32float, and rgba32float | 21:50:49 |
 kvark | hugoam: I don't understand, why would you re-implement the table? If you need filtering, use it. If not, always pick unfiltered | 21:51:12 |
| kainino | There has been talk in the past of having a way to query what you can do with a format | 21:52:21 |
| kvark | kainino: we actually have that in wgpu | 21:52:42 |
| kainino | but it's not a priority until we start adding more optional capabilities to formats | 21:52:45 |
| 17 Apr 2021 |
|  Nausiyan Nyan joined the room. | 06:13:06 |
| 18 Apr 2021 |
| hugoam | Not strictly a WebGPU issue, but related to my WebGPU work, I have a tricky problem where through our convoluted compiler infra (glslang with some heavily hand tweaked HLSL input), something that we wanted to be a storage image ends up as a sampler, because we write those as Texture2D<> in HLSL and those then get automatically converted by glslang to a sampled image with OpImageFetch instead of a storage image with OpImageLoad (which I guess makes sense since there doesn't seem to be strictly a clear distinction in HLSL except through Texture2D vs RWTextureTD)
I decided to try to use a "trick" of declaring those as RWTexture2D<>, with a nonwritable decoration
Does this strategy makes sense or not ? Is it accepted to have nonwritable RWTexture2D<> ? I don't see any other way to convey the fact that we want this to be a storage image (apart from switching to GLSL source which will be a lot of work) | 11:34:00 |
| hugoam | * I have a tricky problem where through our convoluted compiler infra (glslang with some heavily hand tweaked HLSL input), something that we wanted to be a storage image ends up as a sampler, because we write those as Texture2D<> in HLSL and those then get automatically converted by glslang to a sampled image with OpImageFetch instead of a storage image with OpImageLoad
I decided to try to use a "trick" of declaring those as RWTexture2D<>, with a nonwritable decoration
Does this strategy makes sense or not ? Is it accepted to have nonwritable RWTexture2D<> ? | 11:34:17 |
| hugoam | * Not strictly a WebGPU issue, but related to my WebGPU work, I have a tricky problem where through our convoluted compiler infra (glslang with some heavily hand tweaked HLSL input), something that we wanted to be a storage image ends up as a sampler, because we write those as Texture2D<> in HLSL and those then get automatically converted by glslang to a sampled image with OpImageFetch instead of a storage image with OpImageLoad
I decided to try to use a "trick" of declaring those as RWTexture2D<>, with a nonwritable decoration
Does this strategy makes sense or not ? Is it accepted to have nonwritable RWTexture2D<> ? | 11:35:04 |
| hugoam | * Not strictly a WebGPU issue, but related to my WebGPU work, I have a tricky problem where through our convoluted compiler infra (glslang with some heavily hand tweaked HLSL input), something that we wanted to be a storage image ends up as a sampler, because we write those as Texture2D<> in HLSL and those then get automatically converted by glslang to a sampled image with OpImageFetch instead of a storage image with OpImageLoad (which I guess makes sense since there doesn't seem to be strictly a clear distinction in HLSL except through Texture2D vs RWTextureTD)
I decided to try to use a "trick" of declaring those as RWTexture2D<>, with a nonwritable decoration
Does this strategy makes sense or not ? Is it accepted to have nonwritable RWTexture2D<> ? I don't see any other way to convey the fact that we want this to be a storage image (apart from switching to GLSL source which will be a lot of work) | 11:36:54 |
| hugoam | Hmmm googling a little bit it seems that is actually what SPIRV-Cross does by default when emitting HLSL (non writable storage images are expressed as RWTexture2D), so I guess I should be fine here | 11:43:24 |
