This error condition is not implementable when using tessellation or
geometry shaders. The text was also removed from the ES 3.2 spec.
I believe the intended behavior is to remove the error condition
when either OES_geometry_shader or OES_tessellation_shader are
exposed.
v2: Quote a better part of issue 13 (suggested by Ian).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Mostly, I want to share the GLES 3 transform feedback handling,
though most of the rest of the code is identical as well.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This makes them available in the GLES 3.1 API.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Also update _mesa_has_tessellation to know about the new extensions.
For now, these are dummy_false, to avoid turning on the extension
until everything's in place. Eventually, we'll move them over to
the "ARB_tessellation_shader" bit so that any drivers supporting
both the desktop extension and ES 3.1 get the feature.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
The OES_tessellation_shader and EXT_tessellation_shader specifications
have suffixed names. These are identical to the core function, so just
alias them.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Prefer to use DRAW_(INDEX)_INDIRECT_MULTI when available in the firmware.
Versions for SI and CI already added as provided by the firmware team, but
keep in mind that they won't currently be used since the radeon kernel module
has no interface to query the firmware version.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The radeon kernel module doesn't have the firmware query interface, so the
corresponding values will remain 0.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Overriding it is not allowed anyway, and actually lead to a crash when polygon
stippling was used with monolithic shaders.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
These are largely identical, except that the GS version has a few
extra error conditions. We can just pass in the stage and skip these.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We need to subtract VARYING_SLOT_PATCH0, not VARYING_SLOT_VAR0.
Since "patch" only applies to inputs and outputs, we can just handle
this once outside the switch statement, rather than replicating the
check twice and complicating the earlier conditions.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
These are lowered to gl_TessLevel{Outer,Inner}MESA. We need them to
appear in the program resource list with their original names and types.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This assertion is bogus. Varying structs, and arrays of structs, are
allowed by GLSL, and we can see them here. While we currently don't
have any partial-variable support for those, simply returning false
and marking the entire thing as used is certainly legitimate.
I believe this is often swept under the rug by varying packing,
but that's disabled in certain tessellation situations.
Hit by 20 dEQP-GLES31.functional.tessellation.user_defined_io.* tests.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
This better matches the grammar in section 4.3.9 of the GLSL 4.5 spec,
and also removes some redundant code.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Similar to has_geometry_shader(), has_compute_shader(), and so on.
This will make it easier to add more conditions here later.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
They can only be run manually as described in HOW_TO_RUN.
It should help catch suboptimal code generation.
Some of the tests already fail.
v2: rename the tests to *.glsl,
fix lit.cfg to find FileCheck
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
This will be used by GLSL lit tests.
For developers only. It shouldn't be distributable and it doesn't use
the Mesa build system.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This will be used by: amdgcn_glslc -mcpu=[family]
It can also be used for shader-db if you want stats for a different family.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
On gl{Push,Pop}Attrib(GL_CLIENT_VERTEX_ARRAY_BIT) take
care that gl_vertex_array_object::VertexAttribBufferMask
matches the bound buffer object in the
gl_vertex_array_object::VertexBinding array.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Fredrik Höglund <fredrik@kde.org>
According to the IVB PRM Vol2 P1, this bit must be set if a pixel shader
contains a discard instruction.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97207
Cc: "12.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Both the rgb9e5 and r11g11b10 formats are defined based on how they are
packed into a 32-bit integer. It makes sense that the functions that
manipulate them take an explicitly sized type.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
There are a number of reasons for this refactor. First, format_rgb9e5.h is
not something that a user would expect to define such a generic union.
Second, defining it requires checking for endianness which is ugly. Third,
90% of what we were doing with the union was float <-> uint32_t bitcasts
and the remaining 10% can be done with a sinmple left-shift by 23.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
The rgb9e5 format is a packed format defined in terms of slicing up a
single 32-bit value. The bitfields are far more confusing than simple
shifts and require that we check the endianness.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Jason Ekstrand
Kenneth Graunke
Nicolai Hähnle
Marek Olšák
Mathias Fröhlich
Nanley Chery