GetMappedRange on READ-mapped buffer

[kainino0x]

When a buffer is mapped for READ, GetConstMappedRange must be used to get a pointer. What happens if you use GetMappedRange? Dawn currently returns nullptr, but I think perhaps it should be invalid (e.g. crash on assertion in debug mode), for debuggability.

https://matrix.to/#/!ZSOHTEPDbwuEgSJwYw:matrix.org/$LHAITjEUC-TmB-YZ1des5TeUBO-FFRIvnZRfgfgbSZg?via=matrix.org

[kainino0x]

With or without that change, these could also be renamed as explicitly Read or ReadWrite. Though I like the current names personally.

[kainino0x]

In last week's meeting I think we settled on a proposal to:

• keep API surface as it is
• fail with an actual error string if you GetMappedRange on a READ mapping (see Ownership of returned strings #143) or do anything else wrong (e.g. ask for an overlapping range, at least in Emscripten, see Synchronous validation in getMappedRange #64)

[kainino0x]

• keep API surface as it is

Sorry I think I probably forgot to finish typing this sentence? the actual proposal adds some stuff to the API surface, and is here #143 (comment):

struct WGPUGetMappedRangeError {
    char const * errorMessage;
}

void * wgpuBufferGetMappedRange(
    WGPUBuffer buffer, size_t offset, size_t size, WGPUGetMappedRangeError * Error WGPU_NULLABLE);

void wgpuGetMappedRangeResultFreeMembers(WGPUGetMappedRangeError);

[kainino0x]

We introduced the concept of "implementation-defined logging", which probably happened after the resolution above. I would prefer to use that here, and simply say "if there is an error, returns null and should log an error message to an implementation-defined log"

[lokokung]

+1 on using the implementation-defined logging for this to avoid the additional argument change. A validation error could also be a possible solution.

[eliemichel]

Couldn't the use of wgpuBufferGetMappedRange on a read-only mapped buffer trigger the device's uncaptured error callback? I remember doing this mistake a couple of time, and it always took me a bit more time to figure out my mistake than if the device's error callback would have been directly called to tell me "what you do makes no sense".

I believe this situation only occurs in case a programming error that should be solved by fixing the source code of the application, rather than something one wants to catch at runtime (but there can be edge cases I don't think about ofc).

[Kangz]

We can't make it a device validation error easily as that's changing the WebGPU JS API itself that handles all of this validation on the content timeline. We could have overloads to get a failure reason, implementation logging or anything else.

[eliemichel]

All right following the JS API is important enough, no need to create an overload if there is clear enough logging :)

[kainino0x]

We introduced the concept of "implementation-defined logging", which probably happened after the resolution above. I would prefer to use that here, and simply say "if there is an error, returns null and should log an error message to an implementation-defined log"

Oh, that actually is what we said we would do, I just couldn't find it: #64 (comment)

Closing this as a duplicate of that issue.