When rasterizing legacy-lines, OpenGL defines the width as being an
extrusion along the minor axis, repeating varyings. While the spec
*does* allow for an alternative method that matches our current results,
the OpenGL ES CTS doesn't allow these results even if OpenGL ES has the
same wording of an alternative method.
This is technically speaking a bug in the OpenGL ES CTS, but it seems
like nobody else is using the alternative formulation, at least not
while passing the OpenGL ES CTS. On top of this, the OpenGL specification
explicitly lists the extrusion results as the preferred method.
So it seems like a good idea for us to do this the way the OpenGL
specification prefers regardless; it's going to give less surprising
results to applications, and it's helping us pass some tests.
This math to set these up would "trivially" be:
dx = (dx * dx + dy * dy) / dx
dy = 0
and:
dy = (dx * dx + dy * dy) / dy
dx = 0
...but since we've already calculated dxdy, we can reformulate this to
save a division.
This fixes the following dEQP test-cases:
- dEQP-GLES2.functional.rasterization.interpolation.basic.line_loop_wide
- dEQP-GLES2.functional.rasterization.interpolation.basic.line_strip_wide
- dEQP-GLES2.functional.rasterization.interpolation.basic.lines_wide
- dEQP-GLES2.functional.rasterization.interpolation.projected.line_loop_wide
- dEQP-GLES2.functional.rasterization.interpolation.projected.line_strip_wide
- dEQP-GLES2.functional.rasterization.interpolation.projected.lines_wide
- dEQP-GLES3.functional.rasterization.fbo.rbo_singlesample.interpolation.lines_wide
- dEQP-GLES3.functional.rasterization.fbo.texture_2d.interpolation.lines_wide
- dEQP-GLES3.functional.rasterization.interpolation.basic.line_loop_wide
- dEQP-GLES3.functional.rasterization.interpolation.basic.line_strip_wide
- dEQP-GLES3.functional.rasterization.interpolation.basic.lines_wide
- dEQP-GLES3.functional.rasterization.interpolation.projected.line_loop_wide
- dEQP-GLES3.functional.rasterization.interpolation.projected.line_strip_wide
- dEQP-GLES3.functional.rasterization.interpolation.projected.lines_wide
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11315>
Seems we haven't encountered this before because
nir_lower_io_to_scalar_early usually scalarizes this.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12486>
This has never been used because it requires to know the previous
clear values which is not really possible in Vulkan.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12326>
We would like draw-only display lists to have immutable draw info and
this is the only GL non-draw state in pipe_draw_info (not counting
view_mask).
It also allows removing some code from draw_vbo for tessellation.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12351>
Fixes framebuffer_fetch and blend_equation_advanced dEQP tests on v6.
v2: Use clause dependencies rather than comparing the message type
v3: Shift the BIFROST_SLOT_* constants before using them as a mask
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12375>
Two related changes:
- in tu_device.c:tu_CreateDevice we need to free both pointers in the
teardown path after tu_bo_finish(global_bo), which uses the pointers.
They are allocated in the first call to tu_bo_init(), which happens
when global_bo is allocated.
- in tu_drm.c:tu_bo_init we need to free bo_list if the bo_idx
allocation fails. Convert to the goto teardown pattern as well.
Fixes the following dEQP-VK tests:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail
dEQP-VK.api.object_management.alloc_callback_fail.device
dEQP-VK.api.object_management.alloc_callback_fail.device_group
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12481>
Apparently, CLPER_V7 is missing from Mali G31, but CLPER_V6 works. Fixes
INSTR_INVALID_ENC faults and failures in
dEQP-GLES3.functional.shaders.derivate.* on Dvalin.
Technically not an errata but an implementation difference. I suspect
Mali G51 will need this as well, should we ever allowlist it.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
ST_TILE lets us specify an explicit sample, whereas BLEND replicates to
all samples. This fully fixes the interaction between blend shaders and
multisampling on Bifrost, manifesting as
dEQP-GLES3.functional.fragment_ops.random.* failures with the
configuration rgba8888d24s8ms4.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
This varies the sample ID value, which will be used in the next commit.
This is less complicated than keying blend shaders to the content of
this flag and trying to make mega blend shaders covering all samples at
once ... complexity I'd rather not think about right now. The DDK does
it this way.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
Use the explicit sample mode and set the sample ID in the pixel indices
structure to the current sample ID. This fixes tilebuffer loads in blend
shaders on multisampled framebuffers.
Make sure the new routine is broken out to a helper for use with ST_TILE
in the next commit.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
This breaks screen-space derivatives in a shader that uses multiple
render targets, if the derivative calculation is scheduled after a BLEND
instruction calling into a blend shader.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
I don't think we'll ever hit this in practice, since it's not needed for
blend shaders, but better to correct the code anyway.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
Although it is passing all of dEQP-GLES31, it is failing a few
KHR-GLES31.* tests. It also has performance issues at the moment. Invert
the existing noindirect debug flag to become a indirect debug flag. Set
this flag for dEQP-GLES31 CI on G52, to make sure the code doesn't bit
rot on the hope someone will pick this up later on.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
struct wsi_wl_image is only used as member of the swapchain, and during
the swapchain creation the image is already initialized to zero. So we
have no problems with members of the image being used uninitialized.
But for consistency, memset the members of this struct to zero in
wsi_wl_image_init(). This can help to avoid problems in the future.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12451>
In wsi_wl_surface_create_swapchain() we have a piece of code to init
some members of the chain to 0, in order to allow us to call
wsi_wl_swapchain_destroy() for cleanup.
Instead, we can use vk_zalloc() to allocate the chain, as it initializes
all members of the struct to zero. This help us to avoid problems when
people add new members to the struct and forget to initialize them.
Also, it makes the code look better.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12451>
This catches use-after-frees and buffer overflows, but not leaks (which we
disable the checking for since the library gets dlclose()d and we end up
with useless backtraces).
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8889>
I never really implemented this properly, because I wasn't aware of the
clusters when doing the original pipeline barrier implementation. It
turns out that the Vulkan stages we get as part of the barriers are
actually good for something, because it turns out that the pipeline
state is split into stages, so earlier stages can run ahead of later
stages and sometimes we need to wait when an earlier stage depends on
the result of a later stage. This happens most often whenever a shader
reads the result of a color/depth attachment write, because attachment
writes happen in a logically later stage. However this could also happen
for a FS -> VS dependency.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12475>
Implement the workarounds in anv and iris instead.
Before this commit, ISL unconditionally modified workaround registers
while filling out depth stencil state. To account for this, drivers
unconditionally stalled prior to emitting depth stencil packets. This
hurt performance.
By having the drivers perform the workarounds, they can choose when to
modify the relevant registers. The drivers now avoid emitting the
workaround for NULL depth buffers. This reduces stalls and leads to
better performance.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (the ISL/Anv bits)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (the Iris bits)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11454>
Erik Faye-Lund
Rhys Perry
Samuel Pitoiset
Daniel Schürmann
Michel Zou
Ian Romanick
Marek Olšák
Connor Abbott
Rob Clark
Icecream95
Matt Turner
Alyssa Rosenzweig
Leandro Ribeiro
Emma Anholt
Nanley Chery