So far we only used instructions with this size in situations where we
did not operate per-channel and we wanted to ignore the execution mask,
but gen7 fp64 will need to emit code with a width of 4 that needs
normal execution masking.
v2:
- Modify the assert instead of deleting it (Curro)
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
In fp64 we can produce code like this:
mov(16) vgrf2<2>:UD, vgrf3<2>:UD
That our simd lowering pass would typically split in instructions with a
width of 8, writing to two consecutive registers each. Unfortunately, gen7
hardware has a bug affecting execution masking and as a result, the
second GRF register write won't work properly. Curro verified this:
"The problem is that pre-Gen8 EUs are hardwired to use the QtrCtrl+1
(where QtrCtrl is the 8-bit quarter of the execution mask signals
specified in the instruction control fields) for the second
compressed half of any single-precision instruction (for
double-precision instructions it's hardwired to use NibCtrl+1,
at least on HSW), which means that the EU will apply the wrong
execution controls for the second sequential GRF write if the number
of channels per GRF is not exactly eight in single-precision mode (or
four in double-float mode)."
In practice, this means that we cannot write more than one
consecutive GRF in a single instruction if the number of channels
per GRF is not exactly eight in single-precision mode (or four
in double-float mode).
This patch makes our SIMD lowering pass split this kind of instructions
so that the split versions only write to a single register. In the
example above this means that we split the write in 4 instructions, each
one writing 4 UD elements (width = 4) to a single register.
v2 (Curro):
- Make explicit that the thing about hardwiring NibCtrl+1 for the second
compressed half is known to happen in Haswell and the issue with IVB
might not be exactly the same.
- Assign max_width instead of returning early so that we can handle
multiple restrictions affecting to the same instruction.
- Avoid division by 0 if the instruction does not write any registers.
- Ignore instructions what have WE_all set.
- Use the instruction execution type size instead of the dst type size.
v3 (Curro):
- Move the implementation down so it is not placed in the middle of another
workaround.
- Declare channels_per_grf as const.
- Don't break the loop early if we find a BAD_FILE source.
- Fix the number of channels that the hardware shifts for the second half
of a compressed instruction to be 8 in single precision and 4 in double
precision.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Gen7 hardware does not support double immediates so these need
to be moved in 32-bit chunks to a regular vgrf instead. Instead
of doing this every time we need to create a DF immediate,
create a helper function that does the right thing depending
on the hardware generation.
v2:
- Define setup_imm_df() as an independent function (Curro)
- Create a specific builder to get rid of some instruction field
assignments (Curro).
v3:
- Get devinfo from builder (Kenneth)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previously, there were occasionally NIR registers in our programs, but
they were always actually used SSA-only. Now that we're trying to support
control flow, we need to actually conditionally move to registers based on
whether channels are active or not.
We're already checking that branch instructions are within the
contents of the shader and the proper PROG_END sequence is present.
The other thing we need in the presence of branching is to verify that
the shader doesn't overflow past the end of the uniforms stream.
To do that, we require that at the start of any basic block reading
uniforms have the following instructions:
load_imm temp, <offset within uniform stream>
add unif_addr, temp, unif
The instructions are generated by userspace, and the kernel verifies
that the load_imm is of the expected offset, and that the add adds it
to a uniform. We track which uniform in the stream that is, and at
draw call time fix up the uniform stream to have the address of the
start of the shader's uniforms for that draw call.
Signed-off-by: Eric Anholt <eric@anholt.net>
This isn't used yet, it's just a first step toward loop validation.
During the main parsing of instructions, we need to know when we hit a new
basic block so that we can reset validated state.
Basically we just treat each block independently. The only inter-block
scheduling I can think of that would be be interesting would be to move
texture result collection to after a short loop/if block that doesn't do
texturing. However, the kernel disallows that as part of its security
validation.
We still decide which uniform to lower based on how many
instructions-that-need-lowering use that uniform, but now we emit a new
temporary uniform load in each of the basic blocks containing an
instruction being lowered.
This commit is best reviewed with diff -b.
We need to apply the peephole pass to each of the blocks in the program.
We don't do dataflow analysis for SF across blocks, but we also don't
generate code that would need us to do so.
The optimization passes and scheduling aren't actually ready for multiple
blocks with control flow yet (as seen by the "cur_block" references in
them instead of iterating over blocks), but this creates the structures
necessary for converting them.
We have the prior list_foreach() all over the code, but I need to move
where instructions live as part of adding support for control flow. Start
by just converting to a helper iterator macro. (The simpler
"qir_for_each_inst()" will be used for the for-each-inst-in-a-block
iterator macro later)
This avoids a bunch of code gen regressions when enabling loops in vc4.
Prior to that, the GLSL that would have generated these optimizable phi
nodes was being lowered to csels between either (undef, a) or (a, a), and
those were being dealt with by nir_opt_undef and nir_opt_algebraic.
The allocation has succeeded by that point, so it needs to be freed.
CovID: 1358929
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
This was appearing in vc4 VS/CS in mupen64, due to vertex attrib lowering
producing some constants that were getting compared.
total instructions in shared programs: 112276 -> 112198 (-0.07%)
instructions in affected programs: 2239 -> 2161 (-3.48%)
total estimated cycles in shared programs: 283102 -> 283038 (-0.02%)
estimated cycles in affected programs: 2365 -> 2301 (-2.71%)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Small api cleanup. Make all api functions call GetContext instead
of locally casting handle. Makes debugging easier by providing a
single point to track context changes.
Signed-off-by: Tim Rowley <timothy.o.rowley@intel.com>
with encode tunneling
The idea of encode tunneling is to use video buffer directly for encoder,
but currently the encoder doesn’t support interlaced surface, the OMX
decoder set progressive surface before on that purpose.
Since now we are polling the driver for interlacing information for
decoder, we got the interlaced as preferred as other APIs(VDPAU, VA-API),
thus breaking the transcode with tunneling.
The solution is when with tunnel detected, re-allocate progressive target
buffers, and then converting the interlaced decoder results to there.
This has been tested with transcode results bit to bit matching as before
with surface from progressive to progressive.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Julien Isorce <j.isorce@samsung.com>
This shader will make interlaced yuv to progressive yuv.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Julien Isorce <j.isorce@samsung.com>
We'll use weave shader in the later patch.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Tested-by: Julien Isorce <j.isorce@samsung.com>
This bug is uncovered by glsl/lower_if_to_cond_assign.
I don't know if it can be reproduced in any other way.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
[ Francisco Jerez: Use validate_build_common for error checking,
simplify control flow slightly and handle additional exception
types. ]
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
header_map was the only definition left in compiler.hpp, move it into
program.hpp which is its only user in clover/core.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
[ Serge Martin: Fix inverted opts and log build ctor args.
Keep the log related to the build. Fix indentation ]
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
This gets rid of the program::build_* query methods and replaces them
with the program::build() method that returns a single data structure
containing all parameters for the last build done on the given target
device (including build logs, options and the binary itself).
[ Serge Martin: Fix inverted opts and log build ctor args ]
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
This partially reverts 7e0180d57d.
Having two different exception subclasses for compilation and linking
makes it more difficult to share or move code between the two
codepaths, because the exact same function under the same error
condition would need to throw one exception or the other depending on
what top-level API is being implemented with it. There is little
benefit anyway because clCompileProgram() and clLinkProgram() can tell
whether they are linking or compiling a program.
Reviewed-by: Serge Martin <edb+mesa@sigluy.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
Return an API object from an intrusive reference to a Clover object,
incrementing the reference count of the object.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Jan Vesely <jan.vesely@rutgers.edu>
