It's desirable to query or modify virgl_renderer state for various values.
We've done it for resources (virgl_renderer_get_fd_for_texture /
virgl_renderer_get_fd_for_texture2 / virgl_renderer_resource_get_info) a
few times, but more parameters are often desired.
Let's define a protocol instead. That way, more queries/operations (is "ctx
{num} lost?", "is x host feature supported?") can be formulated.
It's also possible to put the protocol in virgl_hw.h, so in theory
the guest can recieve a response directly from virglrenderer. Any
opinions on this?
v2: virgl_renderer_query --> virgl_renderer_execute
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
It's good to tell the guest about these formats.
v2: move this check with the rest of the v2 caps
remove host version check bump (@kusma)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Certain 2D allocations will take the GBM path if the option
is set.
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
We don't want to open the vgem or pvr drivers.
v2: return fd as-is as well (@davidriley)
v3: order of loops (@davidriley)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
virgl_renderer_transfer_write_iov doesn't work for YUV buffers, since
it's based on glTexSubImage.
We assume the YUV image is not disjoint, since that's currently what
Mesa gbm supports.
For RGBA buffers, this will also eliminate a copy in the cases
where the gbm_bo_map(..) implementation doesn't use a shadow buffer
[i915, mediatek, rockchip].
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
These formats can be allocated by gbm implementations.
v2: fix test (not needed on i965, maybe on softpipe)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
It's possible to EGL images from any dmabuf. Currently, gbm-based
dma-bufs are supported.
v2: 39 attributes --> 37 attributes (@davidriley)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Use case: allocate buffers from gbm, import into EGL, and pass to the
display to reduce copies.
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
It is possible to open rendernodes when using EGL_MESA_platform_surfaceless.
v2: fail if user-provided fd fails (@davidriley)
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
These extensions allow for multi-plane images and modifiers, and
are more widely supported than EGL_MESA_drm_image or EGL_MESA_image_dma_buf_export.
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
Just a cleanup -- no functional changes.
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
vrend_clear executes the Gallium clear command which is only called
when the whole viewport is cleared. So far mesa was doing excessive checks
on the scissors, thereby updating the scissors to framebuffer size when they
were disabled, and the according state changes were transmitted to the host.
With mesa/2037478 this was optimized away, so that not disabling the scissors
in the clear command manifested itself as a regression in a number of tests.
Keeping track of the scissor state in the hardware and disabling the scissors
before the clear is executes, and re-enabling them according to the last state
fixes this.
Closes#116
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
virglrenderer doesn't know with which parameters the external
image was created, so it doesn't make sense to emulate it.
This fixes Portal, HL2 etc. not going past the loading screen
in Crostini.
Reviewed-by: David Riley <davidriley@chromium.org>
Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
ARM platforms such as Mali might not support Mesa surfaceless platform
so fall back to using a default display.
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
ARM GL stacks might not support these extensions, and if buffers
are not being exported since they're being imported from externally
created buffers, then these are not necessary.
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
ARM platforms may only advertise GLES 2.0 configurations.
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Instead of setting the depth range values directly just mark the viewport
as dirty and update the state later together with the other viewport
properties. This fixes some issues with the depth clamp emulation and
geometry shaders.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
With thie new version we can enable the depth clamp emulation in the
guest.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This is needed for emulating GL_ARB/EXT_DEPTH_CLAMP on GLES hosts that
don't support it.
Related #108
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The value is only supported for GL >= 3.2 or GLES >= 3.0, on earlier versions
assume the minimum required number.
Closes#113
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The GLES test suites have a rather long run time, so split the runs
for the differeent GLES versions.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>-ne
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>.
A few fixes landed in softpipe so update the results accordingly
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>-ne
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>.
The latest mesa master needs 2.4.99 because of amdgpu
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>-ne
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>.
It seems that some bash versions don't see beyond one "" block when
setting the parameter for the -c command line flag.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>-ne
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>.
When running locally and with softpipe and the hardware driver then one
would sometimes pickup the nam of a temporary file. Make sure to set the
test file name always.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>-ne
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>.
When run locally it might make sense to override this value.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>-ne
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>.
There are more instances where the sampler view and the texture are not
in the same context. So do more un-binding of textures after they were
used.
Related: #112
Signed-off-by: Gert Wollny's avatarGert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
If nr_samples is 1 we allocate textures as MULTISAMPLE, so we also need to handle
the textures in later use as a multisample texture. In addition, on GLES blits to
a multisample texture are not allowed as target, and we must use the GL blit
fallback for all texture types.
v2: Correct more checks including the one in check_resource_valid (Gurchetan)
v3: Also update the tests to use only 0 for no samples and >= 1 for samples
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The variables are already explicitly initialized.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Currently we use a mix of "", {} and {0}. Use a single approach across
the board.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
For guests that support this interface this:
Fixes#91Fixes#94
v2: (whole series) Switch from string interface to integer values
for tweaks (Gurchetan).
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
By default emulate GL_SAMPLES_PASSED by using GL_ANY_SAMPLES_PASSED
and return the value 1024 if any sample has passed. Also add a tweak so
one can set this number to a different value.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
v2: fix use of bindings vs. flags
v3: correct typo (Gurchetan) fb55a453
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
With vtest this swizzling is necessary, but with qemu it is not, so make
it a tweak.
v2: Use original blit format to check the format type in blitter
v3: Correct typo (Gurchetan)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
On GLES B8G8R8A8_SRGB is not available and B8G8R8A8_UNORM can not be
created as immutable. In order to have versions of these formats that
can be created immutable on GLES provide the formats R8G8B8A8_SRGB and
_UNORM with swizzling to BGRA that can then be used instead of the BGRA
formats. Since this may break things these swizzled versions will later
be only enabled when the guest requests them.
v2: Check the base swizzled BGRA format only on GL
v3: Correct type in method name (Gurchetan)
v4: Add PREFER_EMULATED_BRGA to according format binding flags (Gurchetan)
v5: Add comment about formats nou to be used in the guest (Gurchetan)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This is useful for logging a continuation on the same line.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Gert Wollny
Gurchetan Singh
David Riley
Emil Velikov