The scheduler has code to handle hardware that shares the same memory
for inputs and outputs. Seeing as the specific stages that need this is
probably hardware-dependent, this patch makes it a configurable option
instead of hard-coding it to everything but fragment shaders.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5561>
nir_deps_state is a struct used as a closure for calculating the
dependencies. Previously it had two fields copied out of the scoreboard.
The closure is initialised in two seperate places. In order to make it
easier to access other members of the scoreboard in the callbacks in
later patches, the closure now just contains a pointer to the scoreboard
and the two bits of copied information are removed.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5561>
load_per_vertex_input should probably be handled in the same way as a
regular load_input. I think the nir_schedule pass was written before V3D
had geometry shader support, so that is probably why it hasn’t taken
this into account until now.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5561>
wsi_release_display() implements vkReleaseDisplayEXT() which
is supposed to return control to the lessor of an output
upon call.
We need to terminate the wsi->wait_thread when close()'ing
the wsi->fd, otherwise the wait_thread holds another reference
to the wsi->fd, keeping the lease active, and thereby the
leased output blocked, until vkDestroyInstance() is called.
This gives users their GUI back, instead of extended darkness.
Fixes: 352d320a07 ("vulkan: Add EXT_direct_mode_display [v2]")
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5396>
Since binning pass variants share the same const_state with their
draw-pass counterpart, we should re-use the draw-pass variant's ubo
range analysis. So split the two functions of the existing pass
into two parts.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5526>
This serves two purposes, one during ubo range analysis, where we want
to create new ranges, and another during the actual ubo lowering. Split
these in two, with read-only ubo analysis state in the second case, to
prepare to split this pass in two.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5526>
This source-file uses PIPE_OS_WINDOWS to enable the Windows
functionality. But witout including p_config.h, this pre-processor
symbol won't be defined at all.
Let's fix this by adding the missing include, enabling stack-traces on
Windows.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5497>
The Windows implementation of debug_backtrace_capture has a limiation
of max 62 frames in total. Subtract a start-frame of 1 and the wrapping
functions frame, and we land at 60.
So let's lower this number on Windows to avoid triggering an assert.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5497>
Similar to the previous patch, we currently depend on the UNICODE macro
not being set, but it sometimes ends up getting set after all.
Unlike the previous patch, the easier thing to do here, is to lean into
the Unicode wrappers, and use the TEXT()-macro to define a Unicode
or ASCII literal, depending on the setting of the UNICODE macro.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5497>
The GetCommandLine API comes in two versions, GetCommandLineA (which
returns "ANSI" results), and GetCommandLineW which returns UTF-16
("WIDE") results. Then finally, windows.h provides a wrapper-macro that
defines GetCommandLine to either of the two, based on the setting of
the UNICODE macro.
More information about this mechanism can be found here:
https://docs.microsoft.com/en-us/windows/win32/intl/unicode-in-the-windows-api
For some reason, the UNICODE macro is set during build, even if we're
not explicitly setting it. This leads to us trying to cast a UTF-16
result to a char-pointer, which is obviously not going to do the right
thing.
So let's be defensive, and just call GetCommandLineA directly instead.
This avoids us depending on the setting of the UNICODE-macro in the
first place.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5497>
Looks like it fixes some potentially important VK test bugs. But also, it
fixes the GLES31 SSBO layout tests to not be so excessively large, so we
can run them in a reasonable time now. Note that a630 fail list is reset,
since the test list has changed and so we end up with a different subset
of tests being run. Interestingly, in the process the semaphore tests are
now reporting "NotSupported (Exporting and importing semaphore type not
supported at vktSynchronizationSignalOrderTests.cpp:513)" where they
weren't before.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5554>
For texturing and draw calls, HW expects the clear color to be in two
different color spaces after sRGB fast-clears - sRGB in the former and
linear in the latter. Up until now, iris has stored the clear color in
the sRGB color space. Limit the allowable clear colors for sRGB
fast-clears to 0/1 so that both color space requirements are satisfied.
Makes iris pass the sRGB -> sRGB subtest of the fcc-write-after-clear
piglit test on gen9+.
v2:
* Drop iris_context::blend_enables. (Ken)
* Drop some more resolve-related blend-state-tracking code.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4972>
For rendering operations, avoid adding or using fast-cleared blocks if
the render format is incompatible with the clear color interpretation.
Note that the clear color is currently interpreted through the
resource's surface format.
Makes iris pass subtests of the fcc-write-after-clear piglit test:
* UNORM -> SNORM, partial block on gen8+.
* linear -> sRGB, partial block on gen9+.
* UNORM -> SNORM, full block on gen12.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4972>
Remove the CCS_D fallback logic so that iris doesn't attempt to use a
non-existent surface state for some renders. Also, add an assertion to
catch the issue.
The fallback in iris_resource_render_aux_usage can lead to this problem
because it doesn't account for the fact that surface states created from
resources with the Y_TILED_CCS modifier may only have CCS_E or NONE as
aux usages (due to iris_resource_create_with_modifiers).
Without this change, the next commit would have triggered the fallback
and regressed the following tests on gen9:
* dEQP-EGL.functional.wide_color.window_888_colorspace_srgb
* dEQP-EGL.functional.wide_color.window_8888_colorspace_srgb
* dEQP-EGL.functional.wide_color.pbuffer_888_colorspace_srgb
* dEQP-EGL.functional.wide_color.pbuffer_8888_colorspace_srgb
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4972>
