!MFogdGJfnZLrDmgkBN:matrix.org

WebGPU

67 Members
The future of graphics and compute on the Web - unofficial channel10 Servers

Load older messages


Timestamp Message
29 May 2020
09:55:19@kangz:matrix.orgKangzBecause when they implemented WebGPU map was getting back into discussion.
09:56:07@kangz:matrix.orgKangzChromium 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_:matrix.orgtandaradei_So currently there is no way of mapping a buffer for write the same way in Chromium and Firefox?
10:08:07@kangz:matrix.orgKangzI guess not :X
10:23:03@tandaradei_:matrix.orgtandaradei_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:matrix.orgKangzIf you call destroy() every time then it might be passable?
11:57:15@tandaradei_:matrix.orgtandaradei_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_:matrix.orgtandaradei_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:matrix.orgKangzNo resolution yet. I expect we'll talk about it in the group's next call on Monday.
12:04:19@kangz:matrix.orgKangzEven 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:matrix.orgkvark 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:matrixim.ccmartha joined the room.
13:41:53@zoechi:matrix.orgzoechi joined the room.
23:04:32@jonathan:converser.eujonathan joined the room.
1 Jun 2020
13:35:46@dj2:matrix.orgdj2
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:matrix.nrp-nautilus.iodimm joined the room.
5 Jun 2020
08:40:08@joshua:netzgemeinde.eujoshua joined the room.
6 Jun 2020
14:42:55@tandaradei_:matrix.orgtandaradei_ Just to be sure, offset and size in setVertexBuffer / setIndexBuffer are meant to be in bytes, not in elements, right?
14:43:23@kimundi:matrix.orgkimundiI thoughts its in elements, actually
14:43:37@kimundi:matrix.orgkimundior wait... offset
14:43:45@kimundi:matrix.orgkimundino idea then
14:44:11@kimundi:matrix.orgkimundisize at least should be elements
15:13:35@kangz:matrix.orgKangzIn bytes
15:13:38@tandaradei_:matrix.orgtandaradei_ 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:matrix.orgkimundiBut don't the examples use the logical element count for the buffers?
15:14:51@kimundi:matrix.orgkimundiWait, this is not Rust-WebGPU...
15:15:10@kimundi:matrix.orgkimundiSorry for the noise, no idea how it works in the JS API 😅
15:21:10@tandaradei_:matrix.orgtandaradei_

Is

  • setIndexBuffer with offset = 20 (10 indices * 2 bytes for 16bit) + drawIndexed with firstIndex = 0
    and
  • setIndexBuffer with offset = 0, but drawIndexed with firstIndex = 10
    equivalent?
16:34:44@kainino:matrix.orgkaininoValue of gl_VertexIndex is different iirc
16:37:51@kainino:matrix.orgkaininoAnd if we had buffer range tracking (we don't), a smaller range might be in use.

There are no newer messages yet.


Back to Room List