This will allow us to continue searching the current path for
relative shader includes.
From the ARB_shading_language_include spec:
"If it is quoted with double quotes in a previously included
string, then the first search point will be the tree location
where the previously included string had been found."
Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com>
If the shader contains an include when need to first run the
preprocessor before deciding if we can skip compilation based
on the shader cache.
Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com>
From the ARB_shading_language_include spec:
"#line must have, after macro substitution, one of the following
forms:
#line <line>
#line <line> <source-string-number>
#line <line> "<path>"
where <line> and <source-string-number> are constant integer
expressions and <path> is a valid string for a path supplied in the
#include directive. After processing this directive (including its
new-line), the implementation will behave as if it is compiling at
line number <line> and source string number <source-string-number>
or <path> path. Subsequent source strings will be numbered
sequentially, until another #line directive overrides that
numbering."
Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com>
The new local function lookup_shader_include() will be used by
glDeleteNamedStringARB() in the following patch.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com>
This will be usefull when implementing glIsNamedStringARB() which
doesn't do error checking, it just returns false for invalid
lookups instead.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com>
This will be used by the various ARB_shading_language_include
functions in the following patches.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com>
This will be used both by the glsl compiler and the GL API.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Witold Baryluk <witold.baryluk@gmail.com>
When the scratch ringbuffer settings are changed, the shader unit has
to be idle or we will have shaders using old and new settings.
That combination is not supported on the HW (likely the offset is
ringbuffer idx * WAVESIZE * 1024).
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Now that we can (mostly) generate a pipe format for a VkFormat, use that
to answer queries about formats. This will let us refactor the freedreno
format table surface layout code to be shared between gallium and vulkan.
This causes us to expose fewer formats for now (on a 1/100 CTS run I'm
doing, skips go from 3671 to 3835 out of 5145 tests). Fails stay about
the same (478 -> 434, but the run is pretty flaky and we're doing fewer
tests now).
v2: Rebase on master, throw a finishme on missing vk-to-pipe formats that
tu used to support.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> (v1)
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
I'm planning on using this from radv and tu for queries about formats.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
This decreases memory usage, because serialized NIR is more compact.
If shader_has_one_variant is true and the shader is uncached, the first
variant is created from nir_shader, otherwise the first variant and
all other variants are created from serialized NIR.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
a later commit will add back st_vertex_program as a subclass of
st_common_program
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
This matches the uncached codepath.
affected_states was used before initialization, which was technically
a bug, but probably not reproducible due to _NEW_PROGRAM rebinding
everything.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
