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>
Fix the following 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>
While adding support to llvmpipe for GL 4.00 a bunch of virgl tests
started to fail, this should fix one of the cases
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
This is better so we can dump same shader multiple times.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Fix potential truncations caught by the compiler, such as
../src/vrend_shader.c:2395:82: warning: ‘%s’ directive output may be truncated writing up to 127 bytes into a region of size between 86 and 213 [-Wformat-truncation=]
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Increase the size of full_op. Use ARRAY_SIZE to get the buffer
sizes. This fixes
../src/vrend_shader.c:2069:25: warning: ‘%s’ directive output may be truncated writing up to 63 bytes into a region of size between 62 and 125 [-Wformat-truncation=]
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Fix void* arithmetic and extra semicolon. -Wno-overlength-strings
is for large_frag in large_shader.h.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
../src/virgl_gbm.c:186:13: warning: ‘virgl_gbm_transfer_internal’ defined but not used [-Wunused-function]
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
In c20a5a9, I move some unused results files in the archived folder
but I didn't correctly fix the path of the softpipe results.
Softpipe is the driver used for the ci so its results file wasn't archived.
Fixes: c20a5a9 "ci: move outdated results to an archived folder"
Signed-off-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@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>
We should honor info->offset and info->layer_stride. This brings
virgl_gbm_transfer closer to
vrend_renderer_transfer_{write,send}_iov.
minigbm has a bug and never sets info->offset. The bug went
unnoticed before virgl_gbm_transfer was added. I suppose fixing
virgl_gbm_transfer now should not suddenly make the bug
user-visible.
v2: With virgl_gbm_transfer, we added planar YUV support that was
not available before. We have to make a special case for YUV to not
regress minigbm.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: David Riley <davidriley@chromium.org> (v1)
Tested-by: David Riley <davidriley@chromium.org> (v1)
Acked-by: Gurchetan Singh <gurchetansingh@chromium.org>
When a stride is given, validate it against the box width, not the
bo width.
This mirrors what check_iov_bounds does.
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>
amdgpu, llvmpipe and i915 are not used by the freedesktop ci and
didn't see any update for at least 6 months.
Signed-off-by: Elie Tournier <elie.tournier@collabora.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
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>
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>
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>
Dave Airlie
Elie Tournier
Gurchetan Singh
Lepton Wu
Chia-I Wu
John Bates
Tomeu Vizoso
Ka Ho Ng
Benjamin Tissoires