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>
To query the size and number of levels we have to obtain the
sampler as source for the size query, but also the index for
the emulated level lookup, so default to always obtaining the
right sampler, and add a special case for obtaining the sampler
index.
v2: - Fix possible endless loop (John)
- Use the sampler source index to find find the real index
v3: Make loop easier to read, and rename variables (John)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>
On OpenGL all textures can be read back using glGetTexture. On GLES
we have to be able to bind the texture to an FBO to use glReadPixels,
and only a few formats are supported as destination formats.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>
Note that it is also possible to draw just one instance with
start_intance larger than zero, and one must call
glDrawElementsInstancedBaseVertexBaseInstance
or
glDrawArraysInstancedBaseInstance
in this case.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>
Sometimes we receive FS shaders where some output was optimized away.
In this case we have to set the output locations explicitly, but it is
no problem if we always do this. On GL this can always be done by using
glBindFragDataLocationIndexed, it is supported since at least GL 3.3,
and the alternative, setting the layouts in the shader, requires the same
OpenGL. On GLES we have to emit explict locations if EXT_blend_func_extended
is not supported. This fises rendering of "The Long Dark".
v2: - Emit EXT_blend_func_extended in FS if extension is available
since this is required when not emitting the explicit locations
(Robert Wenzel)
- call glBindFragDataLocationIndexedEXT on GLES because that's what the
extension requires
v3: use sizoef(buf) instead of hard-coding size (John)
Related: #223
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: maksym.wezdecki@collabora.com (v2)
Reviewed-by: John Bates <jbates@chromium.org>
A shader that writes only depth will have num_outputs > 0, but since
there are no color outputs, we must not add the swizzling.
This fixes silicon city on GLES/crosvm
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>
This should help debugging shader compilation errors.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>
Fixes: f50c878d61
vrend: factor out preparing the blit info
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>
Since we can't properly resolve the depth buffer, we have to use one
samole, so use the sample 0 and not a random value from tc.z.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>.
The extension declaration must come before the precision definition, and
in GLES we have to emit the OES extension instead of the ARB extension.
Fixes pihlit :
spec/arb_get_texture_sub_image/arb_get_texture_sub_image-cubemap
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Corentin Noël <corentin.noel@collabora.com>.
Italo Nicola
Corentin Noël
Chia-I Wu
mwezdeck
Yiwei Zhang
Antonio Caggiano
Yurii Danilovskyi
Gert Wollny