Like in vrend_renderer_transfer_internal, virgl_gbm_transfer is a
special path that is generally preferred. However, a copy transfer
can be a synchronized transfer. We don't want to use GBM in that
case.
v2: add a comment on glFinish
v3: use GBM only when VIRGL_TEXTURE_NEED_SWIZZLE is set
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Acked-by: Gurchetan Singh <gurchetansingh@chromium.org>
Gbm-resources can be used for data blobs. These are created with a
height of 1 and the required width, which can easily exceed the maximum
supported texture width.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Mesa emulates planar format sampling with per-plane samplers. With this
change, the guest can pass the plane index when creating a sampler view
from a virgl resource to create a per-plane sampler view. The index can
be passed in place of the texture layer, as that will always be 0 for
planar images.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Lepton Wu <lepton@chromium.org>
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>
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>
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>
Turns out some files managed to have a mix between 2, 3, 4 and tabs for
indenting. The only way to really fix this was to do just a single commit
that fixes all of them.
Acked-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
For the same glmark2 "build" test, perf reports about half
instructions.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The idea is to have a unix socket and possible shmem protocol
between a renderering server and local gallium sw driver.
This could be used to validate virgl without qemu with piglit.
Chia-I Wu
David Stevens
Gurchetan Singh
Jakob Bornecrantz
Marc-André Lureau
Dave Airlie
Dave Airlie