This could have led to somewhat increased bandwidth usage for lowered
texturing instructions on Gen4 (which is the only case in which
lower_width may be greater than inst->exec_size). After the previous
patches the invariant mentioned in the comment should no longer be
assumed by any of the other optimization and lowering passes, so the
exec_all() call shouldn't be necessary anymore.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Instead of relying on the default one. This shouldn't lead to any
functional changes because DEP_RESOLVE_MOV overrides the execution
size of the instruction anyway and other execution controls are
irrelevant.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
The global CSE pass stinks and is unable to pull this out. Easy enough
to handle it here and avoid generating unnecessary special register
loads (which can allegedly be quite slow).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
PFETCH retrieves the address for incoming vertices, not output vertices
in TCS. For output vertices, we must use the laneid as a base.
Fixes barrier piglit test, which was failing for entirely non-barrier
reasons, but rather that it was (a) trying to draw multiple patches and
(b) the incoming patch size was not the same as the outgoing patch size.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This reverts commit a27ec5dc46. It
breaks the intended behaviour of pipe_loader_probe() with ndev==0 as
relied upon by clover to query the number of devices available to the
pipe loader in the system.
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
opt_sampler_eot() was relying on the default builder to have the same
width as the sampler and FB write opcodes it was eliminating, the
channel selects didn't matter because the builder was only being used
to allocate registers, no new instructions were being emitted with it.
A future commit will change the width of the default builder what will
break this assumption, so initialize it explicitly here.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This wasn't taking into account the execution controls of the original
instruction, but it was most likely not a bug because control flow
instructions are typically full width.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Emit the SELs and MOVs with the same execution controls as the
original MOVs, and the CMP with the same execution controls as the IF.
Also explicitly check that the execution controls of any pair of MOVs
being folded into a SEL are compatible (which is almost always going
to be the case), since otherwise it would seem wrong to initialize the
builder object below from the then_mov instruction only.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
lower_integer_multiplication() was ignoring the execution controls of
the original MUL instruction. Fix it by using the new fs_builder
constructor.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
demote_pull_constants() was ignoring the execution size and channel
selects of the instruction that wanted the constant, which doesn't
matter for uniform pull constant loads because all channels get the
same scalar value, but it might for varying pull constant loads. Fix
it by using the new fs_builder() constructor that takes care of
setting execution controls compatible with the instruction passed as
argument.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
The execution size was being left equal to the default of 8/16, which
AFAICT would have overwritten components other than the one we wanted
to initialize and could potentially have corrupted other registers.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
We have a number of optimization passes that repeat the same pattern
before inserting new instructions into the program based on some
previous instruction: They point the default builder at the original
instruction, then call exec_all() and group() to select the same
execution controls the original instruction had, and then maybe call
annotate() to clone the debug annotation from the original
instruction.
In fact an optimization pass missing any of these steps is likely to
be broken if the intention was to emit new code based on a preexisting
instruction, so let's make it easy for passes to do the right thing by
having an fs_builder constructor that automates the task of setting up
a builder to emit a given instruction provided as argument.
The following patches fix all cases I've found in which we weren't
explicitly initializing the execution controls of the emitted
instructions, and clean-up optimization passes which were already
doing the right thing to use the new constructor.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Images take up zero uniform slots in the nir_shader::num_uniforms
calculation, but nir_setup_uniforms needs to be executed even if the
program has no non-image uniforms so the driver-specific image
parameters are uploaded. nir_setup_uniforms is a no-op if there are
really no uniforms, so checking the num_uniform count is useless in
any case.
The nir_setup_inputs and _outputs changes shouldn't lead to any
functional change, they are just meant to preserve the symmetry
between them and nir_setup_uniforms.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Image variables need to allocate additional uniform slots over
nir_shader::num_uniforms. nir_setup_uniforms() overwrites the values
imported from the SIMD8 visitor and then exits early before entering
the nir_shader::uniforms loop, so image uniforms are never re-created.
Instead leave the imported values alone, they *must* be the same for
the uniform layout of both runs to be compatible.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Rewrite the NIR atomic counter intrinsics translation code making use
of the recently introduced surface builder. This will allow the
removal of some of the functionality duplicated between the visitor
and surface builder.
v2: Drop VEC4 suport.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Implement helper functions that can be used to construct and send
untyped and typed surface read, write and atomic messages to the
shared dataport unit easily.
v2: Drop VEC4 suport.
v3: Reimplement in terms of logical send opcodes.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This will be handy to avoid some ugly ternary operators in the next
patch, like:
fs_reg reg = (size == 0 ? null_reg_ud() : vgrf(..., size));
Because a zero-size register allocation is guaranteed not to ever be
read or written we can just return the null register. Another
possibility would be to actually allocate a zero-size VGRF what would
involve defining a zero-size register class in the register allocator
and a considerable amount of churn.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Each logical variant is largely equivalent to the original opcode but
instead of taking a single payload source it expects its arguments
separately as individual sources, like:
typed_surface_write_logical null, coordinates, source, surface,
num_coordinates, num_components
This patch defines the opcodes and usual instruction boilerplate,
including a placeholder lowering function provided mainly as
documentation for their source registers.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This cleans up the VEC4 implementation of setup_uniform_values()
somewhat and will avoid duplication of the image uniform upload code
by having a common interface to upload a vector of uniforms on either
back-end.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This should match the set of cases in which we currently call fail()
or no16() from the emit_texture_*() methods and the ones in which
emit_texture_gen4() enables the SIMD16 workaround.
Hint for reviewers: It's not a big deal if I happen to have missed
some case here, it will just lead to an assertion failure down the
road which is easily fixable, however being stricter than necessary
won't cause any visible breakage, it would just decrease performance
silently due to the unnecessary message splitting, so feel free to
double-check that all cases listed here already cause a SIMD8/16
fall-back with the current texturing code -- You may want to skip over
the Gen5-6 cases though if you don't have pencil and paper at hand.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Unlike its Gen5 and Gen7 counterparts this patch isn't a plain
refactor of the previous Gen4 texturing code, it's more of a rewrite
largely based on emit_texture_gen4_simd16(). The reason is that on
the one hand the original emit_texture_gen4() code didn't seem easily
fixable to be SIMD width-invariant and had plenty of clutter to
support SIMD-width workarounds which are no longer required. On the
other hand emit_texture_gen4_simd16() was missing a number of
SIMD8-only opcodes. This should generalize both and roughly match
their current behaviour where there is overlap.
Incidentally this will fix the following piglits on Gen4:
arb_shader_texture_lod.execution.arb_shader_texture_lod-texgrad
arb_shader_texture_lod.execution.tex-miplevel-selection *gradarb 2d
arb_shader_texture_lod.execution.tex-miplevel-selection *gradarb 3d
arb_shader_texture_lod.execution.tex-miplevel-selection *projgradarb 2d
arb_shader_texture_lod.execution.tex-miplevel-selection *projgradarb 2d_projvec4
arb_shader_texture_lod.execution.tex-miplevel-selection *projgradarb 3d
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This should be largely equivalent to emit_texture_gen5() except for
slight codestyle changes and the use i965 opcodes instead of the
ir_texture_opcode enum, see "i965/fs: Implement lowering of logical
texturing opcodes on Gen7+." for the mapping between them.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These weren't being handled by emit_texture_gen7() but we can easily
lower them here for consistency with other texturing opcodes.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This should be largely equivalent to emit_texture_gen7() except that
we now get i965 sampling opcodes directly rather than
ir_texture_opcode enum values. The mapping is as follows:
- ir_tex -> SHADER_OPCODE_TEX
- ir_txb -> FS_OPCODE_TXB
- ir_txl -> SHADER_OPCODE_TXL
- ir_txd -> SHADER_OPCODE_TXD
- ir_txf -> SHADER_OPCODE_TXF
- ir_txf_ms -> SHADER_OPCODE_TXF_CMS
- ir_txs -> SHADER_OPCODE_TXS
- ir_query_levels -> SHADER_OPCODE_TXS too, the visitor will make
sure that the provided lod value is zero in this
case.
- ir_lod -> SHADER_OPCODE_LOD
- ir_tg4 -> SHADER_OPCODE_TG4_OFFSET if the offset value is not
immediate, SHADER_OPCODE_TG4 otherwise.
Other than that there are only minor changes and style fixes like the
implementation now being factored out in static functions to improve
encapsulation.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This hasn't been overallocating space for the header for a long time.
It still leaves the header uninitialized though until the generator
fixes it.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
So that it's left uninitialized by LOAD_PAYLOAD, we only need to
reserve space for it in the message since it will be initialized
implicitly by the generator.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
dispatch_width is global for a single compilation and doesn't
necessarily match the desired execution width if we had to lower the
original full-width instruction due to hardware limitations. These
were all inside a Gen4-specific branch so this patch shouldn't have
any effect on more recent hardware.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Each logical variant is largely equivalent to the original opcode but
instead of taking a single payload source it expects the arguments
separately as individual sources, like:
tex_logical dst, coordinates, shadow_c, lod, lod2,
sample_index, mcs, sampler, offset,
num_coordinate_components, num_grad_components
This patch defines the opcodes and usual instruction boilerplate,
including a placeholder lowering function provided mostly as
documentation for their source registers.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The only non-trivial thing it still has to do is figure out where to
take the src/dst depth values from and predicate the instruction if
discard is in use. The manual SIMD unrolling logic in the dual-source
case goes away because this is now handled transparently by the SIMD
lowering pass.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
This does essentially the same thing as
fs_visitor::emit_single_fb_write(), with some slight differences:
- We don't have to worry about exec_size and use_2nd_half anymore,
16-wide sources have already been lowered to 8-wide thanks to the
previous commit and the manual argument unzipping is no longer
required.
- The src/dst_depth and sample_mask values are now explicit sources
of the instruction instead of being taken from the visitor state
directly. The same goes for the kill-pixel mask that will be
passed to the instruction explicitly as predicate.
- Everything is now done in static functions to improve
encapsulation.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
This shouldn't have any effect because we don't emit logical
framebuffer writes yet.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
There's no need to initialize the wrong half of oMask in the payload
when we're doing an 8-wide framebuffer write because it will be
ignored by the hardware anyway. By doing it this way we can let the
SIMD lowering pass split the sample_mask source as a regular
per-channel source, otherwise we would have to introduce some sort of
per-instruction source query or use fs_inst::header_size for the
lowering pass to be able to find out whether some source is
header-like, and leave the source untouched in that case.
As a bonus this achieves the same purpose as the previous code without
making use of the SET_OMASK pseudo-instruction, which will be removed
in a future commit.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Flatten the if ladder to match the way that the ordering of these
fields is specified in the hardware documentation a bit more closely.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Francisco Jerez