uif is now defined. util_is_power_of_two is replaced by other variants.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
No visible API change.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Now that vkr_ring supports iov, we can allow larger rings. This also
adjusts VKR_RING_BUFFER_MAX_SIZE to be realistic.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
vkr_ring_read_buffer now supports reading from a ring buffer that is on
top of iov. It is overly complex though.
For further optimization and simplication, we should consider requiring
a logically contiguous virgl_resource. Possible options are requiring a
physically contiguous guest memory (this can have other use cases) or
requiring a host VkDeviceMemory (already doable, but meh).
We also use the chance to replace size_t by uint32_t in
vkr_ring_read_buffer. No functional difference.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
It cannot exceed UINT32_MAX because the ring head and tail are 32-bit.
util_is_power_of_two also truncates to 32-bit.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
It is used to access the extra region, with iov support.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
It is used to access the buffer region. No iov support yet.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
It is used to access the control region, with iov support.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
We want to access its iov directly from vkr_ring.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
They are easier to work with when we support iov_count > 1.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
The only functional difference should be that vkr_region_is_aligned
checks both begin and end.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
I need to work with ring regions in more places, and need helper
functions. vkr_region uses {begin, end}, which seems easier to work
with than {offset, size}.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
It initializes and validates a ring layout, replacing
validate_ring_layout.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
VkDrmFormatModifierPropertiesListEXT::drmFormatModifierCount may be used
uninitialized. It is a codegen bug but a proper fix breaks the
protocol. Until we are ready to finalize the protocol, let's work
around it.
It works so far because Mesa calls the function twice in a row. In the
first call, pDrmFormatModifierProperties is NULL and the uninitialized
value is not used. Instead, it is initialized by the host driver.
In the second call, because of how the temp pool works, the memory gets
reused and the "uninitialized value" is already initialized. Thanks
goes to Yiwei for figuring this out.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
There is no need to validate string sizes as they are only encoded in
one place, unlike with other dynamic arrays.
We don't validate string sizes when they are non-zero already. This fixes the
decoder to not validate when they are 0.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
These are marked noautovalidity="true" in vk.xml and the decoder does
not validate them. There are more incidents, but for the others, we
will let VVL do its job. Reported by Yiwei.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
The decoder gained dynamic array size validation in commit 92b083bb
("vkr: validate array sizes and string lengths") but failed for one
case: fooCount != 0 and pFoo is NULL. This commit fixes that.
Fixes: 0690ad0b ("vkr: remove some manual NULL checks")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
We finally have dev readily available to be passed to
vkr_device_add_object.
Let vkr_device_remove_object call list_del as well.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
They are more flexible than the removed {CREATE,DESTORY}_OBJECT. We can
use them for VkDeviceMemory.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Define two more helper functions and call the helper functions directly.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Expand the macro at the call sites because it is short enough.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Expand the macro at the call sites because it is short enough.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
The macro defines a type-safe cast function. Define one for every
object.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Add macros to define helper functions. Update ALLOCATE_POOL_OBJECTS and
FREE_POOL_OBJECTS to use the helper functions.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Generate helper functions. Update CREATE_OBJECT and DESTROY_OBJECT to
use the helper functions.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
They just have some #includes currently.
v2: removed vkCreateRenderPass2 as a variant
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
This allows us to use vkr_context_alloc_object.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
A helper function that loads the id from the handle automatically.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
A helper function that asserts.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
While crosvm gets the legit debug name from the guest kernel, it does
not pass it to virglrenderer. We prefer the instance name anyway.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Remember it as the instance name.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Ensure all ring control member variables have their own storage during
ring creation. Member address re-use would otherwise result in undefined
behavior.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Tracking offset+size together for each ring control variable makes extra
upcoming layout validation simpler.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
When VKR_RENDERER_ASYNC_FENCE_CB is not set, we destroy the VkFence at
device destruction and move the queue syncs to the ctx so that they can
get retired and freed in the next retire_fences call.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Refactored queue syncs retire on destroy into vkr_queue_retire_all_syncs
and rename vkr_queue_retire_syncs to vkr_queue_get_signaled_syncs.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
It is covered by vkr_cs_decoder_lookup_object.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
The decoder makes sure the command buffer pointer is non-NULL since
0f12c460 ("vkr: make sure the first dispatchable handle is non-NULL").
And vkr_cs_decoder_lookup_object is just fixed to validate the object
type.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
The decoder makes sure the device pointer is non-NULL since 0f12c460
("vkr: make sure the first dispatchable handle is non-NULL"). And
vkr_cs_decoder_lookup_object is just fixed to validate the object type.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
The decoder makes sure the physical device pointer is non-NULL since
0f12c460 ("vkr: make sure the first dispatchable handle is non-NULL").
And vkr_cs_decoder_lookup_object is just fixed to validate the object
type.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Chia-I Wu
Yiwei Zhang
Ryan Neph