Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move some existing enums into block 0x0001 #420

Closed
kainino0x opened this issue Nov 14, 2024 · 8 comments
Closed

Move some existing enums into block 0x0001 #420

kainino0x opened this issue Nov 14, 2024 · 8 comments
Assignees

Comments

@kainino0x
Copy link
Collaborator

kainino0x commented Nov 14, 2024

For #214, we need to move some things into block 0x0001. Filing separately because I forgot about it when it was part of that issue.

  • WGPUSType
    • SurfaceSource*
    • ShaderSourceSPIRV probably
    • ShaderSourceWGSL?? [1]
    • SurfaceColorManagement? [1]
  • WGPUPredefinedColorSpace? [1]
  • WGPUToneMappingMode? [1]

Not sure how the codegen will work for this, but see #417 for a first attempt.

@kainino0x kainino0x added the has resolution Issue is resolved, just needs to be done label Nov 14, 2024
@kainino0x kainino0x added the !discuss Needs discussion (at meeting or online) label Nov 15, 2024
@kainino0x
Copy link
Collaborator Author

kainino0x commented Nov 15, 2024

[1] I'm not really sure whether [SurfaceColorManagement, WGPUPredefinedColorSpace, WGPUToneMappingMode] should be in block 0x0000 or 0x0001. They are not "C-specific" which is the currently-written definition of block 0x0001, but they are optional if we don't require all implementations to implement them. Maybe we should change the definition of block 0x0001.

@Kangz
Copy link
Collaborator

Kangz commented Nov 15, 2024

Aren't they native-specific though? As in they wouldn't be exposed in the Web ever?

@kainino0x
Copy link
Collaborator Author

My note [1] is specifically about SurfaceColorManagement, WGPUPredefinedColorSpace, and WGPUToneMappingMode (edited above) which are always exposed on web and (I'm proposing) may not be implemented in non-web. I think it makes sense to somehow separate required-but-post-1.0 extensions from optional extensions, though it's not really necessary.

@kainino0x kainino0x removed the has resolution Issue is resolved, just needs to be done label Nov 27, 2024
@kainino0x kainino0x removed the !discuss Needs discussion (at meeting or online) label Dec 12, 2024
@kainino0x
Copy link
Collaborator Author

Dec 12 meeting:

  • KN: What should be the exact definition of block 0x0001? First we said "multi-implementation native" and then we said "multi-implementation C-specific" but I would like to propose that it should be generally all "multi-implementation" extensions (i.e. any enum value not required to be understood by an implementation).
  • CF: Think that's fine. Don't think we should get too deep into how to define block 1. Just "Not base spec".
  • Agreed

@kainino0x kainino0x self-assigned this Dec 12, 2024
@kainino0x
Copy link
Collaborator Author

Writing out all of the current extension structs to make sure I know what block they belong in:

  • WGPURenderPassMaxDrawCount: 0x0000
  • WGPUShaderSourceWGSL: 0x0000
  • WGPUShaderSourceSPIRV: 0x0001 ?? because it's presumably optional but let's discuss briefly
  • WGPUSurfaceColorManagement: 0x0001
  • WGPUSurfaceSource{AndroidNativeWindow,MetalLayer,WaylandSurface,WindowsHWND,XCBWindow,XlibWindow}: 0x0001

@kainino0x kainino0x added the !discuss Needs discussion (at meeting or online) label Dec 19, 2024
@kainino0x
Copy link
Collaborator Author

Dec 19 meeting:

  • KN: If block 0x0000 is "core" i.e. "required to implement" then I think WGPUShaderSourceSPIRV should be in block 0x0001, "non-core extension", i.e. "optional to implement". Presumably WGPUShaderSourceWGSL is block 0x0000 though.
  • CF/LK: Sounds good.

@kainino0x kainino0x removed the !discuss Needs discussion (at meeting or online) label Dec 21, 2024
@kainino0x
Copy link
Collaborator Author

Kinda sorta blocked on #490. If we decide to just merge block 1 into block 0 it will be a lot easier because I won't have to rework the generator to allow multiple block numbers in one file, which it currently can't do.

@kainino0x
Copy link
Collaborator Author

kainino0x commented Jan 11, 2025

This has been scrapped, because in #490 we're merging block 1 into block 0. Block 1 won't exist anymore.

@kainino0x kainino0x closed this as not planned Won't fix, can't repro, duplicate, stale Jan 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants