!MFogdGJfnZLrDmgkBN:matrix.org

WebGPU

130 Members
The future of graphics and compute on the Web - unofficial channel. Related rooms: https://matrix.to/#/+webgraphics:matrix.org28 Servers

Load older messages


SenderMessageTime
18 Jan 2021
@ghx__:matrix.orgghx__Damn-it, this option 1 does not seem to work for me in Dawn. I'll look at it a bit further, thank you for the answer and thanks for your work on the API !22:53:41
@kainino:matrix.orgkaininoHave an error message? Or the data not getting uploaded?22:54:36
@ghx__:matrix.orgghx__The error message is not very explicit, I'm using the Dawn implementation in Chrome Canary not the library directly. I get : wgpuBufferGetMappedRange(0, 4044) failed: OperationError: Failed to execute 'getMappedRange' on 'GPUBuffer': getMappedRange failed22:56:34
@ghx__:matrix.orgghx__I did use mappedAtCreation instead of a call to mapAsync since I did not want to have to deal with async code. I took the bet that creating the buffer with mappedAtCreation would give me a mapped buffer in a synchronous manner23:01:34
@kainino:matrix.orgkaininomappedAtCreation is different from mapAsync, not just in that it's async. mapAsync requires a MAP_WRITE usage but mappedAtCreation doesn't (it's for setting initial data).23:02:55
@kainino:matrix.orgkaininoBut yeah, getMappedRange should work after mappedAtCreation23:03:14
@kainino:matrix.orgkaininoI don't know what causes that generic error though. Is the buffer big enough for the getMappedRange call?23:04:18
@ghx__:matrix.orgghx__Yes, in this case 4044 is the exact buffer size. But I'll have to look a it a bit more because it seems to do fine on the first call to GetMappedRange, which indicates to me that I must be doing some non glorious things between the first call and the following one23:11:59
@kainino:matrix.orgkaininoOh you can't have two getMappedRange calls that overlap23:12:31
@ghx__:matrix.orgghx__Oh23:12:37
@kainino:matrix.orgkainino(without unmapping and remapping, which you can't do if the buffer isn't mappable)23:13:01
@kainino:matrix.orgkaininoSorry our error messages are not good23:13:18
@ghx__:matrix.orgghx__Oh but I did unmap it23:13:49
@ghx__:matrix.orgghx__Well the validation helped me a lot in general !23:14:25
@kainino:matrix.orgkaininoIf you've unmapped, then you would have to map again (mapAsync) in order to getMappedRange again23:15:01
@ghx__:matrix.orgghx__Ooooh !23:15:07
@kainino:matrix.orgkainino* If you've unmapped, then you would have to map again (mapAsync) in order to getMappedRange again23:15:09
@ghx__:matrix.orgghx__I see. Thank you 😁23:15:34
@kainino:matrix.orgkaininoYou need to upload multiple times to the same vertex buffer?23:15:38
@ghx__:matrix.orgghx__Well, it may not be the most optimal thing to do, but I reuse the previous buffer instead of creating a new one if I have less vertices to deal with. 23:17:28
@kainino:matrix.orgkaininoI see23:17:38
@kainino:matrix.orgkaininoYeah in that case you'd need to either make it MAP_WRITE and mapAsync (but MAP_WRITE may have a cost, like reducing the performance of the vertex buffer), or copy updates into it from another MAP_WRITE|COPY_SRC staging buffer23:19:11
@kainino:matrix.orgkaininoThe cost of creating a new mappedAtCreation buffer should not be too high, but a staging buffer would be good if you have to do it a lot23:20:15
@kainino:matrix.orgkaininoA ring of staging buffers that you keep mapped, so you never have to wait for them to finish mapping. we have an example of this... I think in the spec repo design/ folder, but it may be outdated23:21:17
@ghx__:matrix.orgghx__I get the options ! I guess I could keep this MAP_WRITE|COPY_SRC staging buffer you mention and only resize it when I need a bigger one23:22:19
@ghx__:matrix.orgghx__i'll search for the ring buffers sample23:22:36
@kainino:matrix.orgkaininoI think it's this https://github.com/gpuweb/gpuweb/blob/main/design/BufferOperations.md#updating-data-to-an-existing-buffer-like-webgls-buffersubdata23:24:02
@ghx__:matrix.orgghx__Awesome thank you23:25:08
@kainino:matrix.orgkaininoHope it helps23:25:21
@ghx__:matrix.orgghx__I'll get to it tomorrow, it's getting late here and I'll just pile up the mistakes, have a good day/night !23:26:53

There are no newer messages yet.


Back to Room List