With the exception of always-taken switch cases (which are
indistinguishable from straight line code in our IR), this
disallows use of the builtin barrier() function in all the
places it may not appear.
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tessellation control outputs can be read in directly without first
having been written. Accessing these will require some special logic
anyways, so just let them through.
V2: Never lower tess control output reads, whether patch or not -- both
can be read back by other threads.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is technically not needed, but it makes the compiler return a better
error message if tessellation is used with GLSL < 1.50.
Instead of:
error: syntax error, unexpected NEW_IDENTIFIER, expecting $end
It returns:
error: #version 150 layout qualifier `triangles' used
And the tessellation spec says:
OpenGL 3.2 and GLSL 1.50 are required.
So it makes perfect sense.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There is no way to lower them, because the array sizes are unknown
at compile time.
Based on a patch from: Fabian Bieler <fabianbieler@fastmail.fm>
v2: add comments
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
This is to prevent a name conflict in tessellation shaders built-in interface
blocks.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Similar to gl_ClipDistance -> gl_ClipDistanceMESA
v2: - renamed is_mesa_var to lowered_builtin_array_variable
- moved LowerTessLevel into gl_constants
- cosmetic changes in lower_tess_level.cpp
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Marek: require a tess eval shader if a tess control shader is present
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Tessellation dependencies added by Marek.
v2: require tessellation in addition to atomics/images for some glGet queries
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This has been a no-op due to performance concerns. From now on, drivers
should decide when they don't want to unmap, not the winsys.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
buffer_unmap is currently a no-op on radeon and done correctly on amdgpu.
I plan to fix it for radeon, but before that, all occurences of buffer_unmap
that can negatively affect performance in the future must be removed.
There are 2 reasons for removing buffer_unmap calls:
- There is a likelihood that buffer_map will be called again, so we don't
want to unmap yet.
- The buffer is being released, which automatically unmaps it.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>