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.
Chia-I Wu
Marc-André Lureau
Gurchetan Singh
Jakob Bornecrantz
Marc-André Lureau
Dave Airlie
Dave Airlie