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

Timestamps need to be in nanoseconds #3741

Closed
Wumpf opened this issue May 1, 2023 · 6 comments
Closed

Timestamps need to be in nanoseconds #3741

Wumpf opened this issue May 1, 2023 · 6 comments
Labels
area: api Issues related to API surface type: enhancement New feature or request

Comments

@Wumpf
Copy link
Member

Wumpf commented May 1, 2023

Timestamp values are supposed to represent nanosecond values, see https://gpuweb.github.io/gpuweb/#timestamp
Meaning that get_timestamp_period has to go.
Instead, wgpu-core needs to add a compute shader that converts timestamps with a previously acquired tick->ns ratio upon query resolve. See also gpuweb/gpuweb#1325 (comment)

Related to

@cwfitzgerald
Copy link
Member

I'm honestly not convinced that this is something we should require this on native. We need the functionality in wgpu-core so moz can implement it for WebGPU, but on native, "compute shader injection" isn't going to sit terribly well with our users.

@cwfitzgerald
Copy link
Member

To note - this get_timestamp_period was specifically designed to work fine with the WebGPU model as well while giving us a overhead free version on native (webgpu always reports 1).

Honestly I don't get why the committee settled on this rather silly (imo) design.

@Wumpf
Copy link
Member Author

Wumpf commented May 1, 2023

Oh I see, though this is just an artifact of how things developed over time.
I'm also not happy with the commitee decision on this one, but it also doesn't sit right with me that only for native one needs to use the value - this means that wgpu interface has a more relaxed spec than the WebGPU spec. Sure it has a lot of "extras" via native features, but this feels different to me as it actually changes the meaning of a value from the interface depending on whether you run on web native. Essentially putting a lil dent into portability.

Isn't this also an issue for correctly implementing the webgpu native header correctly?
Mozilla may implement this as a layer over query resolve, but it's not great either.

Not a hill I'll die on as I wouldn't want to volunteer for that compute shader either 😄

@cwfitzgerald
Copy link
Member

No matter what, wgpu-core needs to implement this in resolve, if only for the needs of firefox and maybe wgpu-native.

I'm basically of the mind where if there is an api we can design that allows our native users to not have to suffer the consequences of interesting WebGPU decisions, I'd much rather see that then us just fully copy WebGPU.

@teoxoy teoxoy added type: enhancement New feature or request area: api Issues related to API surface labels Jun 1, 2023
@Diggsey
Copy link
Contributor

Diggsey commented Jun 1, 2023

My terminology might be a bit out of date, but when creating a device users could request what timestamp period to use, with two options, "Native" or "Nanosecond". If the user requests "Nanosecond" then "get_timestamp_period" would be guaranteed to return 1.

@Wumpf
Copy link
Member Author

Wumpf commented Jul 23, 2023

thought about this again and agreeing with @cwfitzgerald . Updating comment on get_timestamp_period in #3636 a little bit

@Wumpf Wumpf closed this as not planned Won't fix, can't repro, duplicate, stale Jul 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: api Issues related to API surface type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants