It will be used by the proxy context.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
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>
Being an interface of virgl_context, this provides per-context fencing.
This is motivated by Vulkan, where each context (i.e., VkInstance) is
independent from one another. Fences submitted to difference contexts
do not signal in the order they are submitted. It is in theory and in
practice also true for OpenGL when SW/HW scheduling or context priority
is considered.
Besides being per-context, fences in Vulkan are also per-VkDevice and
per-VkQueue within a context. This interface uses an opaque uint64_t to
identify the queue a fence is submitted to, similar to how an opaque
uint64_t is used to identify a blob.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Comparing to virgl_renderer_context_create, it allows flags to be
specified. flags can only be used to specify the capset id in this
commit, but that may change in the future.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Isaac Bosompem <mrisaacb@google.com>
Add virgl_resource::map_info and return it in
virgl_renderer_resource_get_map_info.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Isaac Bosompem <mrisaacb@google.com>
Replace virgl_context::get_blob_pipe by virgl_context::get_blob,
which supports fd-based blobs. There is also optional
virgl_context::get_blob_done to give the context a chance to
associate a resource with a blob.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
A blob resource is a container for:
- VIRGL_RENDERER_BLOB_MEM_GUEST: a guest memory allocation
(referred to as a "guest-only blob resource")
- VIRGL_RENDERER_BLOB_MEM_HOST3D: a host3d memory allocation
(referred to as a "host-only blob resource")
- VIRGL_RENDERER_BLOB_MEM_HOST3D_GUEST: a guest + host3d memory allocation
(referred to as a "default blob resource").
Blob resources can be used to implement new features and fix shortcomings
with the current resource create path. The subsequent patches show how
blob resources may be leveraged to implement GL_ARB_buffer_storage
and GL4.5.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Add virgl_context::transfer_3d, and when ctx_id is specified, use
the callback.
When ctx_id is not specified, the resource is a dumb/scanout
resource and is never referenced by submit_cmd. It does not need to
go through the callback. There is no way to either.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Pass virgl_resource to virgl_context::{attach,detach}_resource.
This allows us to move virgl_resource_lookup up from vrend to
virglrenderer.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Add virgl_resource as the type of global cross-renderer resources.
A virgl_resource cannot be used in a renderer context directly.
After a virgl_resource is attached to a renderer context, a local
context object can be created from the virgl_resource. This is
known as "import". A renderer context always imports global
resources and deals with context objects exclusively.
It is also possible to create a virgl_resource from a context
object. This is known as "export". Whether import or export, the
global resource and the context object have independent lifetimes.
There is only GL renderer right now, and the context object for GL
renderer is vrend_resource. Importing from virgl_resource or
exporting to virgl_resource is a matter of increasing the refcount
of vrend_resource. It is fast but can be a bit confusing.
In the future, a virgl_resource can be from a different source
(e.g., VK renderer or an external dmabuf). Importing such a
virgl_resource as a vrend_resource will entail more works.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
It will be the base class for contexts of renderers.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Fixes
ISO C does not support ‘__FUNCTION__’ predefined identifier
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
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.
Yiwei Zhang
Chia-I Wu
Gurchetan Singh
Marc-André Lureau
Jakob Bornecrantz
Marc-André Lureau
Dave Airlie
Dave Airlie