| 18 Jan 2021 |
 ghx__ | 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 | Have an error message? Or the data not getting uploaded? | 22:54:36 |
| ghx__ | 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 failed | 22:56:34 |
| ghx__ | 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 manner | 23:01:34 |
| kainino | mappedAtCreation 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 | But yeah, getMappedRange should work after mappedAtCreation | 23:03:14 |
| kainino | I don't know what causes that generic error though. Is the buffer big enough for the getMappedRange call? | 23:04:18 |
| ghx__ | 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 one | 23:11:59 |
| kainino | Oh you can't have two getMappedRange calls that overlap | 23:12:31 |
| ghx__ | Oh | 23:12:37 |
| kainino | (without unmapping and remapping, which you can't do if the buffer isn't mappable) | 23:13:01 |
| kainino | Sorry our error messages are not good | 23:13:18 |
| ghx__ | Oh but I did unmap it | 23:13:49 |
| ghx__ | Well the validation helped me a lot in general ! | 23:14:25 |
| kainino | If you've unmapped, then you would have to map again (mapAsync) in order to getMappedRange again | 23:15:01 |
| ghx__ | Ooooh ! | 23:15:07 |
| kainino | * If you've unmapped, then you would have to map again (mapAsync) in order to getMappedRange again | 23:15:09 |
| ghx__ | I see. Thank you 😁 | 23:15:34 |
| kainino | You need to upload multiple times to the same vertex buffer? | 23:15:38 |
| ghx__ | 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 | I see | 23:17:38 |
| kainino | Yeah 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 buffer | 23:19:11 |
| kainino | The 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 lot | 23:20:15 |
| kainino | A 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 outdated | 23:21:17 |
| ghx__ | 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 one | 23:22:19 |
| ghx__ | i'll search for the ring buffers sample | 23:22:36 |
| kainino | I think it's this https://github.com/gpuweb/gpuweb/blob/main/design/BufferOperations.md#updating-data-to-an-existing-buffer-like-webgls-buffersubdata | 23:24:02 |
| ghx__ | Awesome thank you | 23:25:08 |
| kainino | Hope it helps | 23:25:21 |
| ghx__ | 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 |
