or silence warnings depending on the compiler settings.

Fixes: 9c5ca936 ("proxy: add proxy_context_resource helpers")

Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>

Andrii Pauk authored 3 years ago and Chia-I Wu committed 3 years ago

This is required for support of untyped resources on virtio
devices which create their own egl context.

Currently untyped resources support is reported to mesa only in case
virglrenderer creates it's own egl context from scratch. The problem
that this context is not "sharable" with device context and if it's
created vrend uses it instead of context callbacks implemented by device.
Thus such approach is not suitable for devices with it's own egl context.

The only thing that is required for untyped resources support is
initialized eglDisplay handle that is requried for eglCreateImageKHR,
thus add callback for device to share it.

Untyped resources feature support is required for sharing vkr resources
with vrend.

Signed-off-by: Oleksandr.Gabrylchuk <Oleksandr.Gabrylchuk@opensynergy.com>
Signed-off-by: Andrii Pauk <Andrii.Pauk@opensynergy.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>

This is mostly a naming change, along with more docs

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>

The ring cmd can come earlier than render server receiving the shmem
after removing redundant guest side roundtrips.

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>

server needs to persist the resource and attach to workaround a guest
kernel out-of-order map and attach cmds.

proxy needs to track and de-dup the attach request for the attached
resources.

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>

The same res_id is also used for later resource attach of the same.

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>

It will be used by the proxy context.

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>

map_info might fail to be initialized if get_map_info failed.

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>

This is dedicated heap memory allocations approach.

This type of blob should be used in the following way:
1) Guest virtio-gpu driver on start checks for dedicated memory region.
2) On create_blob drm ioctl guest driver reserves chunk of required memory and
send it to host using sg list. Heap is managed on guest.
3) Device creates dmabuf fd from this sg entry and sends it to virglrenderer on
create_blob virtio-gpu command. Blob is created using
virgl_renderer_resource_import_blob call.
4) On next vkAllocateMemory call from mesa, virglrenderer will allocate vk memory
handle from this dmabuf fd. It will receive resource id in
VK_STRUCTURE_TYPE_IMPORT_MEMORY_RESOURCE_INFO_MESA vkAllocateMemory structure.

The flow is opposite to the way it's done for HOST_3D types of blob, where
vkAllocateMemory is called first, vk memory is allocated from random host place.
Then create_blob is called, where dmabuf fd is exported from VkDeviceMemory.

Signed-off-by: Andrii Pauk <Andrii.Pauk@opensynergy.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>

This is some leftover from the get_blob_done cleanup.

Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>

Improves the error handling code that deals with resource
deallocation.

Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>

Dispatches for the following commands are implemented:

- vkCmdBindVertexBuffers2
- vkCmdSetCullMode
- vkCmdSetDepthBoundsTestEnable
- vkCmdSetDepthCompareOp
- vkCmdSetDepthTestEnable
- vkCmdSetDepthWriteEnable
- vkCmdSetFrontFace
- vkCmdSetPrimitiveTopology
- vkCmdSetScissorWithCount
- vkCmdSetStencilOp
- vkCmdSetStencilTestEnable
- vkCmdSetViewportWithCount

Signed-off-by: Omar Akkila <omar.akkila@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>

No functional change but it should better to be explicit.

Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>

This only updates venus-protocol.  There is no visible functional
difference.

Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>

vkr_extension_table allows us to fine-control which extensions are
advertised.

To support an extension, we need venus-protocol support and vkr support.
One is generated and one is open-coded.  We don't want to advertise an
extension automatically whenever an updated venus-protocol includes it.

Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>

We do not want to advertise 1.3 when we only support 1.2.

Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>

Temporarily disable the old CI configuration file and replace it with
the one belonging to the reworked CI infrastructure.

The project CI/CD settings should be updated in order to switch
'CI/CD configuration file' from 'ci/.gitlab-ci.yml' to the default
'.gitlab-ci.yml', for consistency with Mesa CI.

