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>
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>
Context lookup should happen in virglrenderer.c such that we can
dispatch through the context callbacks. Being able to get rid of
vrend_lookup_renderer_ctx (context lookup inside vrend) is
significant.
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>
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>
Per-plane sampler views don't require texture views, so move where that
check is performed when creating sampler views. Also, it's not
necessarily the case that a planar resource's egl image can be reused
for the first plane's sampler view, so just always create and use a
dedicated per-plane egl image.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
When switching context, if we want to use shared objects from previous
context, we need to insert glWaitSync to make sure the GL commands
are executed in sequences. This fixes 8 dEQP tests on mali:
dEQP-GLES2.functional.texture.mipmap.2d.generate.a8_fastest
dEQP-GLES2.functional.texture.mipmap.2d.generate.a8_nicest
dEQP-GLES2.functional.texture.mipmap.cube.generate.a8_fastest
dEQP-GLES2.functional.texture.mipmap.cube.generate.a8_nicest
dEQP-GLES2.functional.texture.specification.basic_copyteximage2d.2d_rgb
dEQP-GLES2.functional.texture.specification.basic_copyteximage2d.cube_rgb
dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.2d_rgb
dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.cube_rgb
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
With the prior patch and without this one, I get
../src/.libs/libvrend.a(vrend_renderer.o): In function `vrend_format_can_scanout':
src/vrend_renderer.c:703: undefined reference to `gbm'
src/vrend_renderer.c:703: undefined reference to `gbm
src/vrend_renderer.c:706: undefined reference to `gbm'
../src/.libs/libvrend.a(vrend_renderer.o): In function `vrend_resource_gbm_init':
/virglrenderer/src/vrend_renderer.c:6337: undefined reference to `gbm'
/virglrenderer/src/vrend_renderer.c:6337: undefined reference to `gbm'
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
It's a bit misleading currently. For example, all resources have
guest memory associated with them, and resource can be both a GL
texture and GBM buffer at the same time. Use bits to more accurately
capture this.
No functional change.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Get rid of now useless type casts too.
Fixes#121
v2: rebase to remove type casts that were newly introduced in master
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This change makes sure that gbm functions are properly guarded by
ENABLE_GBM_ALLOCATION, to prevent build failures when the gbm headers
aren't included.
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>
The function is used from vrend_renderer.c, so it also should be
part of the libvrend.la conveniance library. This requires that the
CONTEXT enums and the variable egl are also part of this library.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This change makes a set of changes to increase the range of gbm-based
resources that can be allocated:
- Add VIRGL_BIND_LINEAR to support linear gbm allocations.
- Relax the bind flag argument check if VIRGL_BIND_SHARED or
VIRGL_BIND_LINEAR is set.
- For resources allocated from gbm, only try to create an image if one
of the render target or sampler view bind flags is set.
- Don't try to calculate the internal image format for external images.
This change also fixes a use-after-free that could occur if external
image creation failed.
Signed-off-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@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>
With vtest this swizzling is necessary, but with qemu it is not, so make
it a tweak.
v2: Use original blit format to check the format type in blitter
v3: Correct typo (Gurchetan)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Chia-I Wu
Gurchetan Singh
Elie Tournier
Tomeu Vizoso
David Stevens
Lepton Wu
Gert Wollny
David Stevens