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>
Pre-init virglrenderer only when tracing is disabled, otherwise perfetto
might get confused. Do a vkEnumerateInstanceExtensionProperties to
preload Vulkan ICDs.
"time for i in `seq 100`; do vulkaninfo > /dev/null; done" goes from
0m5.895s to 0m5.535s.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
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>
Inspired from the .editorconfig file of Mesa to ensure that we are using a consistent
code formating here while minimizing the need to customize the code editor when
working on virglrenderer.
Signed-off-by: Corentin Noël <corentin.noel@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>
The render server is a daemon that sits idle waiting for commands. When
requested to create a context, it forks and creates the context in a
subprocess. This isolates contexts from each other, from the server
process, and from the client process.
Because a context process can execute untrusted commands and depends on
GPU drivers, the isolation should improve the security.
There is also a multi-thread mode where each context is executed by a
thread. This mode is used to ease debugging, but maybe someone will
find a use case for it.
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>
1. the workaround is only required for host visible mem type
2. remove the def FORCE_ENABLE_DMABUF from common
3. update the docs to reflect the current assumptions
4. sanity check memory export before forcing export, which requires
extensions to be initialized before memory properties init for a
physical device
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Yiwei Zhang
Gert Wollny
Yonggang Luo
Chia-I Wu
Italo Nicola
Akihiko Odaki
Corentin Noël
mwezdeck