Add wrappers for VK_KHR_video{,_encode,_decode}_queue

[colinmarc]

Closes #722, closes #916

I've been using these via internal wrappers for a good bit.

One downside (or is it a feature?) of the new impl crate::khr::video_decode_queue::Instance pattern is that I can't keep the wrappers in my project if I want to upgrade :) EDIT: Stale observation, resolved below :)

[MarijnS95]

Before looking, how is this supposed to compare to #916? That PR has a not-insignificant amount of basic review comments, and has stalled since.

When a PR is opened, and is supposed to supersede another PR, I expect a little attribution documenting what this PR does better than the old PR. I.e. more specifically, can I assume that all of the review comments there have been resolved in this PR, and won't need to be commented on again (e.g. because it was developed in isolation from that PR)?

[MarijnS95]

This PR is unfortunately forward in some places, but backwards in other places compared to !916. Please stick to the style used in other parts of the ash code-base, and take extra care when dealing with "returned" slices of structures containing pNext chains: the user should be able to set those before calling into the helper.

[MarijnS95]

And don't forget a changelog entry 😰

[MarijnS95]

One downside (or is it a feature?) of the new impl crate::khr::video_decode_queue::Instance pattern is that I can't keep the wrappers in my project if I want to upgrade :)

What is this supposed to mean? I don't think anything is "new" here besides the struct Instance being autogenerated, and having a restructured module hierarchy. impl blocks for types were always allowed in arbitrary modules, as long as those impl blocks live within the same crate.

No clue what kind of upgrade you are anticipating: if these wrappers are merged to ash, and make it into a release, you can remove them from your project?

[colinmarc]

What is this supposed to mean? I don't think anything is "new" here besides the struct Instance being autogenerated, and having a restructured module hierarchy. impl blocks for types were always allowed in arbitrary modules, as long as those impl blocks live within the same crate.

I'm just pointing to the fact that the wrappers have to live inside ash if they want to follow that pattern - it's not possible to impl the definition outside in some other crate, as you correctly point out. My linked in-tree wrapper was using the old pattern, or at least I thought it was, and the change in pattern prompted me to PR this instead of keeping it in-tree. Please don't read too much into it, it was just an observation.

[MarijnS95]

I'm just pointing to the fact that the wrappers have to live inside ash if they want to follow that pattern - it's not possible to impl the definition outside in some other crate, as you correctly point out. My linked in-tree wrapper was using the old pattern, or at least I thought it was, and the change in pattern prompted me to PR this instead of keeping it in-tree. Please don't read too much into it, it was just an observation.

The pattern is identical. You could still define your own struct VideoQueueExt, using the same members or using ash::khr::video_queue::Device as its sole member with a Deref to be able to call the wrapper functions inside ash.

Defining impl on foreign types has never been supported by Rust, and is not something that has been changed by whatever "new' extension pattern you are referring to.

[colinmarc]

I think I got all your comments except the FnMut change to read_into_uninitialized_vector.

Defining impl on foreign types has never been supported by Rust, and is not something that has been changed by whatever "new' extension pattern you are referring to.

I'm sorry if I stepped on your toes somehow - please consider the observation retracted.

When a PR is opened, and is supposed to supersede another PR, I expect a little attribution documenting what this PR does better than the old PR. I.e. more specifically, can I assume that all of the review comments there have been resolved in this PR, and won't need to be commented on again (e.g. because it was developed in isolation from that PR)?

To be completely honest, I glanced at #916, but it didn't seem far enough along to work off of. This code came from a wrapper internal to my project, which I wrote before #916 existed. I understand that you don't want to review the ~same code twice, but if that's the case then feel free to just close this.

[colinmarc]

Ugh, I forgot that I split this into multiple commits last night - I've just been amending the last. I will clean it up, one sec.

[MarijnS95]

Defining impl on foreign types has never been supported by Rust, and is not something that has been changed by whatever "new' extension pattern you are referring to.

I'm sorry if I stepped on your toes somehow - please consider the observation retracted.

Okay. If there's something wrong with the ash API, note that I do need to understand the issue and the scope of it in case there is something we are doing wrong or could do better. I still don't understand your request/observation, so I cannot help (other than refuting statements in hopes of better understanding the point of contention).

---

To be completely honest, I glanced at #916, but it didn't seem far enough along to work off of.

