We've got bug reports with
vkr: vkExecuteCommandStreamsMESA resulted in CS error
and nothing else.
As far as I can tell, the decoder, the encoder, and vn_dispatch_command
all log on CS errors. The problem should be in
vkr_dispatch_vkExecuteCommandStreamsMESA. Make
vkr_dispatch_vkExecuteCommandStreamsMESA chatty as well.
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/722>
VIRGL_BIND_PREFER_EMULATED_BGRA macro was removed when
the old BGRA emulation was removed, but that makes src/virgl_hw.h
incompatible with Mesa, which still has a reference to the macro.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/716>
Apply the same logic as done in commit 08e7afd116 for
the input as we also need to take the indirect output into account.
Fixes running these two dEQP tests:
dEQP-GLES2.functional.shaders.indexing.varying_array.vec4_static_loop_write_static_loop_read
dEQP-GLES2.functional.shaders.indexing.uniform_array.vec4_static_read_vertex
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
v2: * update logic for when to use gbm transfers and send
another caparbility flag to the guest about which
formats can be read back from
* Add comment about GBM logic (John)
v3: * Only enable gbm readback for scanout textures, and signal
the guest when gbm is used, so that it can use stageing
texture transfers in this case.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
minigbm allocations being enabled does not imply that GBM is also
initialized, e.g. if the renderer uses a GLX context, so don't try
to dereference gbm.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>
This is the changes automatically generated from the venus-protocol
repository.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>
Currently the read_from_host code path is not implemented
for this configuration.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Use a more recent Mesa Git revision & pipeline ID.
Additionally, update the expectation files accordingly.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Since crosvm is not able to properly handle parallel tests due to a
concurrency bottleneck, it's necessary to ensuring scaling at the host
system level by increasing the number of active crosvm instances.
For dEQP testing this can be easily accomplished by using the Deqp
Suite support in deqp-runner and adding the crosvm wrapper script in
the related '*.toml' files.
For piglit this is currently not supported in piglit-runner, but
something similar could be added later. For the moment we use an
increased number of parallel jobs to speed-up the execution.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Those files were initially imported from Mesa CI project, but they are
not actually needed. Hence drop them.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Because the tests run using the Mesa CI infrastructure, the results
folder is created in a Mesa project specific location and it is
necessary to move it to CI_PROJECT_DIR once completed.
This operation has been performed only for the vtest based jobs, hence
let's ensure it is always executed.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Fix the expectation files for all virtio-gpu jobs and enable them in the
CI pipeline.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
This also fixes size parameter of glMapBufferRange in
vrend_draw_bind_vertex_legacy.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
A vertex attribute array can affect the selection of the program.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
With that we can enable PIPE_CAP_TGSI_TEXCOORD in the guest
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
With the NTT code path in the guest we might end up with
the generic array outputs also with GS and TES.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Make sure that the condition for which we are emitting the uniform
corresponds to the one in the iter_declaration function.
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Allows virglrenderer-venus to passthrough the VK_EXT_4444_formats
extension to the venus client.
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>
When we first convert a tgsi shader into TGSL, we fill the shader key
with a value of `(gs|tcs|tes)_present` based on the currently bound
shaders. But since a shader is always going to be bound if it's being
used, we should already assume that it is going to be present in the
shader key, saving a recompilation.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
It is not valid to link a program that has a TCS but no TES, therefore
we shouldn't attempt to pre-link this combination of shaders.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Currently, we always use the `tfout` variables when writing TF output
for geometry shaders, but only declare them under specific conditions,
causing GLSL errors in tests like ``
Fixes: 9157dcbca0
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
It's better done in proxy than in vkr.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
This is required for support of untyped resources on virtio
devices which create their own egl context.
Currently untyped resources support is reported to mesa only in case
virglrenderer creates it's own egl context from scratch. The problem
that this context is not "sharable" with device context and if it's
created vrend uses it instead of context callbacks implemented by device.
Thus such approach is not suitable for devices with it's own egl context.
The only thing that is required for untyped resources support is
initialized eglDisplay handle that is requried for eglCreateImageKHR,
thus add callback for device to share it.
Untyped resources feature support is required for sharing vkr resources
with vrend.
Signed-off-by: Oleksandr.Gabrylchuk <Oleksandr.Gabrylchuk@opensynergy.com>
Signed-off-by: Andrii Pauk <Andrii.Pauk@opensynergy.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
This is mostly a naming change, along with more docs
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
The ring cmd can come earlier than render server receiving the shmem
after removing redundant guest side roundtrips.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
server needs to persist the resource and attach to workaround a guest
kernel out-of-order map and attach cmds.
proxy needs to track and de-dup the attach request for the attached
resources.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
The same res_id is also used for later resource attach of the same.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
It will be used by the proxy context.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
This is dedicated heap memory allocations approach.
This type of blob should be used in the following way:
1) Guest virtio-gpu driver on start checks for dedicated memory region.
2) On create_blob drm ioctl guest driver reserves chunk of required memory and
send it to host using sg list. Heap is managed on guest.
3) Device creates dmabuf fd from this sg entry and sends it to virglrenderer on
create_blob virtio-gpu command. Blob is created using
virgl_renderer_resource_import_blob call.
4) On next vkAllocateMemory call from mesa, virglrenderer will allocate vk memory
handle from this dmabuf fd. It will receive resource id in
VK_STRUCTURE_TYPE_IMPORT_MEMORY_RESOURCE_INFO_MESA vkAllocateMemory structure.
The flow is opposite to the way it's done for HOST_3D types of blob, where
vkAllocateMemory is called first, vk memory is allocated from random host place.
Then create_blob is called, where dmabuf fd is exported from VkDeviceMemory.
Signed-off-by: Andrii Pauk <Andrii.Pauk@opensynergy.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Chia-I Wu
Yiwei Zhang
Akihiko Odaki
Corentin Noël
Gert Wollny
Yonggang Luo
Igor Torrente
Cristian Ciocaltea
Italo Nicola
Ryan Neph
Andrii Pauk