Remove iov from vrend_renderer_resource_create and make a separate
call to virgl_renderer_resource_attach_iov. In practice, this
changes nothing because iov is always NULL.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Move resource lookup up from vrend for
virgl_renderer_resource_get_info, virgl_renderer_get_cursor_data,
and virgl_renderer_get_rect.
These functions are mostly for dumb/scanout resources, and they need
information that virgl_resource does not have. I intentionally pass
pipe_resource down to vrend to emphasize that there is no
virgl_context to dispatch to and those functions can only work with
virgl_resource created from virgl_resource_create_from_pipe.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
It detaches the virgl_resource from all contexts and remove the
virgl_resource. That can be done generically.
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>
Remove the unused length argument. Remove unused
vrend_object_insert_nofree as well now that context resource
management is not built on top of vrend_object.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Do not abuse context object table to manage context resources. Add
a simpler variant, which replaces the now unused vrend_resource_*,
to manage context resources instead.
This is cleaner and more efficient because we no longer allocate a
vrend_object to manage a vrend_resource.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
In vrend_renderer_resource_create, call
virgl_resource_create_from_pipe instead of vrend_resource_insert to
manage the resource as a global virgl_resource. Convert all other
vrend_resource_* calls to the corresponding virgl_resource_* calls.
This is just the first step. Ultimately, we want vrend_context to
deal with vrend_resource exclusively.
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>
Cleanup to make it more clear what the functions are modifying.
Signed-off-by: John Bates <jbates@chromium.org>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
These formats are supported and required by GLES3. Without these
formats, guest MESA uses uncompressed formats to emulate them
while formats like GL_R16 are not available on GPU like MALI.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Previously, Mesa would remain forever blocked in read() after an error
such as failing to compile a shader.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
To keep Valgrind happy:
==3628== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
==3628== at 0x48DB431: sendmsg (sendmsg.c:28)
==3628== by 0x10C00E: vtest_create_resource2 (in /virglrenderer/build/vtest/virgl_test_server)
==3628== by 0x10AC2B: vtest_server_run (in /virglrenderer/build/vtest/virgl_test_server)
==3628== by 0x10A5B3: main (in /virglrenderer/build/vtest/virgl_test_server)
==3628== Address 0x1fff0004ef is on thread 1's stack
==3628== in frame #1, created by vtest_create_resource2 (???:)
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Fix not switching to corresponding context when deleting FBOs.
FBOs are not sharable between contexts.
Signed-off-by: Ka Ho Ng <khng300@gmail.com>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Some applications change glAlphaFunc nearly every frame.
Sam 3 apitrace replay went from ~4 fps to ~19 fps on a chromebook.
Signed-off-by: John Bates <jbates@chromium.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
If this is not set, every fork will have to rebuild the image.
This is not what we want for at least 2 reasons:
- forks are not running the CI in the same environment than the
upstream project
- this infers bandwidth costs as every fork has its own image
that needs to be pulled by every runner.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
When destroying any user context, vrend_destroy_context already
calls vrend_renderer_force_ctx_0. The manual switch to context 0 is
unnecessary.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This allows us to get rid of dec_ctx array and VREND_MAX_CTX.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
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>
Rename vrend_util.h to virgl_util.h. Add the header guard.
"vrend" is the prefix for the GL renderer code. "virgl" is the
prefix for common code.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
If we can't switch to the original context for the query objects,
don't check it.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
We convert GBM_BO_USE_TEXTURING to VIRGL_BIND_SAMPLER_VIEW at
Android side, so just convert VIRGL_BIND_SAMPLER_VIEW back to
GBM_BO_USE_TEXTURING, otherwise the allocation won't go
through gbm.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This puts the project more in line with other projects at
freedesktop.org, and most importantly improves the caching of container
images.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
This is currently only used with minigbm, and largely untested
elsewhere. This will also allow us to use flags which are not
available in Mesa GBM.
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Add --multi-clients to enable experimental multi-client support.
Note that multi-client should be enabled only when the clients know
and trust each other. This is because resources are global among
the clients. Two clients trying to create two resources with the
same id will result in an id conflict for example.
Proper multi-client support requires changes to the protocol. The
main change will be for the server to generate globally unique
resource ids and enforce access controls.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Add vtest_server_run to replace vtest_server_run_renderer. The new
function is the main loop of the server, which
- accepts new client connections
- dispatches client commands
- removes inactive clients
- lazily initi/cleanup the renderer
- optionally forks for each connection
in a single loop.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Get rid of gotos so that it will be easier when we turn
vtest_server_run_renderer into the main loop.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
We want to make vtest_server_run_renderer the main loop when we add
multi-client support. Forking for new clients will be done in the
main loop.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Call vtest_init_renderer when the client connects, instead of before
the first command. We want to make vtest_server_run_renderer the
main loop when we add multi-client support, and this makes things
simpler.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Refactor command dispatching to a separate function,
vtest_client_dispatch_commands.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-By: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Gurchetan Singh <gurchetansingh@chromium.org>
Chia-I Wu
John Bates
Lepton Wu
Tomeu Vizoso
Ka Ho Ng
Benjamin Tissoires
Gert Wollny
Gurchetan Singh
Elie Tournier