Note the 'ci/' folder becomes obsolete in favor of '.gitlab-ci/' and
could be removed once all needed functionality has been migrated to the
new setup.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>

Add initial support for reusing the Mesa CI infrastructure.

Note this doesn't conflict with the old CI since it doesn't share the
'ci/' folder, but instead uses '.gitlab-ci/', which makes the new setup
consistent with Mesa CI.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>

It is to avoid integer overflows and to catch bogus allocations (e.g.,
the guest driver encodes an uninitialized value).

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>

Log fatal errors internally generated by vkr_cs.

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>

v2: vrend_print need '\n' (Yiwei)

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>

Italo Nicola authored 3 years ago and Gert Wollny committed 3 years ago

Using a pointer for fs_info in the shader key is not really that useful
because the contents of the structure can change even though the pointer
remains the same, and the pointer can be different when the contents are
the same.

Fixes 5f488ed0

Signed-off-by: Italo Nicola <italonicola@collabora.com>
Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>

With GLES we always set the correct binding if dual source blend
is disabled, with OpenGL we still have to do this to handle outputs
that might be optimized away.

v2: Fix comment (Yiwei Zhang)

Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>

This is a fix for segfault issue, because of usage of uninitialized
vkQueue handle.

Spec [1] states that vkGetDeviceQueue must only be used to get queues
that were created with the flags parameter of VkDeviceQueueCreateInfo
set to zero. To get queues that were created with a non-zero flags
parameter use vkGetDeviceQueue2.

The problem that in case queue was created with flags set to zero following
vkGetDeviceQueue2 call will fail. By failing I mean that pQueue set to NULL,
which later leads to segfault.

This problem was also reported by vulkan validation layer:

vkr: vkGetDeviceQueue2: value of pQueueInfo->flags must not be 0. The Vulkan
spec states: flags must not be 0
(https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-VkDeviceQueueInfo2-flags-requiredbitmask)

[1]: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkGetDeviceQueue.html



Signed-off-by: Andrii Pauk <Andrii.Pauk@opensynergy.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>

Clean up the code a bit and only try to read the primitive type for
point mode if the prev shader really exists.

This fixes a VM crash when running the GLES 3.1 cts.

Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>

Gert Wollny authored 3 years ago and Gert Wollny committed 3 years ago

Fixes a compile error:

   vrend_compile_shader: context error reported 7 "deqp-gles31" Illegal shader 0
   shader failed to compile

   0:3(33): error: GL_ARB_gpu_shader5 invocations qualifier specified

   1: #version 150
   2: #extension GL_ARB_shader_bit_encoding : require
   3: layout(triangles, invocations = 2) in;
   4: layout(points, max_vertices = 3) out;
   ...

Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: John Bates <jbates@chromium.org>

Gert Wollny authored 3 years ago and Gert Wollny committed 3 years ago

If we always emit the glip distance in GS we might end up
having too many outputs, which will result in failures.

Hence, for GS only emit the clip distance evaluation code
when the clip planes are enabled.

Fixes: 072f3095
    shader: Always write code to toggle clip plane

Closes: #254
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Italo Nicola <italonicola@collabora.com>

Italo Nicola authored 3 years ago and Gert Wollny committed 3 years ago

If we receive a link command without a VS or FS, just early exit to
avoid doing extra work.

Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>

No more confusing zombie processes.

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>

Now that render_worker_jail tracks workers, the apis are simplified such
that

 - render_worker_create forks a subprocess
 - render_worker_destroy kills a subprocess
 - render_worker_jail_reap_workers reaps all exited subprocesses

Also add render_worker_jail_detach_workers that can be called by a
forked subprocess to "detach" (free without killing/reaping) workers.

v2: replace some checks for worker->{destroyed,reaped} by asserts (Ryan)

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> (v1)
Reviewed-by: Ryan Neph <ryanneph@google.com> (v1)

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>

It contains only struct minijail, but we plan to add more fields to it.

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>