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>
Add a new command associated to glLinkProgram. With this we should be
able to compile and link shaders when requested by the user.
Together with the command we expect an array of shader handles attached
to the program, where each position of the array corresponds to a pipe
shader type.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Simplify info parameter by replacing it with vertices_per_patch.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
If resource created from egl image we don't need to attach iov to it.
Therefore we don't need to do transfer iov to/from host for those
resources.
Signed-off-by: Yurii Danilovskyi <glyd@opensynergy.com>
Reviewed-by: maksym.wezdecki@collabora.com
Add a helper to return the previous struct of the found struct with
input sType. This is useful for swapping a struct with something else.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by Ryan Neph <ryanneph@google.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Since we use GLES or the GL core profile on the host, the
alpha formats will not be available anyway, so just emulate
them right away, this helps to fix more piglits from
bin/arb_texture_buffer_object-formats fs arb
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: maksym.wezdecki@collabora.com
The swizzling didn't take into account that the destination might
actually only read a few components or just one, so that the
applied swizzling could even become invalid because code like
dest.z = vec4(dest.z.x, dest.z.y.dest.z.z. dest.z.w)
could be created. The check for when to apply the swizzling was also
not correct because the two values compared came from different
name-spaces.
To fix this, just check whether the TEXTURE_NEEDS_SWIZZLE is set,
and when loweing in the shader, take only the components into account
that are actually written.
This also needs a fix for the alpha-format override to add the
TEXTURE_NEEDS_SWIZZLE flag.
Finally take the shader type into account when checking the number
of sampler views.
v2: Correct the shader code to apply the swizzling (Maksym)
v3: Fix formatting (Maksym)
Fixes: 29c6b9177541f189ebed5158a432b21d0d82211
vrend: apply format swizzling during GLSL generation
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: maksym.wezdecki@collabora.com
This is needed for modern games that require more than 16 samplers.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>
Yiwei Zhang
Akihiko Odaki
Chia-I Wu
Gert Wollny
Italo Nicola
Corentin Noël
mwezdeck
Antonio Caggiano
Yurii Danilovskyi