Sender | Message | Time |
---|---|---|
6 Apr 2024 | ||
marksibly | I am working on a point light shadow mapping system which is working well but could probably be improved. In particular, to upload the 'light view projection' matrices I'm using Queue.WriteBuffer, mainly because it's what I'm most familiar with. However, this means I have to stop/restart rendering (ie: Create a new command encoder) for every shadow pass (ie: lightCount * 6 cube faces) and my understanding is that I should avoid creating 'too many' command encoders. I can think of 2 alternatives to this:
Am I missing another way? Another approach could involve using an array of LVP matrices, but then I've got the same problem of having to upload an 'index' uniform. What's the best approach here? | 21:52:28 |
7 Apr 2024 | ||
mehmetoguzderin changed their profile picture. | 10:12:08 | |
François Guthmann | Hey all, I'm trying to do something like the following in WGSL but it doesn't seem to be allowed:
Am I missing some convenient way to do this ? ( For example there is not ternary operator but I can use select instead ). If not, it's not the end of the world but it would be a nice to have addition to the language. | 13:33:53 |
Kangz | There is no assign-to-swizzle yet, but it's a very often requested feature so I think it'll get in at some point. | 15:29:20 |
François Guthmann | * Hey all, I'm trying to do something like the following in WGSL but it doesn't seem to be allowed:
Am I missing some convenient way to do this ? ( For example there is no ternary operator but I can use select instead ). If not, it's not the end of the world but it would be a nice to have addition to the language. | 15:31:01 |
jasperrlz | Swizzle assign would be great | 22:23:51 |
jasperrlz | In reply to @marksibly:matrix.orgI would use the SetBindGroup strategy and ignore render bundles. You can also use dynamic uniform buffers to reuse the same bind group with different offsets. | 22:24:55 |
jasperrlz | The downside of the copyBufferToBuffer approach is that you can't overlap rendering to the different faces. Not that that's likely to happen to begin with, but I would try and give as much opportunity to parallelize as possible. | 22:25:56 |
8 Apr 2024 | ||
Ivan Popelyshev | In reply to @marksibly:matrix.orgIn general, if you want to evade assigning uniforms for each pass, and you have many to bind - put them in storage buffer, it wont cost that much. | 04:56:29 |
jasperrlz | How do you bootstrap the index into the storage buffer then? | 23:13:21 |
jasperrlz | This is where I would a simple push constants API like the one I proposed would come in handy btw. https://github.com/gpuweb/gpuweb/issues/75#issuecomment-1916192333 | 23:16:19 |
10 Apr 2024 | ||
shadiaowangyou joined the room. | 06:41:59 | |
shadiaowangyou changed their display name from wangyou shadiao to shadiaowangyou. | 06:43:51 | |
Andre Weissflog | Uuuuh, does anybody know if Chrome switched to a 60Hz frame update on Apple Silicon Macs recently? Normally it's 120 Hz, but I'm just noticing that both my WebGL and WebGPU demos run at 60 Hz. | 17:10:01 |
Andre Weissflog | * Uuuuh, does anybody know if Chrome switched to a 60Hz frame update on Apple Silicon Macs recently? Normally it's 120 Hz, but I'm just noticing that both my WebGL and WebGPU demos run at 60 Hz. PS: see here: https://floooh.github.io/sokol-html5/imgui-sapp.html ...and notice the ms/frame in the Debug Window. This used to be 8.333ms in Chrome (and still is in Firefox), but is now 16.666. It could be an intended change to behave like Safari, but TBH this would suck because the 120 Hz was also a nice an cheap way to reduce input-to-screen latency both in WebGL and WebGPU with their overly long swapchain pipelines... | 17:24:36 |
Andre Weissflog | * Uuuuh, does anybody know if Chrome switched to a 60Hz frame update on Apple Silicon Macs recently? Normally it's 120 Hz, but I'm just noticing that both my WebGL and WebGPU demos run at 60 Hz. PS: see here: https://floooh.github.io/sokol-html5/imgui-sapp.html ...and notice the ms/frame in the Debug Window. This used to be 8.333ms in Chrome (and still is in Firefox), but is now 16.666. It could be an intended change to behave like Safari, but TBH this would suck because the 120 Hz was also a nice and cheap way to reduce input-to-screen latency both in WebGL and WebGPU with their overly long swapchain pipelines... | 17:24:58 |
Andre Weissflog | * Uuuuh, does anybody know if Chrome switched to a 60Hz frame update on Apple Silicon Macs recently? Normally it's 120 Hz, but I'm just noticing that both my WebGL and WebGPU demos run at 60 Hz. PS: see here: https://floooh.github.io/sokol-html5/imgui-sapp.html ...and notice the ms/frame in the Debug Window. This used to settle on 8.333ms in Chrome (and still is in Firefox), but is now 16.666. It could be an intended change to behave like Safari, but TBH this would suck because the 120 Hz was also a nice and cheap way to reduce input-to-screen latency both in WebGL and WebGPU with their overly long swapchain pipelines... | 17:33:40 |
scott_michaud_riv | Redacted or Malformed Event | 17:34:53 |
scott_michaud_riv | Redacted or Malformed Event | 17:35:09 |
scott_michaud_riv | Interesting. Yeah. I'm seeing 60 FPS on Chrome Stable, but 100 on Canary, Chromium, and Firefox. | 17:35:19 |
scott_michaud_riv | (My monitor is 100Hz) | 17:35:48 |
Andre Weissflog | ah good point, I have the Chrome Dev version 125.x installed, and that's still 120 Hz, while the public version 123.0.6312.107 has 60 Hz. I hope it's just a bug or experiment :/ | 17:38:20 |
Andre Weissflog | ...also why is it 60Hz on a 100Hz monitor instead of 50 Hz. That doesn't make any sense 😅 | 17:39:55 |
Shelby Lynn changed their display name from shelby_nya to Shelby Lynn. | 17:41:27 | |
Andre Weissflog | it's not a power preference thing btw, I already tried that | 17:41:44 |
kainino (he/they) | seeing this too, it is probably a power consumption experiment of some kind | 17:44:29 |
Andre Weissflog | I hope it's not one of those dudes behind it who believe that humans can't notice the difference between 30Hz and 60Hz ;) I'm not so much concerned about "smoothness" but "latency" tbh | 17:46:40 |
Andre Weissflog | ...and even if it "sticks" I hope it will be configurable. | 17:47:24 |
miketuritzin | Yeah, I would definitely be worried if this is more than a mistake/temporary experiment - being able to match native screen refresh in WebGL is important for web apps! | 18:22:03 |
miketuritzin | (and WebGPU :D ) | 18:22:14 |