WGPU_WHOLE_SIZE warning

20 views
Skip to first unread message

Mark Sibly

unread,
Jan 18, 2023, 3:47:57 PM1/18/23
to emscripten-discuss
Hi,

I'm getting the following warning when building an emscripten project that uses webgpu:

C:\Users\marks\dev\emsdk\upstream\emscripten\cache\sysroot/include\webgpu/webgpu.h:61:26: note: expanded from macro 'WGPU_WHOLE_SIZE'
#define WGPU_WHOLE_SIZE (0xffffffffffffffffULL)

I've fixed it be redefining WGPU_WHOLE_SIZE as:

#define WGPU_WHOLE_SIZE (size_t)(0xffffffffffffffffULL)

This appears to be working so far, but I thought I better mention it.

I'm usin emscripten 3.1.30

Bye,
Mark

Sam Clegg

unread,
Jan 18, 2023, 5:15:06 PM1/18/23
to emscripte...@googlegroups.com
Can you share the full warning message (I only see the "note" part)?  And the context in which you are using the macro?

cheers,
sam


--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/7560e498-377d-4916-8216-329faf412962n%40googlegroups.com.

Mark Sibly

unread,
Jan 18, 2023, 5:49:08 PM1/18/23
to emscripten-discuss
>Can you share the full warning message (I only see the "note" part)?  And the context in which you are using the macro?

Oops sorry, here's the full warning:

C:/Users/marks/dev/xros/window/tests/windowtest.cpp:231:33: warning: implicit conversion from 'unsigned long long' to 'size_t' (aka 'unsigned long') changes value from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
                buffer, WGPUMapMode_Write, 0, WGPU_WHOLE_SIZE,
                                              ^~~~~~~~~~~~~~~

C:\Users\marks\dev\emsdk\upstream\emscripten\cache\sysroot/include\webgpu/webgpu.h:61:26: note: expanded from macro 'WGPU_WHOLE_SIZE'
#define WGPU_WHOLE_SIZE (0xffffffffffffffffULL)

...and here's where I'm using the macro:

        WGPUBindGroupEntry bgEntry{};
        bgEntry.buffer = uniforms[eye];
        bgEntry.offset = 0;
        bgEntry.size = WGPU_WHOLE_SIZE;

..and...

    wgpuBufferMapAsync(
        buffer, WGPUMapMode_Write, 0, WGPU_WHOLE_SIZE,
        [](WGPUBufferMapAsyncStatus, void* buffer) { stagingBuffers.push_back((WGPUBuffer)buffer); }, buffer);

...and...

        wgpuRenderPassEncoderSetVertexBuffer(pass, 0, vertexBuffer, 0, WGPU_WHOLE_SIZE);

It's meant to save you having to specify buffer sizes in a few places in native dawn, although I'm not clear on exactly where it can be used.

This all works in native code, but I'm begining to think it doesn't work at all in emscripten, or at least not the same way!

Bye,
Mark

Mark Sibly

unread,
Jan 18, 2023, 5:55:06 PM1/18/23
to emscripten-discuss
Actually, after a bit more research, the original WGPU_WHOLE_SIZE macro *does* work, but may hack to get rid of the warning breaks it!

Not sure why though...

Bye,
Mark

Mark Sibly

unread,
Jan 18, 2023, 5:57:11 PM1/18/23
to emscripten-discuss
This works and gets rid of the warning:

#define WGPU_WHOLE_SIZE ~0

Sam Clegg

unread,
Jan 18, 2023, 7:14:43 PM1/18/23
to emscripte...@googlegroups.com, Kai Ninomiya
It looks like WGPU_WHOLE_SIZE is designed to be used WGPUBindGroupEntry where size is 64-bit, but wgpuBufferMapAsync uses size_t for size (which is either 32-bit ot 64-bit depending on the architecture).

I'm not sure if this is intended behaviour or not.  Perhaps its a bug?   cc'ing Kai who will know more.

On Wed, Jan 18, 2023 at 2:57 PM Mark Sibly <mark...@gmail.com> wrote:
This works and gets rid of the warning:

#define WGPU_WHOLE_SIZE ~0

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

Kai Ninomiya

unread,
Jan 18, 2023, 10:40:27 PM1/18/23
to Sam Clegg, emscripte...@googlegroups.com
Thanks for the CC! Indeed there is a type difference, hence we have two different macros and you're meant to use the other one here :)

#define WGPU_WHOLE_MAP_SIZE SIZE_MAX
#define WGPU_WHOLE_SIZE (0xffffffffffffffffULL)


This is a bit fussy, but it _is_ a C API.... In C++, things are a bit better, because they're typed:

    static constexpr size_t kWholeMapSize = WGPU_WHOLE_MAP_SIZE;
    static constexpr uint64_t kWholeSize = WGPU_WHOLE_SIZE;


We could do this in the C API but it's somewhat unidiomatic - we had someone complain about our use of static const instead of #define before.

That said we should probably consider the ~0 solution, maybe this would let us get rid of the two definitions entirely. Would you file an issue to suggest it here?

-Kai (he/they)

Kai Ninomiya

unread,
Jan 19, 2023, 8:12:27 PM1/19/23
to Mark Sibly, emscripte...@googlegroups.com
Happy to help! I think you're right about ~0 just being 32-bits and thus not the correct solution. Another possibility I've seen is -1, but this is a bit sensitive to which casts you put it through (i32 -> i64 -> u64 is ok, i32 -> u32 -> u64 is not ok). And whether you get warnings or not is sensitive to the compiler and warning options used.

-Kai (he/they)


On Wed, Jan 18, 2023 at 7:26 PM Mark Sibly <mark...@gmail.com> wrote:
Hi Kai,

Thanks for that, I'll start using the right macros!

I'm not sure ~0 is a good idea, it seems like a bit of a hack. In fact, it implies C converts 32->64 bit before converting signed->unsigned in situations where it has to do both, doesn't it? , ie: ~0u wouldn't work as you'd just end up with 0 in the upper bytes. Well, that's something new I learned today!

Bah, whatever, back to work...

Bye!
Mark


On Thu, Jan 19, 2023 at 4:07 PM Kai Ninomiya <kai...@google.com> wrote:
Forwarding directly while my message sits in the moderation queue. :)

Floh

unread,
Jan 20, 2023, 4:15:15 AM1/20/23
to emscripten-discuss
Clang and GCC have a builtin __SIZE_MAX__ macro which resolves to 32-bit or 64-bit ~0. MSVC doesn't though.

But maybe this would make sense?

#if defined(__SIZE_MAX__)
#define WGPU_WHOLE_SIZE (__SIZE_MAX__)
#else
...
#endif

Floh

unread,
Jan 20, 2023, 4:16:50 AM1/20/23
to emscripten-discuss
....ah nvm, I should read the whole thread carefully before responding :D
Reply all
Reply to author
Forward
0 new messages