It is to avoid integer overflows and to catch bogus allocations (e.g.,
the guest driver encodes an uninitialized value).
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Using a pointer for fs_info in the shader key is not really that useful
because the contents of the structure can change even though the pointer
remains the same, and the pointer can be different when the contents are
the same.
Fixes 5f488ed00d
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
With GLES we always set the correct binding if dual source blend
is disabled, with OpenGL we still have to do this to handle outputs
that might be optimized away.
v2: Fix comment (Yiwei Zhang)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
This is a fix for segfault issue, because of usage of uninitialized
vkQueue handle.
Spec [1] states that vkGetDeviceQueue must only be used to get queues
that were created with the flags parameter of VkDeviceQueueCreateInfo
set to zero. To get queues that were created with a non-zero flags
parameter use vkGetDeviceQueue2.
The problem that in case queue was created with flags set to zero following
vkGetDeviceQueue2 call will fail. By failing I mean that pQueue set to NULL,
which later leads to segfault.
This problem was also reported by vulkan validation layer:
vkr: vkGetDeviceQueue2: value of pQueueInfo->flags must not be 0. The Vulkan
spec states: flags must not be 0
(https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkDeviceQueueInfo2-flags-requiredbitmask)
[1]: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkGetDeviceQueue.html
Signed-off-by: Andrii Pauk <Andrii.Pauk@opensynergy.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Clean up the code a bit and only try to read the primitive type for
point mode if the prev shader really exists.
This fixes a VM crash when running the GLES 3.1 cts.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>
If we always emit the glip distance in GS we might end up
having too many outputs, which will result in failures.
Hence, for GS only emit the clip distance evaluation code
when the clip planes are enabled.
Fixes: 072f30955b
shader: Always write code to toggle clip plane
Closes: #254
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Italo Nicola <italonicola@collabora.com>
If we receive a link command without a VS or FS, just early exit to
avoid doing extra work.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This is to prepare for extension cleanup and autogen.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
If we come from link_shader it may be possible that no VS or no FS are
defined, because the guest uses a legacy contexts and the missing shaders
will only be defined at draw time. So drop the warning, it is already
written from vrend_draw_vbo where it is actually relevant.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
With the link_shader command we might end up calculating shader keys
without the full draw info being available, specifically, without the
vertex element array being defined. Skip querying the integer masks in
this case.
v2: Fix extra line (Yiwei)
Fixes: #664
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
To work around a Mali bug, which does not like waitAll to be false when
the fence is external.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
This fixes an issue where a shader would be emitted using
EXT_clip_cull_distance even if the host didn't support the extension.
Fixes 072f30955b
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Use virgl_resource_get_size to fill the size so that supported classic
3d resource can have a valid size as well.
This change also links venus .clang-format into server and proxy.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
This adds get_size to the virgl_resource_pipe_callbacks with a
vrend_pipe_resource_get_size for vrend.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
The old implementation of vrend_add_formats used to check color readback
format even if a depth buffer is bound. As no texture is attached to the
color buffer for such a FBO, it makes glGetIntegerv with
GL_IMPLEMENTATION_COLOR_READ_TYPE fail, and the error can trigger the
GL_NO_ERROR assertion in the function.
Check only if the depth buffer can be read in such a case.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
We lose the "proxy: " prefix, but we can live with it.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Also add a test to check the integer underflow.
Closes: #251
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
v2: Also check that no depth != 1 has been send when none is due
Closes: #250
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
This shader key field is only used if logic ops are enabled, so we can
gain a little bit of performance by avoid unnecessary recompilation
here.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Recording the uid from the fragment shader seems unnecessary when we
already track most of the information through vars_info.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This prevents shader recompilation when the guest only wants to
enable/disable clip plane in a compatibility profile. Can improve
performance if many shaders have to be recompiled because of this,
which happens in some games like Portal 2.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This prevents shader recompilation when the guest wants to enable/disable
alpha test. Can make a performance difference when lots of fragment
shaders suddenly have to be recompiled only because the application
called `glEnable(GL_ALPHA_TEST)`.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
When the flag is set, a render server is started and each vkr context is
replaced by a proxy context.
It does not apply to vrend contexts. There is no plan to support vrend
contexts either currently.
This also extends virgl_renderer_callbacks with a new callback. The
idea is to allow the client to start the render server externally. It
can be used to sandbox the render server, or is required when the client
process is sandboxed and cannot fork/exec/socketpair.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
A proxy context is a virgl_context that forwards context method calls to
a remote process.
On virgl_renderer_init, it starts the render server and connects to it.
On each virgl_renderer_context_create, it requests the render server to
fork a context process such that it can forward context method calls to
the context process.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
When a blob resource is created with
VIRGL_RENDERER_BLOB_FLAG_USE_CROSS_DEVICE, it can be exported to foreign
devices.
This provides the opposite direction. When a foreign device allocates a
cross-device resource, virgl_renderer_resource_import_blob imports the
resource into virglrenderer.
This is similar to virgl_renderer_resource_import_eglimage, but is more
generic and is for blob resources.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
It makes no difference, but is slightly nicer when combined with
https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/501
where queue_id can be 0.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Return a memfd/shm when a blob resource of blob id 0 is exported. This
becomes a part of the venus protocol.
This aims to replace the use of VIRGL_RENDERER_BLOB_MEM_GUEST in venus.
There are two reasons. One is that VIRGL_RENDERER_BLOB_MEM_GUEST cannot
be shared and does not work when we add a render server (unless a
udmabuf is created from iov). The other is that it gives us a logically
contiguous mapping. We can stop dealing with iov.
Another option is achieve the same purposes is to introduce
VIRGL_RENDERER_BLOB_MEM_HOST2D. That is more generic, but requires
changes to virtio-gpu spec and to the kernel.
Yet another option is to add a new Vulkan object, VkShmemMESA, and
commands to create/destroy the object. Then we can use a non-zero blob
id to export to the Vulkan object. But that feels like an overkill
because all we need to allocate a shmem is its size, which is already
given.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
A resource can be bound to the encoder or to a ring. We must unbind on
resource detach.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
We would like to track which resource is bound to the encoder.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
It simply gets iov from virgl_resource. No real change yet.
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 a blob resource to be backed by a mmap()-able fd.
Internally, it is a memfd or a shm.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
We will need it to allocate a mmapable fd.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
COPY_TRANSFER3D was designed to handle transfers
to host. This patch is making it possible to use
this CCMD in both directions.
If guest would like to have this data available
immediately, then it should encode, flush and wait on
the guest side.
The data is copied from host to iovec attached to resource.
In most cases resource is a staging buffer.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Only non-import path is affected by this fallback:
- drop the export info since the fd type can only be dma_buf here
- allocate gbm bo and export a fd for import as external memory
- track the gbm bo in vkr_device_memory
- vkr_context_get_blob exports fd from the bo and we destroy bo here
- vkr_device_memory_release ensures the gbm bo gets destroyed
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Currently we do the below:
1. Open one render node fd per renderer process
2. Track gbm_device pointer per vkr_physical_device
The main reason is that the fallback path requiring the gbm_device
does not use drm render node for physical device.
Later we might:
1. Figure out render nodes for different physical devices
2. Open render node and create gbm_device per vkr_physical_device
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Ryan Neph
Chia-I Wu
Italo Nicola
Gert Wollny
Andrii Pauk
Yiwei Zhang
Yonggang Luo
Akihiko Odaki
mwezdeck