I'm guessing this may have been disable because of missing
component packing support. However recent nir linking changes
required nir based gallium drivers to support component packing
so this should now be ok to enable.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
vsplit_add_cache uses the post-bias index for hashing, but the
vsplit_add_cache_uint/ushort/ubyte ones used the pre-bias index, therefore
the code for handling the special case (because -1 matches the initialization
value of the cache) wasn't actually working.
Commit 78a997f728 actually simplified the
cache logic somewhat, but it looks like this particular problem carried over
(and duplicated to the ushort/ubyte cases, since before only uint needed it).
This could lead to the vsplit cache doing the wrong thing, in particular
later fetch_info might indicate there are 0 values to fetch. This only really
affected edge cases which were bogus to begin with, but it could lead to a
crash with the jit vertex shader, since it cannot handle this case correctly
(the count loop is always executed at least once and we would not allocate
any memory for the shader outputs), so add another assert to catch it there.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This is an optimisation that is recommended by Matt Arsenault,
and used by RadeonSI, but it's not compatible with Vulkan.
Note that AC_FLOAT_MODE_UNSAFE_FP_MATH includes the no signed
zeros flag in LLVM.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
When that debug option is not used, we use the default float mode
because the no signed zeros optimisation is not Vulkan compatible.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This also replaces llvm.AMDGPU.kilp by llvm.AMDGPU.kill with
LLVM < 6. Similar to RadeonSI codepath.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
According with OpenGL GLSL 4.20 spec, section 4.3.9, page 57:
"It is a link-time error if any particular shader interface
contains:
- two different blocks, each having no instance name, and each
having a member of the same name, or
- a variable outside a block, and a block with no instance name,
where the variable has the same name as a member in the block."
This means that it is a link error if for example we have a vertex
shader with the following definition.
"layout(location=0) uniform Data { float a; float b; };"
and a fragment shader with:
"uniform float a;"
As in both cases we refer to both uniforms as "a", and thus using
glGetUniformLocation() wouldn't know which one we mean.
This fixes KHR-GL*.shaders.uniform_block.common.name_matching.
v2: add fixed tests (Tapani)
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
glXGetDriverConfig parameters do not provide a context to dynamically
check for the presence of the function, so the dispatcher directly calls
glXGetDriverConfig, but in non-dri builds dri_glx.c didn't provide
glXGetDriverConfig.
This change make it just return NULL in that case.
Fixes: 84f764a759 "glxglvnddispatch: Add missing dispatch for GetDriverConfig
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
This is to fix VA-API issues with GStreamer and MPEG2.
Since gstreamer does not pass quantiser matrices with each frame, invalid
pointers were being passed to the driver. This patch addresses the same.
Signed-off-by: Indrajit Das <indrajit-kumar.das@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Only update them when the pointers are valid.
Signed-off-by: Indrajit Das <indrajit-kumar.das@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Only upload them when the pointers are valid.
Signed-off-by: Indrajit Das <indrajit-kumar.das@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
This can't work for two reasons:
- TESSINNER/TESSOUTER are shader input values, so never translated
to the intrinsic ops
- the shader info pass scans the current stage but we want to know
in TCS, if TES reads the tess factors.
This fixes 6 regressions related to
deqp-vk/tessellation/shader_input_output/tess_level_{inner,outer}_XXX_tes
This reverts commit 5ba1a61648.
InstanceID is in VGPR2, not 1.
One more failure that CTS didn't catch up...
Reported-by: Alex Smith <asmith@feralinteractive.com>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This shouldn't be scanned in the pipeline.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Without this initialization the temp registers used in tgsi_declaration
may used random indices, and this may result in failing translation from TGSI
with an error message "GPR limit exceeded", because the random index is greater
then the allowed limit implying that the shader uses more temporary registers then
available.
Signed-off-by: Gert Wollny <gw.fossdev@gmail.com>
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
First try with a "soft" depth, to try to schedule sfu instructions
further from their consumers, but fall back to hard depth (which might
result in stalling) if nothing else is avail to schedule.
Previously the consumer of a sfu instruction could end up scheduled
immediately after (since "hard" depth from sfu to consumer would be 0).
This works because legalize pass would insert a (ss) sync bit, but it
is sub-optimal since it would cause a stall.
Instead prioritize other instructions for 4 cycles if they would no
cause a nop to be inserted. This minimizes the stalling. There is a
slight penalty in general to overall # of instructions in shader (since
we could end up needing nop's later due to scheduling the "deeper" sfu
consumer later), but ends up being a wash on register pressure.
Overall this seems to be worth a 10+% gain in fps. Increasing the
"soft" depth of sfu consumer beyond 4 helps a bit in some cases, but 4
seems to be a good trade-off between getting 99% of the gain and not
increasing instruction count of shaders too much.
It's possible a similar approach could help for tex/mem instructions,
but the (sy) sync bit seems to trigger a switch to a different thread-
group to hide memory latency (possibly with some limits depending on
number of registers used?).
Signed-off-by: Rob Clark <robdclark@gmail.com>
If the blit isn't changing format, but is changing tiling, just lie and
call things ARGB (since the exact component order doesn't matter for a
tiling blit).
Signed-off-by: Rob Clark <robdclark@gmail.com>
Overall a nice 5-10% gain for most games. And more for things like
glmark2 texture benchmark.
There are some rough edges. In particular, the hardware seems to only
support tiling or component swap. (Ie. from hw PoV, ARGB/ABGR/RGBA/
BGRA are all the same format but with different component swap.) For
tiled formats, only ARGB is possible. This isn't a big problem for
*sampling* since we also have swizzle state there (and since
util_format_compose_swizzles() already takes into account the component
order, we didn't use COLOR_SWAP for sampling). But it is a problem if
you try to render to a tiled BGRA (for example) surface.
The next patch introduces a workaround for blitter, so we can generate
tiled textures in ABGR/RGBA/BGRA, but that doesn't help the render-
target case. To handle that, I think we'd need to keep track that the
tiled format is different from the linear format, which seems like it
would get extra fun with sampler views/etc.
So for now, disabled by default, enable with FD_MESA_DEBUG=ttile. In
practice it works fine for all the games I've tried, but makes piglit
grumpy.
Signed-off-by: Rob Clark <robdclark@gmail.com>
The rules are sufficiently different for a5xx with tiled textures, so
split this out into something that can be implemented per-generation.
The a5xx specific implementation will come in a later patch.
Signed-off-by: Rob Clark <robdclark@gmail.com>
zlib provides a faster slice-by-4 CRC32 implementation than the
traditional single byte lookup one used by mesa. As most supported
platforms now link zlib unconditionally, we can easily use it.
Improvement for a 1MB buffer (avg MB/s, n=100, zlib 1.2.8):
i5-6600K C2D E4500
mesa zlib mesa zlib
443 1443 225% +/- 2.1% 403 1175 191% +/- 0.9%
It has been verified the calculation results stay the same after this
change.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The next change wants to use some optional zlib functionality, however
not all platforms currently use zlib. Based on earlier Jordan Justen's
patches and their review feedback.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Fixes a number of int64 piglit tests, for example:
generated_tests/spec/arb_gpu_shader_int64/execution/built-in-functions/fs-sign-i64vec2.shader_test
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
V2: just zero-extend the 32-bit value.
Fixes a number of int64 piglet tests, for example:
generated_tests/spec/arb_gpu_shader_int64/execution/conversion/frag-conversion-explicit-bool-int64_t.shader_test
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
assert() is replaced by unreachable(), to avoid following building error:
external/mesa/src/gallium/drivers/radeonsi/si_shader.c:1967:1:
error: control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
1 error generated.
Fixes: c797cd6 ("ac: add load_patch_vertices_in() to the abi")
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Fixes a bunch of arb_gpu_shader_fp64 piglit tests for example:
generated_tests/spec/arb_gpu_shader_fp64/execution/built-in-functions/fs-mix-double-double-double.shader_test
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
I had 3.x putting swizzling in the texture state only for 16-bit texture
returns, and in the shader for 32-bit. This may be due to having mixed up
the return channel setup on 3.x back before I had moved it into the
compiler. On 4.x, the non-border-color texwrap tests are passing nicely
with both 16 and 32-bit returns with swizzling in the texture state.
The LDVARY signal now writes an arbitrary register, so I took out the
magic src register file and replaced it with an instruction with LDVARY
set so we have somewhere to hang a QFILE_TEMP destination for register
allocation.
The V3D 3.x series of TMU writes with meaning depending on the texture
type is replaced with writes to specific registers for each texture
argument semantic.
