Add vrend_renderer_prepare_reset, and move context/resource table
cleanups, to the beginning of the fini/reset functions.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
We want a centralized place to initialize different subsystems (vrend,
winsys, resource/context tables). This is the first step.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
I am not sure what the check in vrend_renderer_init was previously for.
This gives it some sense.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
It is a wrapper for virgl_egl_get_fourcc_for_texture.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Move and rename it to vrend_winsys_has_gl_colorspace.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Move winsys-related includes and globals to the new files.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
If host support dual_src_blend extension, it's possible we need
to call glBindFragDataLocationIndexed to set fragment output location.
We can't explicitly set it in GLSL in such cases.
Fixes: b17ba74 ("shader: Add layout qualifier to fragment shader outputs")
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
Currently, even the input/output buffers are integer formats, we still
use float type for them. This is actually undefined behavior and MALI
GPU will do type conversion and cause unexpected results. To fix this,
we check the input buffer format for vertex shader and also color buffer
format for fragment shader, if they are integer types, just use integer
types in generated shaders. Since the old way works fine on other GPU,
only enable this fix for ARM MALI for now. The plan is to enable this
for other GPU also with auto detection.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This is useful when we need an fd from a virgl_resource.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Capset ids belong to virgl_hw.h. Mesa uses magic numbers right now
and can be fixed with this change.
Capset ids are also leaked in virtio_gpu.h, for use with
virgl_renderer_get_cap_set by qemu. We should replace
virgl_renderer_get_cap_set by something that enumerates all capsets
to stop the leaking, but that is another story.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The intention is to warn the users, not to inconvenience ourselves.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The plan is to remove the patch step and generate the correct glsl
from the beginning. As the first step, just move the patch step to
where we create glsl.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This make sure we have a valid framebuffer in current context.
Some GPU driver like MALI is buggy and will crash on glEndQuery with targets
like GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN if no valid framebuffer in
current context.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
In case GL_ARB_buffer_storage is available, use that.
If not, attempt to allocate a dma-buf and import it into GL.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This is to tell virglrenderer that blob resources used with
the 3d driver must be able represented as file descriptors.
This affects the availability of certain features.
Suggested-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Acked-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
For non-exportable memory, add map/unmap.
For additional validation, query virglrenderer about the preferred
caching type. The response will be returned in to the guest
in virtio_gpu_resp_map_info.
Acked-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
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>
I don't see the point why we want to use context0 to do transfer.
If we always use original context to do transfer, then we can
avoid sync between contexts for mobile GPU.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
If the next shader stage doesn't declare an input block,
we should not emit an output block in the current stage.
Fix the remaining compilation issue when using the GLES backend.
error: redeclaration of gl_PerVertex must be a subset of the built-in members of gl_PerVertex
Signed-off-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
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>
When a context is destroyed, all its queries are destroyed with
vrend_destroy_query_object and removed from
vrend_state.waiting_query_list. vrend_query::ctx is never dangling.
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 to virglrenderer for
vrend_renderer_export_query. Now that the last user of
vrend_renderer_res_lookup is gone, we can remove the helper.
After this change, it becomes clear that vrend deals with
vrend_resource mostly. The only exceptions are the
virgl_context::{attach_resource,detach_resource,transfer_3d}
callbacks.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Add vrend_renderer_export_query for the vrend-specific code and move
the rest 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_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>
We want to move resource lookup up from vrend to virglrenderer for
transfers. Depending on whether ctx_id is specified, we need to
pass a virgl_resource or a pipe_resource down. Let's move handle
out of vrend_transfer_info first.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Add and use virgl_resource_{attach,detach}_iov.
When the iov of a virgl_resource is changed, we should in theory
notify all contexts where the virgl_resource has been attached to.
But because we plan to move to immutable iov for other renderers,
only vrend contexts need to be notified. And because vrend contexts
use vrend_resource and refcount, we only need to update
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>
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>
Chia-I Wu
Lepton Wu
Gurchetan Singh
Elie Tournier