All of the current instances of writing info values from `Vec`s involve
building an iterator and then collecting it specifically for writing.
By using an `ExactSizeIterator`, we can avoid the need for allocating in
these cases.
v2: use existing `CLInfoValue::write_iter()` instead of custom type
Reviewed-by: @LingMan
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34389>
v2: separate from using type aliases based on signature and reorder
v3: verify validity in two additional locations
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34167>
The old way was quite annoying as it required to create a Vec to even get
the size of the result causing needless computations.
This also meant that copying into the result buffer always required to go
through a byte Vec even though we could just do the copy directly.
The main idea here is that instead of returning the result, we simply call
into a write function giving us more flexibility here.
Potentially this will also allow us to add overloads for Iterators or to
even use closures in case the size calculation is cheaper than creating
the value just to get the size.
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32268>
The old impl used `get_arc` which internally calls into
`Arc::increment_strong_count` in order to protect against Arc::drop
deallocating our objects. We could also just not do that :)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27376>
Cross vendor is bogus because of modifier screw ups. We could allow it on
all devices from the same vendor, but for that we have to check if the
supported modifiers match.
Also verify the device in questions actually supports gl_sharing.
Fixes: 57dfc013a6 ("rusticl: Add functions to create CL ctxs from GL, and also to query them")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Antonio Gomes <antoniospg100@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26051>
This happens so the XyzCB names can be used for structs containing both the function pointer and
the provided user data. Since these aliases represent raw unsafe function pointers the `Func`
prefix was chosen over `Fn`, which is generally used for safe functions.
Unfortunately it is not possible to concatinate identifiers to create new ones without a proc macro.
Thus, specify the new alias manually instead of generating them from the existing XyzCB names.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25669>
This drops quite a lot of boilerplate code as this is now all generated
via our proc macros.
Signed-off-by: Karol Herbst <git@karolherbst.de>
Reviewed by Nora Allen <blackcatgames@protonmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23413>
