-
Notifications
You must be signed in to change notification settings - Fork 345
GPUExternalTexture: API for video; WGSL type and functions #1666
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
Conversation
Kangz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
| 1. [=Queue a microtask=] to set |result|.{{GPUExternalTexture/[[destroyed]]}} to `true`, | ||
| releasing the underlying resource. | ||
|
|
||
| Issue: Is this too restrictive? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe? We should probably discuss it in the group as a follow-up. An option would be to add a retained: boolean to the descriptor that would make that micro-task not enqueued but could have additional cost (like an extra copy to decouple the lifetime of the texture).
dneto0
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know enough about this subject, but looks good overall.
I have minor feedback.
spec/index.bs
Outdated
| The provided `sampler` is used to sample any underlying texture(s). | ||
| If there is one RGBA underlying texture, this behaves as usual. | ||
| If there are several underlying textures (Y+U+V or Y+UV), the sampler is used to sample each | ||
| underlying texture separately, prior to conversion from YUV to RGBA or luminance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We previously discussed leaving things open to allow implementations to still filter after conversion (if they wanted to), but the API surface in this PR doesn't allow it: the sampling parameters are baked into the sampler object, so they can't be passed in through the external texture's metadata UBO. Hence I've written the result down here concretely.
But if we DO want post-conversion filtering to be possible with 0-copy YUV sources, we should change the API to allow this somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the post-conversion filtering can still be done with sampler with the same amount of work as when you don't have a sampler:
- Take the fractional and integer parts of the texture coordinates (after multiplication by the texture size)
- Sample the square starting at integer part with the sampler
- Mix using the fractional part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But how do you know whether to use linear or nearest filtering? I don't think the shader can introspect that info from a sampler object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yeah that makes sense. If we wanted to allow that we would need to add the sampler to extrenal_texture creation.
|
I have removed the luminance overloads in this PR, to be followed up on. Items that need to be raised in the WGSL group (can be discussed in office hours and then written down in this proposal for review):
|
502b1cc to
318f11d
Compare
318f11d to
b36cafb
Compare
13adfee to
a2cee13
Compare
a2cee13 to
d0dd2e4
Compare
|
Apologies for the churn (force push), I wanted to detangle the various changes (and merge-from-main commit). After some work on the color spaces, this is ready again. There will be a followup to resolve some |
|
From the office hour:
|
|
It occurs to me that one extra global sampler would be needed to sample a LUT with appropriate filtering. |
403d86d to
b1e33ac
Compare
b1e33ac to
4858a00
Compare
|
I've split out some other changes. This PR is now just for the last commit. |
|
Resolution:
|
| for sampling 3D LUTs. | ||
| - for *each* external texture, one sampled texture binding for each plane, | ||
| one sampled texture binding for a 3D LUT, and one uniform buffer binding for metadata. | ||
| - three sampled texture bindings (for up to 3 planes), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it would be easier to just give it the whole bind group
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't help for the limit because they are for the whole pipeline layout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but I wonder how the discussion goes about bind group re-creation. If we force users to re-create bind groups, we might as well just accept GPUExternalTexture instead of a bind group.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re-create bind groups when, for different external textures? I was imagining we would always use an exact number of bindings in both the bind group layout and the bind group regardless of the underlying representation, and bind dummy objects in any unused slots.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re-create every frame, according to #1666 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there's a good reason to use up, by design, an entire bind group slot for one external texture. I think there are reasonable applications that would need to bind two or more external textures (e.g. compositing a foreground canvas over a background webcam feed) but not want to use up two of their four bind groups.
e1c6271 to
762d1e0
Compare
kvark
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR looks good to me, although the whole approach still feels temporary if we get WebCodecs later on.
05e5fb9 to
53df64b
Compare
dneto0
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving the WGSL change.
The question in my mind is on the API side: if an external texture uses up multiple bindings, then how do I know what binding numbers are occupied? I presume they are in the same bindgroup.
|
I'm not precisely sure how to address this, but I think that in implementations we can hide the fact that multiple binding indices are used. IIRC in Dawn at least, we re-pack the bindings into a small range near 0 anyway, so this problem would disappear in that. However for the sake of alternate implementations we might want to reserve half of the binding index space for internal bindings, or something? |
Original PR: gpuweb#1666 Discussion: gpuweb#2124
Original PR: gpuweb#1666 Discussion: gpuweb#2124
Dependent on #1689 and #1690, see last commit only
Canvas support to follow (it has more complicated semantics).
For video external texture lifetimes, I took the most restrictive option so we can easily change it later.
I also excluded the textureSampleLuminance/textureLoadLuminance functions as they're quite difficult to define: see #1681
Based on #1415 (comment).
Fixes #1415.
Preview | Diff