!MFogdGJfnZLrDmgkBN:matrix.org

WebGPU

784 Members
The future of graphics and compute on the Web! Related rooms: https://matrix.to/#/#webgraphics:matrix.org50 Servers

Load older messages


SenderMessageTime
6 Apr 2024
@marksibly:matrix.orgmarksibly

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:

  1. Upload ALL LVP matrices in one hit into an intermmediate buffer, and then use CommandEncoder.CopyBuffer to copy each LVP matrix to uniform data per shadow pass. I'm guessing this is the right way to go as it means I only ever need to create 1 command encoder for everything, and there is only the CPU->GPU copy and the buffer 'chunk' copying may be more efficient on the GPU?

  2. Create a unique bind group for each shadow pass and use SetBindGroup for each shadow pass (I'm actually sort of doing this already, I actually use 6 per-face boid groups so I only have to create lightCount command encoders). The downside to this approach is that it could potentially complicate the use of render bundles, something I'm not doing yet but would like to try at some point.

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:matrix.orgmehmetoguzderin changed their profile picture.10:12:08
@frguthmann:matrix.orgFrançois Guthmann

Hey all,

I'm trying to do something like the following in WGSL but it doesn't seem to be allowed:

var myVec4 : vec4f;
myVec4.xy = vec2f(1.0, 0.0);

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:matrix.orgKangzThere 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
@frguthmann:matrix.orgFrançois Guthmann *

Hey all,

I'm trying to do something like the following in WGSL but it doesn't seem to be allowed:

var myVec4 : vec4f;
myVec4.xy = vec2f(1.0, 0.0);

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:matrix.orgjasperrlzSwizzle assign would be great22:23:51
@jasperrlz:matrix.orgjasperrlz
In reply to @marksibly:matrix.org

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:

  1. Upload ALL LVP matrices in one hit into an intermmediate buffer, and then use CommandEncoder.CopyBuffer to copy each LVP matrix to uniform data per shadow pass. I'm guessing this is the right way to go as it means I only ever need to create 1 command encoder for everything, and there is only the CPU->GPU copy and the buffer 'chunk' copying may be more efficient on the GPU?

  2. Create a unique bind group for each shadow pass and use SetBindGroup for each shadow pass (I'm actually sort of doing this already, I actually use 6 per-face boid groups so I only have to create lightCount command encoders). The downside to this approach is that it could potentially complicate the use of render bundles, something I'm not doing yet but would like to try at some point.

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?

I 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:matrix.orgjasperrlzThe 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
@hackerham:matrix.orgIvan Popelyshev
In reply to @marksibly:matrix.org

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:

  1. Upload ALL LVP matrices in one hit into an intermmediate buffer, and then use CommandEncoder.CopyBuffer to copy each LVP matrix to uniform data per shadow pass. I'm guessing this is the right way to go as it means I only ever need to create 1 command encoder for everything, and there is only the CPU->GPU copy and the buffer 'chunk' copying may be more efficient on the GPU?

  2. Create a unique bind group for each shadow pass and use SetBindGroup for each shadow pass (I'm actually sort of doing this already, I actually use 6 per-face boid groups so I only have to create lightCount command encoders). The downside to this approach is that it could potentially complicate the use of render bundles, something I'm not doing yet but would like to try at some point.

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?

In 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:matrix.orgjasperrlzHow do you bootstrap the index into the storage buffer then?23:13:21
@jasperrlz:matrix.orgjasperrlzThis 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-191619233323:16:19
10 Apr 2024
@shadiaowangyou:matrix.orgshadiaowangyou joined the room.06:41:59
@shadiaowangyou:matrix.orgshadiaowangyou changed their display name from wangyou shadiao to shadiaowangyou.06:43:51
@flohofwoe:matrix.orgAndre WeissflogUuuuh, 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
@flohofwoe:matrix.orgAndre 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
@flohofwoe:matrix.orgAndre 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
@flohofwoe:matrix.orgAndre 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:matrix.orgscott_michaud_rivRedacted or Malformed Event17:34:53
@scott_michaud_riv:matrix.orgscott_michaud_rivRedacted or Malformed Event17:35:09
@scott_michaud_riv:matrix.orgscott_michaud_rivInteresting. Yeah. I'm seeing 60 FPS on Chrome Stable, but 100 on Canary, Chromium, and Firefox.17:35:19
@scott_michaud_riv:matrix.orgscott_michaud_riv(My monitor is 100Hz)17:35:48
@flohofwoe:matrix.orgAndre Weissflogah 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
@flohofwoe:matrix.orgAndre Weissflog...also why is it 60Hz on a 100Hz monitor instead of 50 Hz. That doesn't make any sense 😅 17:39:55
@shelby_nya:catgirl.cloudShelby Lynn changed their display name from shelby_nya to Shelby Lynn.17:41:27
@flohofwoe:matrix.orgAndre Weissflogit's not a power preference thing btw, I already tried that17:41:44
@kainino:matrix.orgkainino (he/they)seeing this too, it is probably a power consumption experiment of some kind17:44:29
@flohofwoe:matrix.orgAndre WeissflogI 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" tbh17:46:40
@flohofwoe:matrix.orgAndre Weissflog...and even if it "sticks" I hope it will be configurable.17:47:24
@miketuritzin:matrix.orgmiketuritzinYeah, 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:matrix.orgmiketuritzin(and WebGPU :D )18:22:14

Show newer messages


Back to Room ListRoom Version: 5