There is no valid reason for the guest to pass bad resource ids.
Because resource creation failures are not propagated back to the guest,
they are the most common reason for the guest to pass bad resource ids.
When that happens, failing earlier makes things easier to debug.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
It is an env var that vkr uses to set the debug flags. Currently, the
only flag is VKR_DEBUG_VALIDATE that enables the validation layer.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
This is a debug knob that, when set, will enable the validation layer.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
This looks like a copy-paste error. For desktop GL it is
disabled here, so on GLES this should probably be the same.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
clang-format insists on using .clang-format. This commit adds
docs/vkr-clang-format as a doc. To use it,
$ cd src
$ ln -sf ../docs/vkr-clang-format .clang-format
$ clang-format -style file -i vkr_*
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This field was introduced 2 months ago and it breaks virgl
compatibility between guest/host. Switch the new added field
to the end. We will still have compatibility issue but the
"bug window" is much smaller.
Fixes: 7e7a4e7 ("vrend: Introudce VIRGL_CAP_V2_VIDEO_MEMORY to query video memory")
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Add support for external memory fd properties query and import
- vkGetMemoryResourcePropertiesMESA
- VkImportMemoryResourceInfoMESA
- VkMemoryResourcePropertiesMESA
This is a huge commit because it also includes the change which splits
the headers by handle types.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
GL_TEXTURE_MIN/MAG_FILTER expects an enum value, to be set with
glTexParameteri() (integer value) instead of glTexParameterf() (float
value).
Closes#212
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
A vrend_context structure contains a current vrend_sub_context, which
in turn keeps references on various resources like textures, VBOs,
index buffers, etc. which are used for actual drawing operations.
Certain actions can change the current sub-context in use.
There is a split of what resources are cleaned up directly as part of
a context destruction and which are handled by the sub-context
destruction. VBOs, while referenced by sub-contexts, are cleaned up by
the context. To do that, it uses the at the time of destruction
current sub-context to access these. As a result, only the VBOs in the
active sub-context are cleaned up; every other sub-context referenced
by the context will keep references to the VBOs used.
The responsibility of VBO dereferencing is moved to the destruction of
the sub-context, so all VBOs, not just the one from the current
sub-context, are dereferenced during the destruction of a context.
Closes#198
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Fix
[DEBUG:rutabaga_gfx/src/virgl_renderer.rs:104]
GL_IMPLEMENTATION_COLOR_READ_FORMAT is not expected native format 0x80e1 != imp 0x0
with crosvm introduced by commit d9aad06ba2 (vrend: Create frame
buffer object in do_readpixels). We can do the warning check only after
an fb with read buffer is bound.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Make it clear that they are implicit between submit_cmd and
resource_busy_wait.
implicit_fence_submitted is (fence_id - 1) so this change is slightly
more than renaming.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
There is never a need to wait for the GPU works (if any) involved in
resource creation. A client commonly does
VCMD_SUBMIT_CMD
VCMD_RESOURCE_CREATE2(dummy)
...
VCMD_RESOURCE_BUSY_WAIT(dummy)
only because VCMD_RESOURCE_BUSY_WAIT needs a resource. We don't need a
fence for resource creation.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Let VTEST_FUZZER_FENCES control whether VCMD_RESOURCE_BUSY_WAIT waits or
not. Fences are always created.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
It gives clients access to virgl_renderer_resource_create_blob and
virgl_renderer_resource_export_blob.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Protocol version 3 uses server-generated, rather than client-generated,
resource ids. Without that, clients could pick conflicting resource
ids.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
VCMD_RESOURCE_CREATE and VCMD_RESOURCE_CREATE2 use and return
server-generated ids since version 3. The client id must be 0.
This makes the commands work more like linux's
DRM_IOCTL_VIRTGPU_RESOURCE_CREATE.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This paves the way for a protcol change where the server will
generate resource ids. This also improves our error handling by
switching from FREE to vtest_unref_resource.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Add VIRGL_RENDERER_VENUS and the related bits.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
In addition to virgl_renderer_submit_cmd, vkr_ring can also be used to
submit commands.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
On 64-bit builds, we can store uint64_t keys in pointers directly and
there is no need to malloc/free.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
util_hash_table_u64 is a wrapper to util_hash_table with uint64_t
keys. This is similar to hash_table_u64 in mesa.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
chenjiangnan
Chia-I Wu
Yiwei Zhang
Gert Wollny
Lepton Wu
Robert Wetzel
Leo