The opcodes are not specific for conversions to/from float since we need
the same for conversions to/from other 32-bit types. Rename the opcodes
accordingly and change the asserts to check the size of the types involved
instead.
v2:
- Rename to VEC4_OPCODE_TO_DOUBLE and VEC4_OPCODE_FROM_DOUBLE (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Make dst_reg_for_nir_reg() handle this for nir_register since we
want to have the correct type set before we call offset().
Reviewed-by: Matt Turner <mattst88@gmail.com>
Basically, ALIGN1 mode will ignore swizzles on the input vectors so we don't
want the copy propagation pass to mess with them.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These align1 opcodes do partial writes of 64-bit data. The problem is that we
want to use them to write on the same register to implement packDouble2x32 and
from the point of view of DCE, since both opcodes write to the same register,
only the last one stands and decides to eliminate the first, which is
not correct, so prevent this from happening.
v2: Make a helper in vec4_instruction to know if the instruction is an
align1 partial write. This will come in handy when we implement a
simd splitting pass in a later patch.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These opcodes will set the low/high 32-bit in each 64-bit data element
using Align1 mode. We will use this to implement packDouble2x32.
We use Align1 mode because in order to implement this in Align16 mode
we would need to use 32-bit logical swizzles (XZ for low, YW for high),
but the IR works in terms of 64-bit logical swizzles for DF operands
all the way up to codegen.
v2:
- use suboffset() instead of get_element_ud()
- no need to set the width on the dst
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These opcodes will pick the low/high 32-bit in each 64-bit data element
using Align1 mode. We will use this, for example, to do things like
unpackDouble2x32.
We use Align1 mode because in order to implement this in Align16 mode
we would need to use 32-bit logical swizzles (XZ for low, YW for high),
but the IR works in terms of 64-bit logical swizzles for DF operands
all the way up to codegen.
v2:
- use suboffset() instead of get_element_ud()
- no need to set the width on the dst
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Add asserts so we remember to address this when we enable 64-bit
integer support, as suggested by Connor and Jason.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
For 32-bit instructions we want to use <4,4,1> regions for VGRF
sources so we should really set a width of 4 (we were setting 8).
For 64-bit instructions we want to use a width of 2 because the
hardware uses 32-bit swizzles, meaning that we can only address 2
consecutive 64-bit components in a row. Also, Curro suggested that
the hardware is probably fixing the width to 2 for 64-bit instructions
anyway, so just go with that and use <2,2,1>.
v2:
- No need to explicitly set the vertical stride of 64-bit regions to 2,
brw_vecn_grf with a width of 2 will do that for us.
- No need to adjust the width of dst registers.
v3 (Ian):
- Make type_size and width const.
Signed-off-by: Connor Abbott <connor.w.abbott@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
These need to be emitted as align1 MOV's, since they need to have a
stride of 2 on the float register (whether src or dest) so that data
from another thread doesn't cross the middle of a SIMD8 register.
v2 (Iago):
- The float-to-double needs to align 32-bit data to 64-bit before doing the
conversion. This was doable in align16 when we tried to use an execsize
of 4, but with an execsize of 8 we would need another align1 opcode to do
that (since we need data to cross the middle of a SIMD register). Just
making the opcode handle this internally seems more practical that adding
another opcode just for this purpose and having the caller know about this
before converting.
- The double-to-float conversion produces 32-bit elements aligned to 64-bit
so we make the opcode re-pack the result to 32-bit and fit in one register,
as expected by SIMD4x2 operation. This still requires that callers reserve
two registers for the float data destination because we need to produce
64-bit aligned data first, and repack it later on the same destination
register, but it saves the need for a re-pack opcode only to achieve this
making the operation complete in a single opcode. Hopefully that is worth
the weirdness of the double register allocation...
Signed-off-by: Connor Abbott <connor.w.abbott@intel.com>
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Basically, this involves considering the bit-size information to set
the appropriate type on both operands and destination.
v2 (Curro)
- Don't use two temporaries (and write one of them twice ) to obtain
the nir_alu_type.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2 (Curro):
- Do not special-case for a bit-size of 64, divide the bit_size by 32
instead.
- Use DIV_ROUND_UP so we can handle sub-32-bit types.
v3 (Ian):
- Make num_regs const.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Less duplication, one one less case to handle for doubles and support
for sized NIR types.
v2: Fix call to get_instance by swapping rows and columns params (Iago)
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
max_vector_size is used in the vec4 backend to pad out the uniform
components to match a size that is a multiple of a vec4. Double and dvec2
uniforms only require a single vec4 slot, not two.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Otherwise, DIM instructions will be emitted with the default exec size
which could be 16 in some cases, that is not legal.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Suggested-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We can just get this information from shader_info instead.
Note that passing gen6_gs_visitor() gl_program via _LinkedShaders
will go away in a later patch.
Reviewed-by: Eric Anholt <eric@anholt.net>
This removes another dependency on gl_shader_program in the codegen
functions which will help allow us to use gl_program in the
CurrentProgram array rather than gl_shader_program.
Reviewed-by: Eric Anholt <eric@anholt.net>
This disallows fancy varyings in tessellation and geometry shaders,
as required by ES 3.2.
Fixes:
dEQP-GLES31.functional.tessellation.user_defined_io.negative.per_patch_array_of_structs
dEQP-GLES31.functional.tessellation.user_defined_io.negative.per_patch_structs_containing_arrays
(Not a candidate for stable branches as it only disallows things which
should be working as desktop GL allows them.)
v2: Update error messages to not say "vertex shader" (caught by Iago).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
As CCS buffers are passed to KMS, it becomes useful to be able to
determine exactly what type of aux buffers are disabled. This was
previously not entirely needed (though the code was a little more
confusing), however it becomes very desirable after a recent patch from
Chad:
commit 1c8be049be
Author: Chad Versace <chadversary@chromium.org>
Date: Fri Dec 9 16:18:11 2016 -0800
i965/mt: Disable aux surfaces after making miptree shareable
The next patch will handle CCS and get rid of no_ccs.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Dump values for every selected data source in GALLIUM_HUD.
Every data source has its own file and the filename is
equal to the data source identifier.
Set GALLIUM_HUD_DUMP_DIR to dump values to files in this directory.
No values are dumped if the environment variable is not set, the
directory doesn't exist or the user doesn't have write access.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
The SPIR-V capability isn't even marked as enabled, and there are no
tests in Vulkan-CTS. Per Jason Ekstrand, this won't work in anv as such
write-only surfaces require additional setup which is currently not
performed.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>
upload_3dstate_streamout can be called when there's no currently bound
transform feedback object. In this case, we get the default object,
which has a NULL shader (previously gl_shader_program, now gl_program).
The old code did something sketchy, but which worked:
const struct gl_transform_feedback_info *linked_xfb_info =
&xfb_obj->shader_program->LinkedTransformFeedback;
Here, if shader_program is NULL, this would be a bogus pointer of 0x60.
But we never actually dereferenced it, so it worked out.
With Timothy's recent reworks, we actually end up dereferencing
xfb_obj->program along the way, which crashes since it's NULL.
The solution is to move this pointer initialization into the "active"
block, where we know it actually exists and won't be bogus.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99231
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
We also add the stubs for the standalone compiler in this change.
By adding a reference here we can now refactor some code to use
gl_program where we were previously awkwardly using gl_shader_program.
Reviewed-by: Eric Anholt <eric@anholt.net>
i915 is mixing the use of these fields, for now change this to a
struct and add a FIXME.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99229
We were passing around a void *mem_ctx and using that to initialize the
builder which was wrong since that pointed to ralloc_parent(impl) which
is the shader but the builder is supposed to be initialized with the
nir_function_impl.
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Iago Toral Quiroga
Connor Abbott
Samuel Iglesias Gonsálvez
Timothy Arceri
Marek Olšák
Kenneth Graunke
Ben Widawsky
Edmondo Tommasina
Ilia Mirkin
Jason Ekstrand