The Nvidia/AMD binary drivers allow this, as does GCC.
This fixes shader compilation issues in the latest update of
No Mans Sky.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
>From Section 6.1.2 (Subroutines) of the GLSL 4.00 specification
"A program will fail to compile or link if any shader
or stage contains two or more functions with the same
name if the name is associated with a subroutine type."
v2:
- error out earlier (Tapani)
- style fixes (Iago)
Fixes:
* no-overloads.vert
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108109
Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
do_assignment validated assigment but when rhs type was not compatible
it proceeded without issues and returned error_emitted = false.
On the other hand process_initializer expected do_assignment to always
return compatible type and never fail.
As a result when variable was initialized with incompatible type
the type of variable changed to the incompatible one.
This manifested in unnecessary error messages and in one case in crash.
Example GLSL:
vec4 tmp = vec2(0.0);
tmp.z -= 1.0;
Past error messages:
initializer of type vec2 cannot be assigned to variable of type vec4
invalid swizzle / mask `z'
type mismatch
operands to arithmetic operators must be numeric
After this patch:
initializer of type vec2 cannot be assigned to variable of type vec4
In the other case when we initialize variable with incompatible struct,
accessing variable's field leaded to a crash. Example:
uniform struct {float field;} data;
...
vec4 tmp = data;
tmp.x -= 1.0;
After the patch there is only error line without a crash:
initializer of type #anon_struct cannot be assigned to variable of
type vec4
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547
From Section 4.6.4 (Invariance and Linkage) of the GLSL ES 1.0 specification
"The invariance of varyings that are declared in both the vertex and
fragment shaders must match. For the built-in special variables,
gl_FragCoord can only be declared invariant if and only if
gl_Position is declared invariant. Similarly gl_PointCoord can only
be declared invariant if and only if gl_PointSize is declared
invariant. It is an error to declare gl_FrontFacing as invariant.
The invariance of gl_FrontFacing is the same as the invariance of
gl_Position."
Fixes:
* glsl-pcoord-invariant.shader_test
* glsl-fcoord-invariant.shader_test
* glsl-fface-invariant.shader_test
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107734
Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
and _mesa_bitcount_64 with util_bitcount_64. This fixes a build problem
in nir for platforms that don't have popcount or popcountll, such as
32bit msvc.
v2: - Fix additional uses of _mesa_bitcount added after this was
originally written
Acked-by: Eric Engestrom <eric.engestrom@intel.com> (v1)
Acked-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
It was very inconsistently handled; the only things that made use of it
were glsl_to_nir, glspirv, and nir_gather_info. In particular,
nir_lower_io completely ignored it so anyone using nir_lower_io on
64-bit vertex attributes was going to be in for a shock. Also, as of
the previous commit, it's set by every driver that supports 64-bit
vertex attributes. There's no longer any reason to have it be an option
so let's just delete it.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Previously, we had two field in shader_info: double_inputs_read and
double_inputs. Presumably, the one was for all double inputs that are
read and the other is all that exist. However, because nir_gather_info
regenerates these two values, there is a possibility, if a variable gets
deleted, that the value of double_inputs could change over time. This
is a problem because double_inputs is used to remap the input locations
to a two-slot-per-dvec3/4 scheme for i965. If that mapping were to
change between glsl_to_nir and back-end state setup, we would fall over
when trying to map the NIR outputs back onto the GL location space.
This commit changes the way slot re-mapping works. Instead of the
double_inputs field in shader_info, it adds a DualSlotInputs bitfield to
gl_program. By having it in gl_program, we more easily guarantee that
NIR passes won't touch it after it's been set. It also makes more sense
to put it in a GL data structure since it's really a mapping from GL
slots to back-end and/or NIR slots and not really a NIR shader thing.
Tested-by: Alejandro Piñeiro <apinheiro@igalia.com> (ARB_gl_spirv tests)
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
If we have something like:
#ifdef NOT_DEFINED
#define A_MACRO(x) \
if (x)
#endif
The # on the #define is not skipped but the define itself is so
this then gets recognised as #if.
Until 28a3731e3f this didn't happen because we ended up in
<HASH>{NONSPACE} where BEGIN INITIAL was called stopping the
problem from happening.
This change makes sure we never call RETURN_TOKEN_NEVER_SKIP for
if/else/endif when processing a define.
Cc: Ian Romanick <idr@freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107772
Tested-By: Eero Tamminen <eero.t.tamminen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
With compat creeping up to geometry and tess shaders, lowering texcoord
accesses/writes becomes more complicated. Since it's an optimization
anyways, just avoid the complication for now.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
The spec is quite clear this is not allowed:
From Section 4.4. (Layout Qualifiers) of the GLSL 4.60 spec:
"Layout qualifiers can appear in several forms of declaration.
They can appear as part of an interface block definition or
block member, as shown in the grammar in the previous section.
They can also appear with just an interface-qualifier to establish
layouts of other declarations made with that qualifier:
layout-qualifier interface-qualifier ;
Or, they can appear with an individual variable declared with
an interface qualifier:
layout-qualifier interface-qualifier declaration ;"
From Section 4.10 (Memory Qualifiers) of the GLSL 4.60 spec:
"Layout qualifiers cannot be used on formal function parameters,
and layout qualification is not included in parameter matching."
However on the Nvidia binary driver they actually fail to compile
if image function params don't have a layout qualifier. This results
in applications such as No Mans Sky using layout qualifiers on params.
I've submitted a CTS test to expose this problem in the Nvidia driver
but until that is resolved this patch will help Mesa drivers work
around the issue.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This fixes compilation of some "No Mans Sky" shaders where the stringification
happens in branches intended for DX12.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This commit expands the current memory access enum to contain the extra
two bits provided for images. We choose to follow the SPIR-V convention
of NonReadable and NonWriteable because readonly implies that you *can*
read so readonly + writeonly doesn't make as much sense as NonReadable +
NonWriteable.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The GLSL spec allows you to set both the "readonly" and "writeonly"
qualifiers on images to indicate that it can only be used with
imageSize. However, we had no way of representing this int he linked
shader and flagged it as GL_READ_ONLY. This is good from a "does it use
this buffer?" perspective but not from a format and access lowering
perspective. By using GL_NONE for if "readonly" and "writeonly" are
both set, we can detect this case in the driver and handle it correctly.
Nothing currently relies on the type of surface in the "readonly" +
"writeonly" case but that's about to change. i965 is the only drier
which uses the ImageAccess field and gl_bindless_image::access is
currently unused.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Instead of requiring 4 components, this allows them to potentially use
fewer. Both the SPIR-V and GLSL paths still generate vec4 intrinsics so
drivers which assume 4 components should be safe. However, we want to
be able to shrink them for i965.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This extension provides new GLSL built-in function
beginFragmentShaderOrderingIntel() that guarantees
(taking wording of GL_INTEL_fragment_shader_ordering
extension) that any memory transactions issued by
shader invocations from previous primitives mapped to
same xy window coordinates (and same sample when
per-sample shading is active), complete and are visible
to the shader invocation that called
beginFragmentShaderOrderingINTEL().
One advantage of INTEL_fragment_shader_ordering over
ARB_fragment_shader_interlock is that it provides a
function that operates as a memory barrie (instead
of a defining a critcial section) that can be called
under arbitary control flow from any function (in
contrast the begin/end of ARB_fragment_shader_interlock
may only be called once, from main(), under no control
flow.
Signed-off-by: Kevin Rogovin <kevin.rogovin@intel.com>
Reviewed-by: Plamena Manolova <plamena.manolova@intel.com>
>From Section 4.3.4 (Inputs) of the GLSL 1.50 spec:
"Only the input variables that are actually read need to be written
by the previous stage; it is allowed to have superfluous
declarations of input variables."
Fixes:
* interstage-multiple-shader-objects.shader_test
v2:
Update comment in ir.h since the usage of "used" field
has been extended.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101247
Signed-off-by: Vadym Shovkoplias <vadym.shovkoplias@globallogic.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
This reverts commit ae7898dfdb.
Turns out the python scripts are _not_ fully python 3 compatible.
As Ilia reported using get_xmlpool.py with LANG=C produces some weird
output - see the link for details.
Even though the issue was spotted with the autoconf build, it exposes a
genuine problem with the script (and lack of lang handling of the meson
build.)
https://lists.freedesktop.org/archives/mesa-dev/2018-August/203508.html
because the closed driver exposes it.
It's equivalent to ARB_gpu_shader_int64.
In this patch, I did everything the same as we do for ARB_gpu_shader_int64.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Pretty much all of the scripts are python2+3 compatible.
Check and allow using python3, while adjusting the PYTHON2 refs.
Note:
- python3.4 is used as it's the earliest supported version
- python3 chosen prior to python2
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Eric Engestrom <eric.engestrom@intel.com>
Just like the rest of the tree - these should be run either as part of
the build system check target, or at the very least with an explicitly
versioned python executable.
Fixes: db8cd8e367 ("glcpp/tests: Convert shell scripts to a python script")
Fixes: 97c28cb082 ("glsl/tests: Convert optimization-test.sh to pure python")
Fixes: 3b52d29227 ("glsl/tests: reimplement warnings-test in python")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
We are testing the behaviour of a tool, for different input files, each
one using a different newline sequence. ('\n' on UNIX, '\r\n' on
Windows, …)
Unfortunately, when opening a file in text mode, Python 3 will by
default enable the "universal newlines" mode, which means it replaces
all the known newline sequences by '\n'.
This (usually useful) behaviour breaks the tests, which are specifically
trying to handle files with newline sequences different from '\n'.
Disabling the universal newlines mode fixes the tests.
However, to keep the script compatible with both Python 2 and 3, we must
use the io.open() function instead of the open() builtin, as the latter
only knows about the `newline` argument on Python 3.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Python 3 does not automatically convert from bytes to unicode strings
like Python 2 used to do.
This commit makes sure we pass unicode strings to difflib.unified_diff,
so that the script works on both Python 2 and 3.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
v2: - explicitly decode the output of subprocesses
- handle bytes and string types consistently rather than relying on
python 2's coercion for bytes and ignoring them in python 3
v3: - explicitly set encode as well as decode
- python 2.7 and 3.x `bytes` instead of defining an alias
Reviewed-by: Mathieu Bridon <bochecha@daitauha.fr>
The main purpose for having NV_fragment_shader_interlock
extension is because that extension is also for GLES31 while
the ARB extension is for GL only.
Reviewed-by: Plamena Manolova <plamena.manolova@intel.com>
After commit "nir: Use derefs in nir_lower_samplers"
(75286c2d08) assumes one deref for both
the texture and the sampler. However there are cases (on OpenGL, using
ARB_gl_spirv) where SPIR-V is not providing a sampler, like for
texture query levels ops. Although we could make spirv_to_nir to
provide a sampler deref for those cases, it is not really needed, and
wrong from the Vulkan point of view.
This patch fixes the following (borrowed) tests run on SPIR-V mode:
arb_compute_shader/execution/basic-texelFetch.shader_test
arb_gpu_shader5/execution/sampler_array_indexing/fs-simple-texture-size.shader_test
arb_texture_query_levels/execution/fs-baselevel.shader_test
arb_texture_query_levels/execution/fs-maxlevel.shader_test
arb_texture_query_levels/execution/fs-miptree.shader_test
arb_texture_query_levels/execution/fs-nomips.shader_test
arb_texture_query_levels/execution/vs-baselevel.shader_test
arb_texture_query_levels/execution/vs-maxlevel.shader_test
arb_texture_query_levels/execution/vs-miptree.shader_test
arb_texture_query_levels/execution/vs-nomips.shader_test
glsl-1.30/execution/fs-textureSize-compare.shader_test
v2: merge lower_tex_src_to_offset and calc_sampler_offsets together,
update texture/sampler index and texture_array_size directly on
lower_tex_src_to_offset (Jason)
v3: clarify one comment (Jason)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
So they are not exposed through the introspection API.
It is worth to note that the number of hidden uniforms of GLSL linking
vs SPIR-V linking would be somewhat different due the differen order
of the nir lowerings/optimizations.
For example: gl_FbWposYTransform. This is introduced as part of
nir_lower_wpos_ytransform. On GLSL that is executed after the IR-based
linking. So that means that on GLSL the UniformStorage will not
include this uniform. With the SPIR-V linking, that uniform is already
present, but marked as hidden. So it will be included on the
UniformStorage, but as hidden.
One alternative would create a special how_declared for that case, but
seemed an overkill. Using hidden should be ok as far as it is used
properly.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Now that all the build scripts are compatible with both Python 2 and 3,
we can flip the switch and tell Meson to use the latter.
Since Meson already depends on Python 3 anyway, this means we don't need
two different Python stacks to build Mesa.
Signed-off-by: Mathieu Bridon <bochecha@daitauha.fr>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Fixes new piglit test:
tests/spec/glsl-1.20/execution/qualifiers/vs-out-conversion-int-to-float-vec4-index.shader_test
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
