restart_index is later always used in a comparison, so it should be
initialized properly.
Fixes valgrind warning:
Conditional jump or move depends on uninitialised value(s)
at 0xB8D682F: r600_draw_vbo (r600_state_common.c:2153)
by 0xB71F743: u_vbuf_draw_vbo (u_vbuf.c:1156)
by 0xB3B92DB: st_draw_vbo (st_draw.c:235)
by 0xB36B1AE: vbo_draw_arrays (vbo_exec_array.c:391)
by 0xB36BB0D: vbo_exec_DrawArrays (vbo_exec_array.c:550)
by 0x10A989: piglit_display (textureSize.c:157)
by 0x4F8F174: run_test (piglit_fbo_framework.c:52)
by 0x4F7BA12: piglit_gl_test_run (piglit-framework-gl.c:229)
by 0x10A60A: main (textureSize.c:71)
Uninitialised value was created by a stack allocation
at 0xB3B90B0: st_draw_vbo (st_draw.c:143)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Its unlikely anyone will add proper ARB_direct_state_access compat
support before we branch 18.2. Enabling the extension in 4.5 at
least allows users to make use of MESA_GL_VERSION_OVERRIDE=4.5COMPAT
for games like No Mans Sky.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The game forgets to enable multiple extensions in its shaders, one
of those extesions is EXT_texture_array. But enabling this config
entry fixes at least one other rendering issue that enabling
EXT_texture_array on its own doesn't fix.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
There is a 15-character limit for thread names shared by the queue name
and process name. Shorten the thread name to make space for the process
name.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Compile times of simple shaders are reduced by ~20%.
Compile times of prologs and epilogs are reduced by up to 40%.
Reviewed-by: Dave Airlie <airlied@redhat.com>
This is basically LLVMTargetMachineEmitToMemoryBuffer inlined and reworked.
struct ac_compiler_passes (opaque type) contains the main pass manager.
ac_create_llvm_passes -- the result can go to thread local storage
ac_destroy_llvm_passes -- can be called by a destructor in TLS
ac_compile_module_to_binary -- from LLVMModuleRef to ac_shader_binary
The motivation is to do the expensive call addPassesToEmitFile once
per context or thread.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Changes in v2:
- make loadSuInfo32() protected without making the rest protected
- move NVC0_SU_INFO_* into nv50_ir_lowering_nvc0.h instead of duplicating
NVC0_SU_INFO_MS
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
In 6f5abf3146 this code was fixed to calculate the maximum size of
an attribute in a seperate pass and then allocate the registers to
that size. However this wasn’t taking into account ranges that overlap
but don’t have the same starting location. For example:
layout(location = 0, component = 0) out float a[4];
layout(location = 2, component = 1) out float b[4];
Previously, if ‘a’ was processed first then it would allocate a
register of size 4 for location 0 and it wouldn’t allocate another
register for location 2 because it would already be covered by the
range of 0. Then if something tries to write to b[2] it would try to
write past the end of the register allocated for ‘a’ and it would hit
an assert.
This patch changes it to scan for any overlapping ranges that start
within each range to calculate the maximum extent and allocate that
instead.
Fixed Piglit’s arb_enhanced_layouts/execution/component-layout/
vs-fs-array-interleave-range.shader_test
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Fixes: 6f5abf3146 "i965: Fix output register sizes when multiple variables
share a slot."
The current code causes:
/usr/include/c++/8/debug/safe_iterator.h:207:
Error: attempt to copy from a singular iterator.
This is due to the iterators getting invalidated, fix the
reverse iterator to use the return value from erase, and
cast it properly.
(used Mathias suggestion)
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Mathias Fröhlich <mathias.froehlich@web.de>
This ports radv to the shared code, however due to a bug in LLVM
version prior to 7, radv cannot add target info at this stage,
as it would leak one for every shader compile, however I'd prefer
to keep this llvm damage in the shared code, since it isn't the
driver at fault here. We just add a flag to denote if the driver
can support leaking the target info or not, and the common code
does the right thing depending on the llvm version.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
We want to share this code with radv in the future, so port
it out of radeonsi.
Add a return value as radv will want that to know if this
succeeds
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
As precursor to moving init to common code, just rename the struct
and move it.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is prep work for moving this to a per-thread struct
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This adds a inline always pass, but otherwise should work the
same.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This just splits out the non-shared code and reuses ac_get_llvm_target in radv.
v2: rebase on Marek's patch - fixup brace position/whitespace
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
From the SPIR-V 1.0 specification, section 3.32.18, "Atomic
Instructions":
"OpAtomicIDecrement:
<skip>
The instruction's result is the Original Value."
However, we were implementing it, for uniform atomic counters, as a
pre-decrement operation, as was the one available from GLSL.
Renamed the former nir intrinsic 'atomic_counter_dec*' to
'atomic_counter_pre_dec*' for clarification purposes, as it implements
a pre-decrement operation as specified for GLSL. From GLSL 4.50 spec,
section 8.10, "Atomic Counter Functions":
"uint atomicCounterDecrement (atomic_uint c)
Atomically
1. decrements the counter for c, and
2. returns the value resulting from the decrement operation.
These two steps are done atomically with respect to the atomic
counter functions in this table."
Added a new nir intrinsic 'atomic_counter_post_dec*' which implements
a post-decrement operation as required by SPIR-V.
v2: (Timothy Arceri)
* Add extra spec quotes on commit message
* Use "post" instead "pos" to avoid confusion with "position"
Signed-off-by: Antia Puentes <apuentes@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
This is mostly just a straight-forward conversion of
link_assign_atomic_counter_resources to C directly using nir variables
instead of GLSL IR variables.
It is based on the version of link_assign_atomic_counter_resources in
6b8909f2d1. I’m noting this here to make it easier to track changes
and keep the NIR version up-to-date.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Capability that informs if atomic counters are supported. From SPIR-V
1.0 spec, section 3.7, "Storage Class", item 10 from table:
(Column "Storage Class"):
"AtomicCounter For holding atomic counters. Visible across all
functions of the current invocation. Atomic counter-specific
memory."
(Column "Required Capability"):
"AtomicStorage"
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
This is convenient when dealing with atomic counter uniforms. The
alternative would be doing that at vtn_handle_atomics.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
When constructing NIR if we have a SPIR-V uint variable and the
storage class is SpvStorageClassAtomicCounter, we store as NIR's
glsl_type an atomic_uint to reflect the fact that the variable is an
atomic counter.
However, we were tweaking the type only for atomic_uint scalars, we
have to do it as well for atomic_uint arrays and atomic_uint arrays of
arrays of any depth.
Signed-off-by: Antia Puentes <apuentes@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
v2: update after deref patches got pushed (Alejandro Piñeiro)
v3: simplify repair_atomic_type (suggested by Timothy Arceri, included
on the patch by Alejandro)
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
GLSL types differentiates uint from atomic uint. On SPIR-V the type is
uint, and the variable has a specific storage class. So we need to
tweak the type based on the storage class.
Ideally we would like to get the proper type at vtn_handle_type, but
we don't have the storage class at that moment.
We tweak only the nir type, as is the one that really requires it.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Also initialize it on var_decoration_cb
This is equivalent to nir_variable.offset, used to store the location
an atomic counter is stored at.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
ARB_gl_spirv points that uniforms in general need explicit
location. But there are still some cases of uniforms without location,
like for example uniform atomic counters. Those doesn't have a
location from the OpenGL point of view (they are identified with a
binding and offset), but Mesa internally assigns it a location.
Signed-off-by: Eduardo Lima <elima@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Neil Roberts <nroberts@igalia.com>
v2: squash with another patch, minor variable name tweak (Timothy
Arceri)
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
This includes:
* Move the defition of empty_uniform_block to linker_util.h
* Move find_empty_block (with a rename) to linker_util.h
* Refactor some code at linker.cpp to a new method at linker_util.h
(link_util_update_empty_uniform_locations)
So all that code could be used by the GLSL linker and the NIR linker
used for ARB_gl_spirv.
v2: include just "ir_uniform.h" (Timothy Arceri)
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
This is the wrong kind of dirty bit. Caught by GCC warnings, due to
64-bit values being truncated to 32 bits.
Fixes: b95b0e2918 (intel/anv,blorp,i965: Implement the SKL 16x MSAA SIMD32 workaround)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The Vulkan API provides a mechanism for applications to cache their own
shaders and manage on-disk pipeline caching themselves. Generally, this
is what I would recommend to application developers and I've resisted
implementing driver-side transparent caching in the Vulkan driver for a
long time. However, not all applications do this and, for some
use-cases, it's just not practical.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Before, we were only hashing the shader if we had a shader cache to
cache things in. This means that if we ever get it wrong, we could end
up trying to cache a shader with an undefined hash. Since not having a
shader cache is an extremely uncommon case, let's optimize for code
clarity and obvious correctness over avoiding a hash operation.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
