The SAMPLEMASK is always returning an integer, we previously always had another
instruction that would convert it to a float but this is no longer the case so
always convert it to a floating number.
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/684>
We mark the build job as never running post-merge, because we just don't
want a pipeline running. GitLab seems to respond to this by just trying
to run the job anyway, so mark it as never.
In all other cases, it will be run on_success when the upstream jobs it
depends on have completed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/748>
Mesa has VIRGL_FORMAT_R8G8_SRGB since commit
e33cb6a763532279fc6fa6c3c1583ce3dd530827. Define it also in
virglrenderer for the header compatibility with Mesa and
to avoid acceidental collision of the definition.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/738>
VirGL just runs way too many jobs, with each pipeline consuming the
entire committed x86-64 build capacity we have available, so we need to
restrict it anyway. This is made worse by the fact it will create
duplicate pipelines for merge requests.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/744>
It is possible for two variable to have the same sid and array_id as long as they
have a different name. Make sure that we are not considering them as two components.
Also fix the already_found_one variable define in the loop when we need it to persist
between iterations.
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/736>
Adds the code to make use of the new proc table functions
in the [physical_]device initialization.
Co-authored-by: Igor Torrente <igor.torrente@collabora.com>
Co-authored-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/719>
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>
Gert Wollny
Corentin Noël
Igor Torrente
Daniel Stone
Akihiko Odaki
Cristian Ciocaltea
Yiwei Zhang
Chia-I Wu
Ryan Neph