I missed the fact that the ARB_fragment_program SWZ instruction allows
per-component negation. To fix this, move Abs/Negate handling into both
the simple case and the SWZ case's per-component loop.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90000
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
The X and Y values come interleaved in g1 (.4-.11 inclusive), so we can
calculate them together with a single add(32) instruction on some
platforms like Broadwell and newer or in SIMD8 elsewhere.
Note that I also moved the PIXEL_X/PIXEL_Y virtual opcodes from before
LINTERP to after it. That's because the writes_accumulator_implicitly()
function in backend_instruction tests for <= LINTERP for determining
whether the instruction indeed writes the accumulator implicitly. The
old FS_OPCODE_PIXEL_X/Y emitted ADD instructions, which did, but the new
opcodes just emit MOVs, which don't. It doesn't matter, since we don't
use these opcodes on Gen4/5 anymore, but in the case that we do...
On Broadwell:
total instructions in shared programs: 7192355 -> 7186224 (-0.09%)
instructions in affected programs: 1190700 -> 1184569 (-0.51%)
helped: 6131
On Haswell:
total instructions in shared programs: 6155979 -> 6152800 (-0.05%)
instructions in affected programs: 652362 -> 649183 (-0.49%)
helped: 3179
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This lets SIMD16 programs on G45 and Gen5 use the PLN instruction.
On Ironlake:
total instructions in shared programs: 5634757 -> 5518055 (-2.07%)
instructions in affected programs: 1745837 -> 1629135 (-6.68%)
helped: 11439
HURT: 4
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
These were used only on Gen4 and 5. emit_interpolation_setup_gen6() emits
ADDs directly. The virtual opcodes weren't providing anything useful.
I'm going to repurpose these opcodes, so deleting and readding them makes
it simpler to see what's going on.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Like LINE (commit 92346db0), src0 must have a scalar region. Setting
src1's region to <8,8,1> lets us pass a properly sized combined delta_xy
argument in a few commits without getting a bogus <16,16,1> region.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
LINTERP's src0 is PLN's src1, and PLN's src1 reads exec_size / 4
registers.
Having that information lets us drop the delta_x/y special case code in
split_virtual_grfs().
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
guess_execution_size() does two things:
1. Cope with small destination registers.
2. Cope with SIMD8 vs SIMD16 mode.
This patch replaces the first with a simple if block in brw_set_dest: if
the destination register width is less than 8, you probably want the
execution size to match. (I didn't put this in the 3src block because
it doesn't seem to matter.)
Since only the FS compiler cares about SIMD16 mode, it's easy to just
set the default execution size there.
This pattern was already been proven in the Gen8+ generator, but we
didn't port it back to the existing generator when we combined the two.
This is based on a patch from Ken from about a year ago. I've rebased it
and and fixed a few bugs.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Consistently just use C99's __func__ everywhere.
No functional changes.
Signed-off-by: Marius Predut <marius.predut@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Consistently just use C99's __func__ everywhere.
No functional changes.
Signed-off-by: Marius Predut <marius.predut@intel.com>
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Commit 34df5eb introduced regression to GetActiveUniformBlockiv
when querying one of the following properties:
GL_UNIFORM_BLOCK_ACTIVE_UNIFORMS
GL_UNIFORM_BLOCK_ACTIVE_UNIFORM_INDICES
Implementation counted all uniforms in ubo directly while query should
check first if the uniform in question is _active_.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90109
Reviewed-By: Martin Peres <martin.peres@linux.intel.com>
On Skylake the qpitch value is uploaded as part of the surface state
so we don't need to add the extra rows that are done for other
generations. However for 3D textures it needs to be aligned to the
tile height and for depth/stencil textures it needs to be a multiple
of 8. Unlike previous generations the qpitch is measured as a multiple
of the block size for compressed surfaces. When the horizontal mipmap
layout is used for 1D textures then the qpitch is measured in pixels
instead of rows.
v2: Align the depth/stencil textures to a multiple of 8
v3: Add an assert that ALL_SLICES_AT_EACH_LOD is not used. Ignore the
vertical alignment when picking the qpitch for 1D_ARRAY textures.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
The render surface state command for Skylake doesn't have the surface
array spacing bit so it's not possible to select this layout. I think
it was only used in order to make it pick a tightly-packed qpitch
value that doesn't include space for the mipmaps. However this won't
be necessary after the next patch because it will automatically pick a
packed qpitch value whenever first_level==last_level. It is better to
remove this layout entirely on Gen8+ because although it can
effectively be implemented with a small qpitch value when there are no
mipmaps it isn't possible to support the case where there are mipmaps
because in that case the layout is very different.
It could be good to make a similar change for Gen8 if we also change
the layouting code to pick the qpitch value in a similar way.
v2: Make the commit message and comments more convincing
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Tested-by: Ben Widawsky <ben@bwidawsk.net>
Clover not longer compile with llvm <= 3.5.0 since e1d363b3.
e1d363b3 implies c++11 and llvm 3.5.0 CXXFLAGS provided it.
No one seems to have noticed it, it's now official.
Acked-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
LLVM removed JITEmitDebugInfo from TargetOptions since they weren't used
v2: Be consistent with the LLVM version check (Aaron Watry)
Signed-off-by: Nick Sarnie <commendsarnex@gmail.com>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
This allows drivers to provide consistent flat shading for quads.
Otherwise a driver that only supported tris would have to force last
provoking vertex when drawing quads (and would have to say that quads
don't follow the provoking vertex convention).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
This should match to how drivers program hardware. flatshade relates to
whether color inputs are interpolated, not the provoking vertex
convention.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Rob Clark <robclark@freedesktop.org>
We haven't implemented proper unsynchronized map support on !LLC systems
(pre-SNB, Atom). MapBufferRange with GL_MAP_UNSYNCHRONIZE_BIT will
actually do a synchronized map, probably killing performance.
Also warn on BufferSubData, when we should be doing an unsynchronized
upload, but instead have to do a synchronous map.
v2: Only complain if the buffer is actually busy - we use unsynchronized
maps internally for vertex upload and such, but expect those to not
be busy.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Tested-by: Ben Widawsky <ben@bwidawsk.net>
Jason noticed that shader_time was bumping the reference count on the
gl_shader_program and gl_program structures, in code called during
compilation.
Not only were these never unreferenced, but it meant fragment shaders
might be referenced twice (SIMD8 and SIMD16)...or only once.
We don't actually need the programs. We just need their numeric ID and
their language (GLSL/ARB/FF) or KHR_debug label. If there's a label, we
have to strdup it since the underlying program could be deleted.
To be fair, we're not exactly cleaning that up either, but we at least
ralloc it out of the shader_time arrays, so if we ever bother cleaning
those up, they'll go away properly.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
It is true that a gl_shader_program with ID 0 will be a fixed-function
fragment program; a gl_program with ID 0 but NULL gl_shader_program
means that it's a fixed-function vertex shader.
But that's not terribly interesting or relevant to what we're doing.
We just need to know that ID 0 means "fixed function".
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
0 is not a valid GLSL shader or ARB program ID. For some reason,
shader_time used -1 instead...so we had code to detect 0, then override
it to -1.
We can just delete that.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
This enables using _mesa_meta_pbo_TexSubImage() to upload data
to R16G16B16X16 texture. Earlier it fell back to slower paths.
Jenkins run shows no piglit regressions.
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
SEL and MOV instructions, as long as they don't have source modifiers, are
just copying bits around. This commit adds support to copy propagation to
switch the type of a SEL or MOV instruction as needed so that it can
propagate source modifiers. This is needed because NIR generates integer
SEL and MOV instructions whenver it doesn't know what else to generate.
shader-db results with NIR:
total FS instructions in shared programs: 4360910 -> 4360186 (-0.02%)
FS instructions in affected programs: 59094 -> 58370 (-1.23%)
helped: 341
HURT: 0
GAINED: 2
LOST: 0
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
There can be problems with floats and conditional modifiers when
copy-propagating a negated UD source. The problem arises when a source
modifier is applied to a UD value. In this case, a 33-bit representation
is internally used. If you do the following:
1: mov foo:UD 7U
2: mov bar:UD -foo:UD
3: mov out:F bar:UD
the out register will have the value (float)(unt32_t)-7 which is some very
large floating-point number. However, if we allow copy-propagation of the
second mov, we get
1: mov foo:UD 7U
3: mov out:f -bar:UD
and, since the negation is computed in 33-bits, we get a value of -7.0f
which is clearly not the same. This is a similar problem if the
instruction has a conditional modifier where the 33-bit value is used in
the comparison and not the 32-bit version.
Previously, we checked the source to be copied for the negate and then
checked the source being propagated to for the type. This isn't quite what
we want because we are really just looking for negated UD sources. A check
later in the file ensures that both ends of the propagate have the right
type so it works. However, if we relax the restriction that both ends of
the propagation have the same type, it ends up causing us to bail early in
cases we don't want.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
isaml needs to scale up coords based on LoD. Also fix bogus bary.f
varying # when there are non-bary frag shader inputs. And use sub.s of
a positive immediate rather than add.s of negative (since CP is better
about figuring out that those can be collapsed into the cat2 instr).
Signed-off-by: Rob Clark <robclark@freedesktop.org>
For now, completely flatten if/else blocks. That will almost certainly
change once we have flow control.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Basically just sync up the cmdstream emit parts to match the changes
already done on a3xx.
Also, fix scheduling for mem instructions. This is needed on a4xx, and
I am a bit surprised it isn't needed for a3xx.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Kenneth Graunke
Tapani Pälli
Matt Turner
Marius Predut
Neil Roberts
EdB
Dave Airlie
Nick Sarnie
Ian Romanick
Ilia Mirkin
Connor Abbott
Tobias Nygren
Anuj Phogat
Jason Ekstrand
Rob Clark