| 29 May 2020 |
| 09:55:19 |  Kangz | Because when they implemented WebGPU map was getting back into discussion. |
| 09:56:07 | Kangz | Chromium is actually out of spec, but we need the group to resolve a couple more things before we can implement the new mapping |
| 10:01:22 |  tandaradei_ | So currently there is no way of mapping a buffer for write the same way in Chromium and Firefox? |
| 10:08:07 | Kangz | I guess not :X |
| 10:23:03 | tandaradei_ | Hmm I use it for my staging buffers, so the only solution I see is creating these buffers already mapped (mappedAtCreation) each frame, instead of reusing the buffers. But I suspect this would hurt performance? |
| 10:30:06 | Kangz | If you call destroy() every time then it might be passable? |
| 11:57:15 | tandaradei_ | Looks like it's working :) I have 3 buffers that are created every frame for now and it costs around 0.07-0.08ms for all createBufferMapped calls if I'm reading the Chrome Performance Summary correctly. |
| 11:59:30 | tandaradei_ | So there isn't a final decision how mapping a buffer will work in the end? Either "mapAsync" with flags or two separate functions? |
| 12:03:43 | Kangz | No resolution yet. I expect we'll talk about it in the group's next call on Monday. |
| 12:04:19 | Kangz | Even after it is resolved, implementation might take some time because buffer mapping is a complicated part of the API to make work in a browser. |
| 14:50:54 |  kvark | tandaradei_: we didn't have mapWriteAsync implemented, sorry! We'll have mapAsync and writeBuffer with writeTexture some time soonish though (a few weeks?) |
| 31 May 2020 |
| 09:49:45 | |  martha joined the room. |
| 13:41:53 | |  zoechi joined the room. |
| 23:04:32 | |  jonathan joined the room. |
| 1 Jun 2020 |
| 13:35:46 |  dj2 | In reply to @litherum:matrix.org
dj2: In your proposal at https://github.com/gpuweb/gpuweb/pull/757/files#r421484430, neither function_call_stmt nor func_call_stmt exist Yes, from my comment in #757: 'where func_call_stmt would probably need to be defined for #716 anyway.' |
| 4 Jun 2020 |
| 17:16:40 | |  dimm joined the room. |
| 5 Jun 2020 |
| 08:40:08 | |  joshua joined the room. |
| 6 Jun 2020 |
| 14:42:55 | tandaradei_ | Just to be sure, offset and size in setVertexBuffer / setIndexBuffer are meant to be in bytes, not in elements, right? |
| 14:43:23 |  kimundi | I thoughts its in elements, actually |
| 14:43:37 | kimundi | or wait... offset |
| 14:43:45 | kimundi | no idea then |
| 14:44:11 | kimundi | size at least should be elements |
| 15:13:35 | Kangz | In bytes |
| 15:13:38 | tandaradei_ | Thought it would be bytes because they're of type GPUSize64, while the offsets and counts in for example drawIndexed are of type GPUSize32 |
| 15:14:22 | kimundi | But don't the examples use the logical element count for the buffers? |
| 15:14:51 | kimundi | Wait, this is not Rust-WebGPU... |
| 15:15:10 | kimundi | Sorry for the noise, no idea how it works in the JS API 😅 |
| 15:21:10 | tandaradei_ | Is
setIndexBuffer with offset = 20 (10 indices * 2 bytes for 16bit) + drawIndexed with firstIndex = 0
andsetIndexBuffer with offset = 0, but drawIndexed with firstIndex = 10
equivalent?
|
| 16:34:44 |  kainino | Value of gl_VertexIndex is different iirc |
| 16:37:51 | kainino | And if we had buffer range tracking (we don't), a smaller range might be in use. |
