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>
In cases where the color0 argument wasn't being provided,
emit_single_fb_writes() would take the alpha channel directly from the
visitor state instead of taking it from its arguments. This sort of
hack didn't fit nicely into the logical send-message approach because
all parameters of the instruction have to be visible to the SIMD
lowering pass for it to be able to split them into halves at all.
Fix it by using LOAD_PAYLOAD in fs_visitor::emit_fb_writes() to
provide an actual color0 vector with undefined contents except for the
alpha component to match the previous behavior when no color buffers
are enabled.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
It's surprising that we weren't checking for this already. A future
patch will cause code like the following to be emitted:
MOV(16) tmp<1>:uw, src
MOV(8) dst<1>:ud, tmp<8,8,1>:ud
The second MOV comes from the expansion of a LOAD_PAYLOAD header copy,
so I don't have control over its types. Copy propagation will happily
turn this into:
MOV(8) dst<1>:ud, src
Which has different semantics. Fix it by preventing propagation in
cases where a single channel of the instruction would span several
channels of the copy (this requirement could in fact be relaxed if the
copy is just a trivial memcpy, but this case is unusual enough that I
don't think it matters in practice).
I'm deliberately only checking if the type of the instruction is
larger than the original, because the converse case seems to be
handled correctly already in the code below.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We were previously guessing the half based on the EOT flag which seems
rather gross.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The logical variant is largely equivalent to the original opcode but
instead of taking a single payload source it expects its arguments
that make up the payload separately as individual sources, like:
fb_write_logical null, color0, color1, src0_alpha,
src_depth, dst_depth, sample_mask, num_components
This patch defines the opcode and usual instruction boilerplate,
including a placeholder lowering function provided mainly as
self-documentation.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This lowering pass implements an algorithm to expand SIMDN
instructions into a sequence of SIMDM instructions in cases where the
hardware doesn't support the original execution size natively for some
particular instruction. The most important use-cases are:
- Lowering send message instructions that don't support SIMD16
natively into SIMD8 (several texturing, framebuffer write and typed
surface operations).
- Lowering messages that don't support SIMD8 natively into SIMD16
(*cough*gen4*cough*).
- 64-bit precision operations (e.g. FP64 and 64-bit integer
multiplication).
- SIMD32.
The algorithm works by splitting the sources of the original
instruction into chunks of width appropriate for the lowered
instructions, and then interleaving the results component-wise into
the destination of the original instruction. The pass is controlled
by the get_lowered_simd_width() function that currently just returns
the original execution size making the whole pass a no-op for the
moment until some user is introduced.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
v2: Reverse order of the source transformations and split_inst emit
call to make the code a bit easier to understand.
Typically BAD_FILE sources are used to mark a source as not present
what implies that no registers are read. This will become much more
frequent with logical send opcodes which have a large number of
sources, many of them optionally used and marked as BAD_FILE when they
aren't applicable. It will prove to be useful to be able to rely on
the value of regs_read() regardless of whether a source is present or
not.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
And start using it in fs_builder::LOAD_PAYLOAD(). This will be used
to emit logical send message opcodes which have an unusually large
number of arguments.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This pass will house ad-hoc lowering code for several send
message-like virtual opcodes that will represent their logically
independent arguments as separate instruction sources rather than as a
single payload blob. This pass will basically just take the separate
arguments that are supposed to be part of the payload and concatenate
them to construct a message in the form required by the hardware.
Virtual instructions in separate-source form will eventually allow
some simplification of the visitor code and make several
transformations easier like lowering SIMD16 instructions to SIMD8
algorithmically in cases where the hardware doesn't support the former
natively.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This cleans up fs_inst::regs_read() slightly by disentangling the
calculation of "components" from the handling of message payload
arguments. This will also simplify the SIMD lowering and logical send
message lowering passes, because it will avoid expressions like
'regs_read * REG_SIZE / component_size' which are not only ugly, they
may be inaccurate because regs_read rounds up the result to the
closest register multiple so they could give incorrect results when
the component size is lower than one register (e.g. uniforms). This
didn't seem to be a problem right now because all such expressions
happen to be dealing with per-channel GRFs only currently, but that's
by no means obvious so better be safe than sorry.
v2: Split PIXEL_X/Y and LINTERP into separate case blocks.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
For some reason the loop that rewrites all occurrences of the
coalesced register was iterating over all possible offsets until it
would find one that compares equal to the offset of a source or
destination of any instruction in the program. Since the mapping
between old and new offsets is already available in the regs_to_offset
array and we know that the whole register has been coalesced we can
just look it up.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
The register coalesce pass wasn't rewriting the destination and
sources of instructions that accessed the second half of a coalesced
register previously copied with a 16-wide MOV instruction. E.g.:
| ADD (16) vgrf0:f, vgrf0:f, 1.0:f
| MOV (16) vgrf1:f, vgrf0:f
| MOV (8) vgrf2:f, vgrf0+1:f { sechalf }
would get incorrectly register-coalesced into:
| ADD (16) vgrf1:f, vgrf1:f, 1.0:f
| MOV (8) vgrf2:f, vgrf0+1:f { sechalf }
The reason is that the mov[i] pointer was being left equal to NULL for
every other register. The fact that we've made it to the rewrite loop
implies that the whole register will be coalesced, so it doesn't seem
right not to update something that uses it depending on whether mov[i]
is NULL or not. Fixes an amount of texturing and image_load_store
piglit tests on my SIMD-lowering branch.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
register_coalesce() was considering the exec_size of the MOV
instruction alone to decide whether the register at offset+1 of the
source VGRF was being copied to inst->dst.reg_offset+1 of the
destination VGRF, which is only a valid assumption if the move has a
32-bit execution type. Use regs_read() instead to find out the number
of registers copied by the instruction.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This adds to the common radeon streamout code, support
for multiple streams.
It updates radeonsi/r600 to set the enabled mask up.
v2: update for changes in previous patch.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This will be used here later.
v2: update atom sizes
add check for old vs new enabled mask
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Page 497 of the PDF, section '17.4.3.1 Clearing Individual Buffers' of the
OpenGL 4.5 spec states:
"An INVALID_ENUM error is generated by ClearBufferiv and
ClearNamedFramebufferiv if buffer is not COLOR or STENCIL."
Fixes 1 dEQP test:
* dEQP-GLES3.functional.negative_api.buffer.clear_bufferiv
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
A simple shader such as
vec4 color;
color.xy.x = 1.0;
would cause ir_assignment::set_lhs() to generate bogus IR:
(swiz xy (swiz x (constant float (1.0))))
We were setting the number of components of each new RHS swizzle based
on the highest channel used in the LHS swizzle. So, .xy.y would
generate (swiz xy (swiz xx ...)), while .xy.x would break.
Our existing Piglit test happened to use .xzy.z, which worked, since
'z' is the third component, resulting in an xxx swizzle.
This patch sets the number of swizzle components based on the size of
the LHS swizzle's inner value, so we always have the correct number
at each step.
Fixes new Piglit tests glsl-vs-swizzle-swizzle-lhs-[23].
Fixes ir_validate assertions in in Metro 2033 Redux.
v2: Move num_components updating completely out of update_rhs_swizzle
(suggested by Timothy Arceri). Simplify.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>
Same check is made for glBindFragDataLocationIndexed but it was missing
when using layout qualifiers.
Fixes following Piglit test:
arb_blend_func_extended-output-location
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>
Change function to get all gl_constants for inspection, this is used
by follow-up patch.
v2: rebase, update function documentation
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>
It's a bunch of work for us to emit it (and its uniforms), more work for
the kernel to validate it, and additional work for the CLE to read
it. Improves es2gears framerate by about 50%.
Signed-off-by: Eric Anholt <eric@anholt.net>
Since the conversion to keeping validated shaders around for the BO's
lifetime, we haven't been checking that rendering doesn't happen to
shaders. Make vc4_use_bo check that always, and just don't use it for the
VC4_MODE_SHADER case (so now modes are unused)
We don't want anything to appear after we've kicked off the render (and
thus job flush), since that might then get written out to the tile
allocation state.
Signed-off-by: Eric Anholt <eric@anholt.net>
Glamor asks GBM for the handle of the BO, then flinks it itself. We
were marking the bo non-private in the flink and dmabuf (DRI3) paths,
but not the GEM handle path. As a result, non-pageflipping DRI2
swapbuffers (EGL apps, in particular) were never updating the texture.
The meta CopyImageSubData path uses BlitFramebuffers to do the actual copy.
The only thing that can affect BlitFramebuffers other than the currently
bound framebuffers is the scissor so we need to save that off and reset it.
If we don't do this, applications that use a scissor together with
CopyImageSubData will get accidentally scissored copies.
Tested-by: Markus Wick <markus at selfnet.de>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Previously, we were crawling through the anv_cmd_buffer datastructure to
pull out batch buffers and things. This meant that every time something in
anv_cmd_buffer changed, we broke aub dumping. However, aub dumping should
just dump the stuff the kernel knows about so we really don't need to be
crawling driver internals.
This adds support for queries against the non-0 vertex streams.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It only checks fragment textures and ignores other shaders, which makes it
incomplete, and textures are already finalized in update_single_texture.
There are no piglit regressions.
Reviewed-by: Brian Paul <brianp@vmware.com>
Francisco Jerez