That's the kind of information I'd like to see in a PR description. That way I know I don't have to directly correlate the review comments and confirm they were addressed as requested, for example. On the other hand, knowing that you would have looked at those review comments on a stale PR, and tried hard to preclude them from your PR in the first place, is a huge bonus.

This code came from a wrapper internal to my project, which I wrote before #916 existed.

All fine if you wrote the code before #916 existed, just wanted to know if you updated/modified the code before making this PR which happened after #916 existed (and was hard to miss given that it was mentioned in #722).

I understand that you don't want to review the ~same code twice, but if that's the case then feel free to just close this.

At least we actually made progress in this PR nice and quickly, and this looks all set to be merged before the next ash Release 🎉

Ugh, I forgot that I split this into multiple commits last night - I've just been amending the last. I will clean it up, one sec.

Don't worry, we'll probably end up squash-merging this as we do with any PR.

[colinmarc]

Okay. If there's something wrong with the ash API, note that I do need to understand the issue and the scope of it in case there is something we are doing wrong or could do better. I still don't understand your request/observation, so I cannot help (other than refuting statements in hopes of better understanding the point of contention).

Nothing is wrong with the ash API. I was being lazy and keeping the Video*QueueExt wrapper internal to my project rather than upstreaming it. The confusion stems from this:

The pattern is identical. You could still define your own struct VideoQueueExt, using the same members or using ash::khr::video_queue::Device as its sole member with a Deref to be able to call the wrapper functions inside ash.

I didn't know that - I didn't have a deep understanding of what bits are codegen and what are manual and how they interact, and I had previously built my internal wrapper by copy/pasting ash code and tweaking the signatures. :)

Because the struct definition moved into codegen and implementing foreign structs is illegal, it didn't work anymore to just copy/paste and tweak the signatures. Thus, the observation that the change made it impossible to write external wrappers. In actuality, it is still very possible, you just have to actually know how it works.

No clue what kind of upgrade you are anticipating: if these wrappers are merged to ash, and make it into a release, you can remove them from your project?

I also have no idea what I meant by upgrade when I wrote that 48 hours ago 😅

[MarijnS95]

My gripe with this API was forcing the caller to initialize the byte-slice. &mut [MaybeUninit<u8>] seems more fitting, and it allows callers to pass Vec::spare_capacity_mut() directly after reserving enough capacity.

[colinmarc]

Looks like there's also a new helper for that: MaybeUninit::uninit_array

[MarijnS95]

I wouldn't call it new: I've been waiting for years for those helpers to stabilize 😅. Likewise for slice_assume_init_*(), and slice_as_mut_ptr() to replace the cast below.

[MarijnS95]

I hate giving repeated "changes requested" reviews like this (it's a common source of editor/submitter fatigue), but I just keep spotting new things that I either missed, or weren't there before the last pushes...

Happy to accept-changes / resolve them myself though! Seems to be mostly copy-paste typos while attempting to replicate constructs from other files.

[MarijnS95]

I am happy with this, just need some more time to think about get_encoded_video_session_parameters_len().

I guess that's where the len naming comes from. And as we discussed, this is the variant that could also be used to query just feedback_info and optionally have the length around. That function name (in hindsight) sits a bit weird with me.

One alternative is having just ``get_encoded_video_session_parameters(), which takes both out` and `feedback_info` as `Option`, and unconditionally returns the length?

That length should be useless to the caller if they gave us a Some() slice in out, because we'll still validate the length for them.

And utilizing an unsafe implementation of the yet-unstable slice_assume_init_*(), we could return their Option<&mut [u8]> back to them, signifying that it was initialized.

[colinmarc]

I hate giving repeated "changes requested" reviews like this (it's a common source of editor/submitter fatigue), but I just keep spotting new things that I either missed, or weren't there before the last pushes...

Happy to accept-changes / resolve them myself though! Seems to be mostly copy-paste typos while attempting to replicate constructs from other files.

I get the desire to have the codebase consistent, no worries. Sorry about all the copy pasta.

Are there plans to codegen more of this stuff? That would obviously help with the consistency.

[MarijnS95]

Are there plans to codegen more of this stuff? That would obviously help with the consistency.

There is (see open issues) but as you've hopefully noticed by the abundance of (requested) consistency yet subtle differences all over the place, you probably understand that this is hard.