Defining undefined on WGPULimits

[almarklein]

In #104 the WGPULimits struct was added. To specify "undefined" (i.e. the default), the value to use depends on the type:

webgpu-headers/webgpu.h

Lines 57 to 58 in 4b4dbc3

	#define WGPU_LIMIT_U32_UNDEFINED (0xffffffffUL)
	#define WGPU_LIMIT_U64_UNDEFINED (0xffffffffffffffffULL)

I suppose this is fine if your brain is wired for Rust, but my Python-brain finds this rather scary. In other words: not all code that consumes wgpu-native has a type-checker that is going to prevent setting a massive limit where the default was intended. I fear this can cause very annoying issues.

Is there still room for discussion here? Some options:

• Use zeros as undefined. For many limits zero makes no sense anyway. However, it does for some, so probably not a good idea.
• Use signed integers, and consider <0 as undefined.
• Use uin32 for all limits, it looks like wgpu-core also uses u32 for all limits. Then at least its consistent.

[Kangz]

Can't python just use None and dynamically check if the limit is None or a number? We previously had 0 mean "undefined" for various things (mip level count, row pitch, etc) but it made it difficult to map Javascript's undefined to a sensible value. So instead we use special values that should never be valid as tags that mean undefined.

[almarklein]

Yes it can, and that's what we will do. My point is that the value that I'll have to replace the None with depends on the (type of) limit and this is prone to errors. E.g. if in webgpu.h a limit is changed from u32 to u64, and I miss that, I fear I spend an evening wondering why the adapter can't satisfy the limits even though I'm specifying all defaults :)

[Kangz]

You could memset(0xFF) the limits before going through all the Python side limits and setting them if they are not None. This is mildly inconvenient on the Chromium side too but I think it's more important to be able to easily implement the JS semantics on top of WebGPU.h

[kvark]

I think this would be more convenient for all webgpu-native users if you just leave 0 where you don't care. Isn't this how we are building the rest of the C-facing API? @austinEng has this been considered in #104 ?

[almarklein]

Isn't this how we are building the rest of the C-facing API?

Also see #77

[austinEng]

Yes, I considered 0, but the rest of the C API is using values like: WGPU_MIP_LEVEL_COUNT_UNDEFINED, WGPU_ARRAY_LAYER_COUNT_UNDEFINED, WGPU_WHOLE_SIZE

[kainino0x]

webgpu.h meeting (nov 2):

We decided we should keep this as-is. We've already decided we're not going to be able to have zero-init as the default for structs and we'll instead have init macros (#158)

Zero in particular is used in wgpu for certain cases of limits not being supported (e.g. no compute -> compute limits are 0) and it's likely we'll use that in the standard in the future too.

• KN: UNDEFINED is used to say “no request for this limit” (use the default)
• CF: How does defaulting work in compat?
• RM: In wgpu-native we
• ………………………… Kai stopped taking notes sorry
  • discussion about defaulting, whether we should change them all to 64-bit like in the JS API, whether there’s a way to define a constant “-1” that works in both places
  • KN: If we ever add a float/double limit, JS API is going to probably just change the type from record<string, u64> to record<string, double>
  • KN: I need to check if Chrome is correctly handling the case where you ask for a limit >2^32 on a 32-bit limit
• Two favorite solutions
  • Change all of the fields to u64 so there’s just one UNDEFINED
    • Won’t work if we ever add a float/double limit
    • Types won’t match with the way you use them (e.g. maxTextureDimension2D won’t be the same type as a texture dimension)
    • Could change all to double, but that problem still applies
  • Leave as is, it’s fine, we’re likely to end up needing more types anyway
• conclusion: Leave as is