It's legal in OpenGL to start a query even if the result will have zero
valid bits. It's not enough to just report zero bits, We need to also
prevent calling down into the driver with these invalid queries.
Because ARB_ES3_compatibility adds ANY_SAMPLES_PASSED and
ANY_SAMPLES_PASSED_CONSERVATIVE to the set of queries that support zero
bits, we also need to check for the corresponding indices.
Fixes: 0186e9e1c5 ("mesa: always support occlusion queries")
Reviewed-by: Soroush Kashani <soroush.kashani@imgtec.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19750>
(cherry picked from commit 1b1e8873fe)
The mesa state-tracker can now emulate all formats indicated by this
feature-flag, so we don't require this for OpenGL 4.2 any more.
It's however a good idea to support for power-usage and performance
reasons, saving on memory bandwidth. So let's move it to the
gl46_optimal block instead.
Fixes: e4ff42684b ("mesa/st: enable bptc extension with fallback")
Fixes: 2ea481b2f0 ("Zink: add Zink profiles file")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19779>
(cherry picked from commit 13bccac5a7)
We never required the uniform texel buffer bit for more than
bufferFeatures for a bunch of these formats.
Similarly, we *don't* need the uniform texel buffer bit for sampled
image access.
For the image-dimensions, the Mesa frontend doesn't validate the max 1D,
3D or Cube sizes, nor the max texture layers. So we'll expose GL 4.1
without these, even if that's not conformant.
Finally, we don't require robustImageAccess2 for OpenGL 4.3 at all. All
we need is the robustBufferAccess feature.
Fixes: 2ea481b2f0 ("Zink: add Zink profiles file")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19779>
(cherry picked from commit b60bc52992)
Fixes a number of CTS patterns on DG2 :
- dEQP-VK.dynamic_rendering.primary_cmd_buff.random*
- dEQP-VK.draw.*secondary_cmd*
- dEQP-VK.dynamic_rendering.*secondary_cmd*
- dEQP-VK.geometry.*secondary_cmd_buffer
- dEQP-VK.multiview.*secondary_cmd*
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9c1c1888d9 ("intel/fs: put scratch surface in the surface state heap")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19946>
(cherry picked from commit 9bb055ff5d)
static constexpr const 'value' is replaced by static function
in all type_char template specializations
to avoid the following building errors happening with clang 6
/home/utente/pie-x86_kernel/prebuilts/clang/host/linux-x86/clang-4691093/bin/ld.lld: error: undefined symbol: r600::type_char<r600::ExportInstr>::value
>>> referenced by sfn_scheduler.cpp
>>> sfn_sfn_scheduler.cpp.o:(bool r600::BlockSheduler::collect_ready_type<r600::ExportInstr>(std::__1::list<r600::ExportInstr*, std::__1::allocator<r600::ExportInstr*> >&, std::__1::list<r600::ExportInstr*, std::__1::allocator<r600::ExportInstr*> >&)) in archive src/gallium/drivers/r600/libr600.a
...
/home/utente/pie-x86_kernel/prebuilts/clang/host/linux-x86/clang-4691093/bin/ld.lld: error: undefined symbol: r600::type_char<r600::RatInstr>::value
>>> referenced by sfn_scheduler.cpp
>>> sfn_sfn_scheduler.cpp.o:(bool r600::BlockSheduler::collect_ready_type<r600::RatInstr>(std::__1::list<r600::RatInstr*, std::__1::allocator<r600::RatInstr*> >&, std::__1::list<r600::RatInstr*, std::__1::allocator<r600::RatInstr*> >&)) in archive src/gallium/drivers/r600/libr600.a
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
Cc: "22.2" "22.3" mesa-stable
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19873>
(cherry picked from commit e74d989a69)
If a shader has XFB outputs but the application never enables
streamout in runtime (no buffers bound and no begin/end pair), we
have to disable it in the shader by emitting buffer size as 0. It's
also still needed to remember that the cmdbuf needs GDS/GDS OA BOs,
so move this at pipeline bind time instead.
Cc: 22.3 mesa-stable
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/19801>
(cherry picked from commit 3189be249d)
The NGG streamout lowering pass allocates space for all outputs which
means we have to align our computation. Otherwise, the maximum number
of vertices is incorrect and we end up by reaching the maximum allowed
LDS size. This code could be shared instead of being duplicated but
that's for later.
Fixes some transform feedback tests with Zink and
RADV_PERFTEST=ngg_streamout on GFX10.3.
Cc: 22.3 mesa-stable
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/19801>
(cherry picked from commit ba81dcf971)
This fixes a longstanding bug in the interaction between TS and a write
mapping. The write does not update TS regardless of the way the update
is done. Update via etna_copy_resource would just set the target ts_valid
to false without actually writing back any dirty TS to the resource.
Writes via the CPU would update the resource, but keep ts_valid at true
even if the tile status may now not match the actually written tiles of
the resource anymore.
Fix this by writing back a dirty TS to the target resource if needed
before updating the level with the write data. Always invalidate TS,
even when the update is done by the CPU.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19846>
(cherry picked from commit 0fb813526e)
Consider the loop:
float i = 0.0;
while (true) {
if (i != 0.0)
break;
i = i + 1.0;
}
This loop clearly executes exactly one time.
Some trickery is necessary to handle cases where the initial loop value
is very large and the increment is, by comparison, very small. From the
fenu_once test case,
float i = -604462909807314587353088.0;
while (true) {
if (i != -604462909807314587353088.0)
break;
i = i + 36028797018963968.0;
}
This loop should also execute exactly once, but this is much more
challenging to calculate due to precision issues.
Going towards smaller magnitude (i.e., adding a small positive value to
a large negative value) requires a smaller delta to make a difference
than going towards a larger magnitude. For this reason,
-604462909807314587353088.0 + 36028797018963968.0 !=
-604462909807314587353088.0, but -604462909807314587353088.0 +
-36028797018963968.0 == -604462909807314587353088.0. Math class is
tough.
No changes in shader-db or fossil-db.
v2: Fix major bug in checking result of the eval_const_binop(nir_op_feq,
...) discovered while developing fneu_once_easy unit test. Fix a typo in
the comment just above that. Add fneu_once_easy test.
v3: Skip the iteration count adjustment tests for nir_op_fenu and
nir_op_ine. Since the iteration count is either 1 or unknown, all this
function can do is add numerical error. Add fenu_once tests.
v4: Change the initial value in the fneu_once test from large positive
to large negative. Change check in get_iteration from nir_op_fsub to
nir_op_fadd. Both changes from discussion with M Henning. Also add some
more explanation in fneu_once.
v5: Rename test cases.
Fixes: 6772a17acc ("nir: Add a loop analysis pass")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19732>
(cherry picked from commit f75c83c4aa)
I discovered this problem because adding an algebraic transformation to
convert some uge and ult to ieq or ine caused a couple loops to stop
unrolling. Consider the loop:
uint i = 0;
while (true) {
if (i >= 1)
break;
i++;
}
This loop clearly executes exactly one time. Note that uge(x, 1) is
equivalent to ine(x, 0). Changing the condition to 'if (i != 0)' will
also execute exactly one time.
In the added test cases, uge_once correctly get an exact loop trip count
of 1. Without the changes to nir_loop_analyze.c, the ine_once case
detects a maximum loop trip count of zero and does not get an exact loop
trip count.
No changes in shader-db or fossil-db.
v2: Move nir_op_fneu changes to a separate commit.
v3: Rename test cases.
Fixes: 6772a17acc ("nir: Add a loop analysis pass")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19732>
(cherry picked from commit d9f014401b)
There seems to be a problem with running firefox by using Xwayland that
results in a shared resources being not always tagged as using staging.
As a result one process tries to map the resource that was allocated as
one that uses staging without actually using the staging resource, and
hence the mapped range only accounts for the small region that we have
to allocated because a zero-allocation doesn't work, but the application
mapping the resource assumes that a properly sized range is mapped, and
consequently this results in invalid memory access.
To work around this issue disable creating staging for resources that
are created by using shared binding. It is not clear to me whether this
is the best fix, but it seems to quell the issue.
Fixes: c9d99b7eec
virgl: Fix texture transfers by using a staging resource
Related: https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/291
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19655>
(cherry picked from commit e496d24cb2)
In 4ceaed7839 we made scratch surface state allocations part of the
internal heap (mapped to STATE_BASE_ADDRESS::SurfaceStateBaseAddress)
so that it doesn't uses slots in the application's expected 1M
descriptors (especially with vkd3d-proton).
But all our compiler code relies on BSS
(STATE_BASE_ADDRESS::BindlessSurfaceStateBaseAddress).
The additional issue is that there is only 26bits of surface offset
available in CS instruction (CFE_STATE, 3DSTATE_VS, etc...) for
scratch surfaces. So we need the drivers to put the scratch surfaces
in the first chunk of STATE_BASE_ADDRESS::SurfaceStateBaseAddress
(hence all the driver changes).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 4ceaed7839 ("anv: split internal surface states from descriptors")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7687
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19727>
(cherry picked from commit 9c1c1888d9)
