These warnings were detected with clang version 12.0.0.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
On GLES hosts, BGR* resources are manually swizzled to RGB* internal
format on creation and swizzled back to BGR* format on readback.
For small transfers, iovec data is directly passed to the host driver
without staging in a temp buffer first. When swizzling for BGR*
resources, this modifies the persistend iovec buffer when it should
remain in the user-provided format. So we force temp buffers for all
iovec transfers on BGR* resources on GLES hosts to fix this.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Lepton Wu <lepton@chromium.org>
It tests nothing on release builds because virgl_renderer_context_create
is not called and virgl_renderer_submit_cmd fails immediately.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-By: David Riley <davidriley@chromium.org>
This fixes the regression introduced with commit
45eb512a43e257427617699e3849ca93434c1717c and
62cc6ed6e5.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
vrend_renderer_pipe_resource_set_type() called for
VIRGL_RESOURCE_FD_DMABUF resources fail during virgl to GBM format
conversion due to an uninitialized variable.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
BGRX resources backed by EGL images are given GL_RGB8 internal format
on creation outside of virglrenderer, so we must accomodate when
creating a texture view.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Since externally-stored BGRA resource buffers must remain with
BGRA byte ordering, there are several special cases in the custom
blitter that need to be handled, based on the source and destination
resource formats, as well as the views requested on each by the caller.
This change gives the caller more control over the swizzling operation
to perform during the shader-based blit, so the caller can reconcile the
special cases more concisely.
Fixes#225
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
BGRA resources that use external storage (EGL image, GBM)
must keep the data store in the BGRA byte-order, while
producing the correct results when used within the host's
GL or GLES API. To maintain compatability of BGRA resources
with features such as gamma correction, texture views, and
multisampled rendering, virglrenderer swizzles BGRA texture
data to RGBA and passes GL_RGBA to the host API, then swizzles
the RGBA data back to BGRA on readout.
With external storage, virglrenderer no longer has complete
control over buffer accesses, with the possibility that buffers
will be written to and read out by other processes, such as the
display compositor. Under these circumstances, we need to emulate
the external buffer format when using it with the host rendering
API such that data is accessed from the backing buffer as RGBA
and written back as BGRA.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Some virgl_formats rely on the same GL internal format. In such cases,
texture views during blits are unnecessary.
Also, avoid generating a GL texture handle unless a view is created.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
When performing blits, a texture view is not necessary if the
base format and view format of either the source or dest
resource are equal. with this change, unnecessary views will
be avoided on the source and destination resources.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Once we know the GL shader-based blitter is needed, there's no need
test remaining conditions.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Removing tweaks could cause wire format inconsistencies between host
and guest. Instead, just mark these two tweaks as non-functional in
log output and ignore their values.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
BGRA emulation was added to address rendering artifacts when GL guest
apps are run on a GLES host with virglrenderer's use_gles == true.
Due to tenuous compatibility of EXT_texture_format_BGRA8888 with
gamma correction (sRGB formats/views) and multisampled rendering on
GLES hosts, it is best to represent BGR* resourcs with RGB* internal
format and add necessary byte re-ordering on to/from transfers instead.
Note, however, that removing the existing BGR* emulation will cause
problems for externally stored resources such as EGL images, and GBM
allocated buffers, which may actually be stored with BGR* byte-order.
This is addressed in the commits immediately following this one.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
For GL hosts CopyImageSubData and TextureView are not defined
when ASTC textures are involved, and the copy fallback currently
doesn't handle these formats correctly. Since Gallium can handles
ASTC texures transparetly in the guest, host support is not really
required to be able to use it.
Fixes all tests out of
dEQP-GLES32.functional.copy_image*astc*
that were failing on the llvmpipe GL host before
Related #224
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
It is always false because venus requires per-context fencing. However,
when it is true (in a private branch), it means
virgl_renderer_create_fence
virgl_renderer_poll
virgl_renderer_export_fence
(but not virgl_renderer_get_poll_fd)
works with venus.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
This is desirable when we have a per-context version of
virgl_renderer_export_fence.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Some game engines rely on the real hardware info to adjust default
graphics quality and other attributes.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Some game engines rely on the real hardware info to adjust default
graphics quality and other attributes.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Handle type must be VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT.
Check if VkMemoryResourceAllocationSizeProperties100000MESA is
chained. If chained, fill with dma_buf allocation size.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
We introduce vkGetVenusExperimentalFeatureData100000MESA to negotiate
experimental venus features under development between the guest and the
host, which can help avoid breaking existing clients of venus. All the
experimental features will be cleaned up and merged into core upon
finalizing venus protocol.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
When there is no vulkan support compiled in and user ask for vulkan
support, the current code could fail and clean everything while still
returns success since the outside ret value is not initialized yet.
Signed-off-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
There are many possible testure targets that can be bound as
framebuffer attachment, so it doesn't make sense to check assert
on this here.
Fixes: 4405172812
virgl: implement EXT_multisampled_render_to_texture
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
There is no valid reason for the guest to pass bad resource ids.
Because resource creation failures are not propagated back to the guest,
they are the most common reason for the guest to pass bad resource ids.
When that happens, failing earlier makes things easier to debug.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Akihiko Odaki
Ryan Neph
Chia-I Wu
Gert Wollny
Yiwei Zhang
Lepton Wu
Italo Nicola
chenjiangnan