This fixes the same problem as the previous patch did for vdpau, but for
xvmc.
Fixes: 724916c8a8
("meson: dedup gallium-xvmc logic")
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Currently if vdpau is set to auto, it will be disabled only in cases
where gallium is disabled or the host OS is not supported (mac, haiku,
windows). However on (for example) Linux if libvdpau is not installed
then the build will error because of the unmet dependency. This corrects
auto to do the right thing, and not error if libvdpau is not installed.
Fixes: 992af0a4b8
("meson: dedup gallium-vdpau logic")
Signed-off-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
From my point of view, when we aren't able to submit a CS
something terribly wrong happens and we are most likely
going to lost the device.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
the format of the CLEAR_COLOR register doesn't depend on the target format
this fixes clear color when rendering to 32-bit RGBA and 16-bit targets
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@gmail.com>
this patch adds support for a20x, which has some differences with a220:
-no VGT_MAX_VTX_INDX register
-no CLEAR_COLOR register
-set RB_BC_CONTROL in restore (hangs without)
-different CP_DRAW_INDX format
tested with kmscube and glmark2 scenes, on par with a220
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The offset field is 22 bit large.
11 bits are necessary because MaxVertexAttribRelativeOffset = 2047
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@gmail.com>
For a meson -Db_ndebug=true release build on x86_64, reduces text size of
libv3d.a from 53.0k to 51.6k. Inspired by 0d5329d626 ("anv: Disable
__gen_validate_value if NDEBUG is set.")
This is reproducible on Stoney, but other chips may be affected too.
Cc 18.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
All of ARB_gpu_shader5 is most certainly not required for GLES 3.1
(most of it is in OES_gpu_shader5 on top of GLES 3.1).
Some of what is required from ARB_gpu_shader5 is provided by
ARB_texture_gather, so check for that. The remaining subset of
ARB_gpu_shader5 doesn't have individual extensions to check for,
but I guess it is unlikely that some driver has all of these
extensions but not, say, integer bitfield manipulation.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Similar to the combined limit for VS+FS, there is an upper limit for
shader size to run from internel memory.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Previously when setting up a uniform it would try to walk the uniform
storage slots and find one that matches the name of the given
variable. However, each variable already has a location which is an
index into the UniformStorage array so we can just directly jump to
the right slot. Some of the variables take up more than one slot so we
still need to calculate how many it uses.
The main reason to do this is to support ARB_gl_spirv because in that
case the uniforms don’t have names so the previous approach won’t
work.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Right now, the BRW linker code assumes nir_variable::name is always
non-NULL, but thanks to ARB_gl_spirv we will soon be linking SPIR-V
programs, and those explicitly require matching uniforms by location.
The name is just a debug hint.
Instead of checking for the name this patch makes it check for
var->num_state_slots on the assumption that everything that had an
internal name also had some state slots. This seems likely because the
two code paths that are taken when the name begins with "gl_" already
have an assert that var->state_slots is not NULL.
v2: simplified, most of it moved to glsl/nir/spirv (Neil Roberts)
v3: check for num_state_slots instead of the name. This is needed
because we do actually have nameless builtins with SPIR-V such as
PatchVerticesIn and we want them to hit the
_mesa_add_state_reference code path (Neil Roberts)
Signed-off-by: Eduardo Lima <elima@igalia.com>
Signed-off-by: Neil Roberts <nroberts@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Otherwise if the shader is SPIR-V then SamplerUsed won’t have been
initialised yet so it will end up thinking no textures are used. This
was causing a crash later on if nothing causes it to regenerate
TexturesUsed before the next render.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
This function is equivalent to the linker.cpp
build_program_resource_list() but will extract the resources from NIR
shaders instead.
For now, only uniforms and program inputs are implemented.
v2: move from compiler/nir to compiler/glsl (Timothy Arceri)
v3: remove support for inputs, that is still WIP (spotted by Timothy
Arceri)
Signed-off-by: Eduardo Lima <elima@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
So it could be used by the GLSL and NIR linker.
v2: (Timothy Arceri)
* Moved from compiler to compiler/glsl
* Method renamed to link_util_add_program_resource
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
This is based on link_uniform_initializers.cpp.
v2: move from compiler/nir to compiler/glsl (Timothy Arceri)
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
This function will be the entry point for linking the uniforms from
the nir_shader objects associated with the gl_linked_shaders of a
program.
This patch includes initial support for linking uniforms from NIR
shaders. It is tailored for the ARB_gl_spirv needs, and it is far from
complete, but it should handle most cases of uniforms, array
uniforms, structs, samplers and images.
There are some FIXMEs related to specific features that will be
implemented in following patches, like atomic counters, UBOs and
SSBOs.
Also, note that ARB_gl_spirv makes mandatory explicit location for
normal uniforms, so this code only handles uniforms with explicit
location. But there are cases, like uniform atomic counters, that
doesn't have a location from the OpenGL point of view (they have a
binding), but that Mesa assign internally a location. That will be
handled on following patches.
A nir_linker.h file is also added. More NIR-linking related API will
be added in subsequent patches and those will include stuff from Mesa,
so reusing nir.h didn't seem a good idea.
v2: move from compiler/nir to compiler/glsl (Timothy Arceri)
v3: sets var->driver.location if the uniform was found from a previous
stage (Neil Roberts).
Signed-off-by: Eduardo Lima <elima@igalia.com>
Signed-off-by: Neil Roberts <nroberts@igalia.com
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Linker utilities common to the GLSL IR and NIR linker (the latter to
be used for ARB_gl_spirv).
We need to move it to a new header as the NIR linker doesn't need to
know about ir_variable, and others, included at linker.h.
v2: move from src/compiler to src/compiler/glsl (Timothy Arceri)
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
When SpvDecorationBinding is encountered in the SPIR-V source it now
sets explicit_binding on the nir_variable. This will be used to
determine whether to initialise sampler and image uniforms with the
binding value.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
vtn_variable_mode_image and _sampler are instead replaced with
vtn_variable_mode_uniform which encompasses both of them. In the few
places where it was neccessary to distinguish between the two, the
GLSL type of the pointer is used instead.
The main reason to do this is that on OpenGL it is permitted to put
images and samplers into structs and declare a uniform with them. That
means that variables can now have a mix of uniform, sampler and image
modes so picking a single one of those modes for a variable no longer
makes sense.
This fixes OpLoad on a sampler within a struct which was previously
using the variable mode to determine whether it was a sampler or not.
The type of the variable is a struct so it was not being considered to
be uniform mode even though the member being loaded should be sampler
mode.
The previous code appeared to be using var->interface_type as a place
to store the type of the variable without the enclosing array for
images and samplers. I guess this worked because opaque types can not
appear in interfaces so the interface_type is sort of unused. This
patch removes the overloading of var->interface_type and any places
that needed the type without the array can now just deduce it from
var->type.
v2: squash in this patch the changes to anv/nir (Timothy)
Signed-off-by: Eduardo Lima <elima@igalia.com>
Signed-off-by: Neil Roberts <nroberts@igalia.com
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
They are supported by SPIR-V for ARB_gl_spirv.
v2 (changes on top of Nicolai's original patch):
* Handle UniformConstant storage class for uniforms other than
samplers and images. (Eduardo Lima)
* Handle location decoration also for samplers and images. (Eduardo
Lima)
* Rebase update (spirv_to_nir options added, logging changes, and
others) (Alejandro Piñeiro)
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Eduardo Lima <elima@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Vulkan has the concept of separate image and sampler objects in the
SPIR-V code whereas GL conflates them into one. nir_lower_samplers
contains an assert to verify that sampler operand is not being set on
the nir instruction. However when the code comes from spirv_to_nir the
sampler operand is always set. GL_arb_gl_spirv explicitly states that
OpTypeSampler is not supported so it retains the GL behaviour of not
being able to seperate them. Therefore the sampler will always be the
same as the texture. This GL version of the lowering code ignores
instr->sampler and sets instr->sampler_index to the same value as
instr->texture_index. Some other places in the code (such as in
nir_print) assume that once the instruction is lowered then both
instr->texture and instr->sampler will be NULL, so to keep this
behaviour we now set instr->sampler to NULL after ignoring it to fill
in instr->sampler_index.
Signed-off-by: Eduardo Lima <elima@igalia.com>
Signed-off-by: Neil Roberts <nroberts@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
This is copied from the corresponding value in ir_variable. The
intention is to eventually use it in a pure-NIR linker.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Since ARB_gl_spirv name reflection can be missing. piglit
shader_runner does several resource checking, so this commit is useful
to get even the more simple piglit tests running without crashing on
SPIR-V mode.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
This will be used by the linker code to differentiate between programs
made out of SPIR-V or GLSL shaders.
This was rejected in the past, assuming that it was equivalent to
check for "shProg->_LinkedShaders[stage]->spirv_data != NULL". But:
* At some points of the linking process it would be needed to check
if _LinkerShaders[stage] is present, so the full check would be:
"shProg->_LinkedShaders[stage] != NULL &&
shProg->_LinkedShaders[stage]->spirv_data != NULL"
* Sometimes you would like to do some specific to SPIR-V
independently of the stage, or for any stage. For example, "link
all the uniforms, for all stages". In that case checking for the
flag would be equivalent to iterate all the _LinkedShaders and
check if there is any spirv_data available.
The former makes readibility really worse. Both could be solved by
adding two helpers. But adding a flag seems really more simple and
readable.
v2: added justification for the flag on the commit message (Alejandro)
Signed-off-by: Eduardo Lima <elima@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
The current `grep "foo\|bar"' trips on some grep implementations, like
the FreeBSD one. Instead use `egrep "foo|bar"' as suggested by Stefan.
Cc: Stefan Esser <se@FreeBSD.org>
Reported-by: Stefan Esser <se@FreeBSD.org>
Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228673
Fixes: 1914c814a6 ("configure: error out if building OMX w/o supported platform")
Fixes: 63e11ac2b5 ("configure: error out if building VA w/o supported platform")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
With the recent rework of converting the shell script to a python one
the check for actual tests was dropped.
Bring that back, since it was explicitly added considering we had a ~2
year period, during which the tests were not run.
v2: use raise Exception() over print() & return false (Dylan)
Fixes: db8cd8e367 ("glcpp/tests: Convert shell scripts to a python
script")
Cc: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Bring back the "detection" of the said variables, to allow
standalone execution.
Fixes: db8cd8e367 ("glcpp/tests: Convert shell scripts to a python
script")
Cc: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
As of recently both of these have been reworked so they invoke a python
script. At the same time the latter can be executed with the combined
arguments of both scripts.
AKA we no longer need to have them separate.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
As the function says - only the visual is changed.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Dylan Baker
Samuel Pitoiset
Jonathan Marek
Eric Anholt
Marek Olšák
Rob Clark
Eduardo Lima Mitev
Neil Roberts
Alejandro Piñeiro
Nicolai Hähnle
Emil Velikov