The resource_busy() hook was having to check the batch cache for usage of
the resource, since TC didn't know how long our driver would. By
committing to calling the tc_driver_internal_flush_notify() hook on
non-deferred flushes, TC keeps track of which buffers have been used but
not flushed and considers them busy, saving us needing to look in the BC
(which we won't be able to do once we move it to being per-context).
drawoverhead test results (all numbers are throughput, n=5):
1, DrawElements ( 1 VBO| 0 UBO| 0 ) w/ no state change: -4.94214% +/- 2.45047%
7, DrawElements ( 1 VBO| 8 UBO| 8 Tex) w/ vertex attrib change: 48.3992% +/- 5.02827%
8, DrawElements ( 1 VBO| 8 UBO| 8 Tex) w/ 1 texture change: 26.0974% +/- 1.14932%
9, DrawElements ( 1 VBO| 8 UBO| 8 Tex) w/ 8 textures change: 12.6963% +/- 3.01077%
17, DrawElements ( 1 VBO| 8 UBO| 8 Tex) w/ 8 UBOs change: 54.3846% +/- 35.0049%
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11513>
The Navi 1x NGG hardware can hang in certain conditions when
not every wave launched before s_sendmsg(GS_ALLOC_REQ).
As a workaround, to ensure this never happens, let's emit a
workgroup barrier at the beginning of NGG VS and TES.
Note that NGG GS already has a workgroup barrier so it doesn't
need this.
Cc: mesa-stable
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10837>
Navi 1x GPUs have an issue: they can hang when the output vertex
and primitive counts are zero. The workaround is exporting a dummy
triangle.
This commit changes the dummy triangle's vertex so its positions
are all NaN. This should make sure the triangle is never rendered.
Cc: mesa-stable
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10837>
During dEQP runs for radv, I see a lot of warnings like,
ERROR - dEQP error: SPIR-V WARNING:
ERROR - dEQP error: In file ../src/compiler/spirv/spirv_to_nir.c:1073
ERROR - dEQP error: Decoration not allowed on struct members: SpvDecorationRestrict
ERROR - dEQP error: 408 bytes into the SPIR-V binary
This fails jobs on Gitlab, due to,
Job's log exceeded limit of 4194304 bytes.
Job execution will continue but no more output will be collected.
Since it doesn't seem feasible right now to fix the many shaders in
the VK-CTS triggering this warning, add an environment toggle that
allows test runners to only see the level of commentary they want.
v2 from Martin:
- Add my SoB
v3 from Martin:
- fix the indentation (suggested by Eric)
- put the declarations at the top of the function
v4 from Martin:
- make vtn_default_log_level() static (Marcin)
- cache the default level in vtn_log (Marcin)
- move vtn_log_level_strings inside vtn_default_log_level()
- Fix the build issue on MSC
Signed-off-by: Martin Peres <martin.peres@mupuf.org>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Acked-by: Andres Gomez <agomez@igalia.com>
Acked-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Acked-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11491>
We follow the same approach that v3d. We compile the files that
depends on the version several times, passing a different version each
time. We link all those per-version libs on the main library.
Note that right now we only support version == 42, so the array of
supported versions is one-sized.
Also note that although we were doing a previous work to split
hw-version dependant code from general code, this is the first commit
that only inject the current V3D_VERSION on the former.
We have two cases where we hardcode the V3D_VERSION (as a full
wrapping would be an overkill) that we need to include here to avoid
warnings/errors if we do that before or after.
Having some exceptions also happens on v3d. As we are here we add some
comment on v3d clarifying that.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
cl_packet_length depends on the specific hw generation packets, so it
is can't be included directly by main header.
The straight forward solution would be to allocate them dynamically,
based on the current generation. That ended to be complex and
messy. Also, even if that change between hw versions, it will not
change significantly.
So we just add some definition with the size of the packets we
prepack. We just need to be careful that this needs to be the maximum
value considering all the versions supported.
Note that on Opengl v3d does something similar, using hardcoded
values, but without a define, neither a runtime check.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
As part of this, we get rid of the v3dv_xxx_descriptor structs to
v3dv_descriptor. The main reason is that in order to support several
versions, we would need to define them several times. Also, they were
somewhat an overkill even before, as their main advantage was getting
the offset for each data on the combined case. That functionality is
replaced with some new helpers.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
The idea would be to move all the code that uses cl_emit,
cl_emit_with_prepack, v3dx_pack, and any enum/structure definition
defined on the v3d pack headers.
All those methods would be defined on v3dvx_private (that would be the
equivalent to v3dx_context.h on v3d).
This commit includes the definition of v3dX for the current version
supported (42), a function calling wrapper, and the move for v3dv_queue
methods as a reference.
About the function calling wrapper, I took the idea from anv. We don't
have on v3d, but we added it because we foresee that we will need that
functionality more often. So without that macro, in order to call the
correct version of the method from the general code we would need to
do like we do on v3d, and doing something like this:
if (devinfo->ver >= 42)
return v3d42_pack_sampler_state(sampler, pCreateInfo);
else
return v3d33_pack_sampler_state(sampler, pCreateInfo);
So with the macro we can just do this:
v3dv_X(device, pack_sampler_state)(sampler, pCreateInfo).
Note that as mentioned, that is to be used on the general code, so a
runtime decision. If we are already on version-dependant code (so at
v3dx_queue for example) we just use v3dX, as at that point is a build
time decision.
Also, fwiw, I don't like too much the name of that macro, but I was
not able to think on a better one.
v2: merge job_emit_noop_bin and job_emit_noop_render (Iago)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11310>
Instead of having different layouts which might complicate things when
some registers are missing, hardcode the SELECT and SELECT1 registers
into separate arrays.
The SELECT registers are "legacy" counters, while the SELECT1 registers
are SPM counters.
This is more verbose and emit more UCONFIG registers, but emitting the
SELECT registers is now much simpler and it seems less error prone.
This will also help emitting the SPM configuration.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11186>
This makes dEQP-VK.api.version_check.entry_points pass and matches how
other drivers are handling this case. We do not support the feature but
still need to provide a dummy entrypoint.
v2: throw error if/when called (Jason)
Fixes: 0d031d1da3 ("anv: toggle on VK_EXT_extended_dynamic_state2")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11503>
mesa/mesa@2dcc9c7f54 from mesa/mesa!6639 added a resource_get_param
hook for llvmpipe, which was nice since it gave lavapipe more features.
One of those features was not exporting llvmpipe textures, so those
parts were stubbed out and landed in an assert(0).
This completely broke kms_swrast (llvmpipe+GBM) on non-release builds,
since that definitely does need to export llvmpipe textures.
The query codepath which caused this explosion does fall back to
resource_get_handle() - which is how it worked previously - but not all
callers do this, so just do what all other drivers implementing
resource_get_param() do and open-code the translation.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reported-by: Jonas Ådahl <jadahl@gmail.com>
Tested-by: Jonas Ådahl <jadahl@gmail.com>
Fixes: 2dcc9c7f54 ("llvmpipe: add resource get param support.")
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6639
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11504>
The previous implementation had several issues:
- It wasn't checking all the conditions necessary for "this blit updates
the whole surface", like PIPE_MASK_Z but not S on a depth/stencil
buffer.
- It would reset the previous batchbuffer, even if that batch had side
effects on other buffers.
- The layering was painful to follow and made any recursion extra
dangerous.
Now, we use a more conservative test (enough for the resource shadowing
case) and just invalidate the buffer up front, which should have the right
logic for discarding drawing to that resource.
I found I had to add fd_bc_flush_writer() to the end of fd_blitter_blit()
-- a flush was happening at fb state restore time when the discard flag
was set, and losing that flush breaks
dEQP-GLES31.functional.stencil_texturing.format.stencil_index8_cube.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11455>
