Fixes dEQP-EGL.functional.wide_color#window_888_colorspace_srgb on
ARCVM, which uses a 24 bit-per-pixel R8G8B8_UNORM surface format that
slipped through the cracks during the latest BGRA rework in
virglrenderer!725.
Fixes: 187e651304 ("vrend: avoid srgb views on eglimage-backed surfaces")
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Change-Id: I9553613278b2c7a99fd2898594221f52ff9ed643
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/740>
Converting from valid pointer to void to intptr_t and uintptr_t,
and then converting back to pointer to void will result in a pointer
which compares equal to the original pointer. Using another integer type
as intermediate would result in an implementation-defined behavior.
Especially using unsigned long for the purpose is problematic for
LLP64 model like Windows.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/726>
On GLES hosts, pixel data for BGRA resources are byte-reordered and
passed to the host driver for compatibility reasons.
The clear color used in glClearTexSubImage[EXT] for such resources
on GLES hosts must be reordered to match.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
After cleaning up many of the previous BGRA hacks, it is clear now that
we must manually reorder all bgr* data en-route to/from the guest, but
only for GLES hosts.
GL hosts instead enjoy the use of the GL_BGRA pixel transfer format,
prompting the host driver to the the reordering internally, and only
when it deems it necessary.
Trying to use GL_BGRA_EXT for GLES hosts is somewhat possible with the
new GL_MESA_bgra extension, but it still struggles when multisampled
textures are involved. It is more robust to use the GL_RGBA pixel
transfer format for GLES hosts instead and handle reordering ourselves.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
Now that the glTextureView() issues for eglimage-backed textures have
been discovered, we can switch back to using the right gbm formats for
externally allocated resources (this commit) and remove many of the
bgra-specific emulation (following commits).
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
There's no reason to keep them separated. gles_bgra_formats already
includes both UNORM and SRGB versions anyways.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
Views on samplers of eglimage-backed rgb* textures cause unintended
red/blue channel-swapping due to the lack of an internalformat that
specifically for BGR* ordering. Since we have control over the
sampler's swizzle parameters, we can still use the texture view to get
automatic colorspace conversion, but need to compensate for the
unintended swizzle with our own to swizzle back. If the view intended
to swap the channels, we just leave the swizzle parameters alone.
With this approach, no shader augmentation is necessary.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
It is now clear that this special swizzling only needs to be applied to
blits involving eglimage-backed bgr* resources, which do not support
texture views. In this case, an extra red/blue swizzle must only be
applied in blits that involve exactly one eglimage-backed bgr* resource
with an rgb* view format. No special consideration is required for
internally-allocated bgr* resources, so that code has been dropped from
the helper function.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
eglimage-backed bgr* textures must have colorspace conversion applied
manually since they don't support glTextureView(). Use the new blitter
features for srgb decode/encode and force these blits down the
vrend_renderer_blit_int() pathway.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
This is needed for bgr* textures backed by eglimages that traditionally
used glTextureView() to mediate colorspace conversions, as that approach
has been determined to cause format misinterpretation issues.
This commit simply adds the capabilty but doesn't enable such manual
encode/decode for any uses yet.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
Since eglimage-backed textures don't support glTextureView(), colorspace
conversion must be applied manually on the clear_color vector. Also, if
the view intended to swizzle, we need to do that manually as well.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
Continue using the existing option to manually encode writes to such
surfaces via fragment shader glsl augmentation.
Uses the new vrend_resource_supports_view() to detect this scenario.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
using glTextureView() on eglimage-backed bgr* textures has been
determined to cause format misinterpretation issues, such as swapping
the red/blue channels.
This adds a convenience function for detecting these unsupported view
uses. It will be used to prevent creating views in the following commits.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/725>
There are many combinations of invalid arguments for OpenGL functions
and it is impractical to cover all of them.
Even if nothing is wrong with the user, GL_CONTEXT_LOST and
GL_OUT_OF_MEMORY can also occur in many GL functions due to hardware
problems. They can leave the context in an invalid state which can
result in a reliability or security issue.
Check GL errors after an operation completes and prevent from using the
GL context after a GL error occurred.
spec@!opengl 1.5@draw-vertices, spec@!opengl 1.5@draw-vertices-user,
and spec@!opengl 2.0@gl-2.0-vertexattribpointer are marked as crash in
.gitlab-ci/expectations/host/piglit-virgl-gles-fails.txt because they
require GL_DOUBLE specification for glVertexAttribPointer, which is
not supported by OpenGL ES. Avoiding the crashes requires capability
checks on the guest, which this change does not implement.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/715>
VREND_DEBUG_ENABLED represents if debugging features are enabled and is
controlled by NDEBUG macro. By using VREND_DEBUG_ENABLED in
an if statement instead of using NDEBUG in ifdef, the compiler can
validate the content of the conditional and know its variable usage to
avoid meaningless warnings.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/715>
v2: Check function availability
v3: Isolate function availability check to a variable (Gert Wollny)
v4: Use util_format_name and add a utility function (Gert Wollny)
v5: Move variables to narrower scopes (Gert Wollny)
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/715>
The compressed formats are incompatible with
GL_TEXTURE_RECTANGLE on Mesa 21.3.6.
This also fixes spec@!opengl 1.0@gl-1.0-dlist-bitmap, which makes
the guest to have GL_TEXTURE_RECTANGLE but TGSI specifies
TGSI_TEXTURE_2D, on OpenGL ES by always looking at the target of
given texture.
v2: Use the result of compatibility check in shader transformation.
(Gert Wollny)
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/715>
We've got bug reports with
vkr: vkExecuteCommandStreamsMESA resulted in CS error
and nothing else.
As far as I can tell, the decoder, the encoder, and vn_dispatch_command
all log on CS errors. The problem should be in
vkr_dispatch_vkExecuteCommandStreamsMESA. Make
vkr_dispatch_vkExecuteCommandStreamsMESA chatty as well.
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/722>
VIRGL_BIND_PREFER_EMULATED_BGRA macro was removed when
the old BGRA emulation was removed, but that makes src/virgl_hw.h
incompatible with Mesa, which still has a reference to the macro.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/716>
Apply the same logic as done in commit 08e7afd116 for
the input as we also need to take the indirect output into account.
Fixes running these two dEQP tests:
dEQP-GLES2.functional.shaders.indexing.varying_array.vec4_static_loop_write_static_loop_read
dEQP-GLES2.functional.shaders.indexing.uniform_array.vec4_static_read_vertex
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
v2: * update logic for when to use gbm transfers and send
another caparbility flag to the guest about which
formats can be read back from
* Add comment about GBM logic (John)
v3: * Only enable gbm readback for scanout textures, and signal
the guest when gbm is used, so that it can use stageing
texture transfers in this case.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Chia-I Wu
Ryan Neph
Corentin Noël
Akihiko Odaki
Yiwei Zhang
Gert Wollny