Lionel Landwerlin [Tue, 13 Dec 2016 11:18:01 +0000 (11:18 +0000)]
spirv: compute push constant access offset & range
v2: Move relative push constant relative offset computation down to
_vtn_load_store_tail() (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Lionel Landwerlin [Sat, 17 Dec 2016 22:25:37 +0000 (22:25 +0000)]
spirv: move block_size() definition
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Marek Olšák [Wed, 4 Jan 2017 10:42:13 +0000 (11:42 +0100)]
va: call texture_get_handle while the mutex is being held
The context may be used by texture_get_handle.
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Marek Olšák [Wed, 4 Jan 2017 10:42:13 +0000 (11:42 +0100)]
vdpau: call texture_get_handle while the mutex is being held
The context may be used by texture_get_handle.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99158
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Samuel Pitoiset [Tue, 3 Jan 2017 17:41:13 +0000 (18:41 +0100)]
radeonsi: capitalize VM hex addr when dumping buffer list
Useful when debugging with R600_DEBUG=vm,check_vm to match
addr in both outputs.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tapani Pälli [Mon, 2 Jan 2017 13:02:03 +0000 (15:02 +0200)]
i965: remove unused brwInitVtbl declaration
function was removed by
b3360d23ac1db61390b2ac8963756c6133ba6e23
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Iago Toral Quiroga [Tue, 3 Jan 2017 08:10:13 +0000 (09:10 +0100)]
i965: remove brw_context dependency from intel_batchbuffer_init()
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Iago Toral Quiroga [Tue, 3 Jan 2017 07:39:27 +0000 (08:39 +0100)]
i965: make intel_batchbuffer_free() take a batchbuffer as argument
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Iago Toral Quiroga [Mon, 2 Jan 2017 15:28:55 +0000 (16:28 +0100)]
i965: make intel_batchbuffer_emit_dword() take a batchbuffer as argument
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Iago Toral Quiroga [Mon, 2 Jan 2017 15:14:33 +0000 (16:14 +0100)]
i965: Make intel_bachbuffer_reloc() take a batchbuffer argument
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Timothy Arceri [Tue, 3 Jan 2017 01:03:54 +0000 (12:03 +1100)]
nir: fix loop iteration count calculation for floats
Fixes performance regression in SynMark PSPom caused by loops with float
counters not always unrolling.
For example:
for (float i = 0.02; i < 0.9; i += 0.11)
...
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Edmondo Tommasina [Sun, 1 Jan 2017 21:31:57 +0000 (22:31 +0100)]
gallium/hud: add a path separator between dump directory and filename
It's more user friendly and it avoids to write files in unexpected
places.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Heiko Przybyl [Sun, 20 Nov 2016 13:42:28 +0000 (14:42 +0100)]
r600/sb: Fix loop optimization related hangs on eg
Make sure unused ops and their references are removed, prior to entering
the GCM (global code motion) pass, to stop GCM from breaking the loop
logic and thus hanging the GPU.
Turns out, that sb has problems with loops and node optimizations
regarding associative folding:
- the global code motion (gcm) pass moves ops up a loop level/basic block
until they've fulfilled their total usage count
- if there are ops folded into others, the usage count won't be
fulfilled and thus the op moved way up to the top
- within GCM the op would be visited and their deps would be moved
alongside it, to fulfill the src constaints
- in a loop, an unused op is moved out of the loop and GCM would move
the src value ops up as well
- now here arises the problem: if the loop counter is one of the src
values it would get moved up as well, the loop break condition would
never get hit and the shader turn into an endless loop, resulting in the
GPU hanging and being reset
A reduced (albeit nonsense) piglit example would be:
[require]
GLSL >= 1.20
[fragment shader]
uniform int SIZE;
uniform vec4 lights[512];
void main()
{
float x = 0;
for(int i = 0; i < SIZE; i++)
x += lights[2*i+1].x;
}
[test]
uniform int SIZE 1
draw rect -1 -1 2 2
Which gets optimized to:
===== SHADER #12 OPT ================================== PS/BARTS/EVERGREEN =====
===== 42 dw ===== 1 gprs ===== 2 stack =========================================
ALU 3 @24
1 y: MOV R0.y, 0
t: MULLO_UINT R0.w, [0x00000002 2.8026e-45].x, R0.z
LOOP_START_DX10 @22
PUSH @6
ALU 1 @30 KC0[CB0:0-15]
2 M x: PRED_SETGE_INT __.x, R0.z, KC0[0].x
JUMP @14 POP:1
LOOP_BREAK @20
POP @14 POP:1
ALU 2 @32
3 x: ADD_INT R0.x, R0.w, [0x00000002 2.8026e-45].x
TEX 1 @36
VFETCH R0.x___, R0.x, RID:0 MFC:16 UCF:0 FMT[..]
ALU 1 @40
4 y: ADD R0.y, R0.y, R0.x
LOOP_END @4
EXPORT_DONE PIXEL 0 R0.____ EOP
===== SHADER_END ===============================================================
Notice R0.z being the loop counter/break condition relevant register
and being never incremented at all. Also some of the loop content
has been moved out of it, to fulfill the requirements for the one unused
op.
With a debug build of mesa this would produce an error like
error at : PRED_SETGE_INT __, __, EM.2, R1.x.2||FP@R0.z, C0.x
: operand value R1.x.2||FP@R0.z was not previously written to its gpr
and the compilation would fail due to this. On a release build it gets
passed to the GPU.
When using this patch, the loop remains intact:
===== SHADER #12 OPT ================================== PS/BARTS/EVERGREEN =====
===== 48 dw ===== 1 gprs ===== 2 stack =========================================
ALU 2 @24
1 y: MOV R0.y, 0
z: MOV R0.z, 0
LOOP_START_DX10 @22
PUSH @6
ALU 1 @28 KC0[CB0:0-15]
2 M x: PRED_SETGE_INT __.x, R0.z, KC0[0].x
JUMP @14 POP:1
LOOP_BREAK @20
POP @14 POP:1
ALU 4 @30
3 t: MULLO_UINT T0.x, [0x00000002 2.8026e-45].x, R0.z
4 x: ADD_INT R0.x, T0.x, [0x00000002 2.8026e-45].x
TEX 1 @40
VFETCH R0.x___, R0.x, RID:0 MFC:16 UCF:0 FMT[..]
ALU 2 @44
5 y: ADD R0.y, R0.y, R0.x
z: ADD_INT R0.z, R0.z, 1
LOOP_END @4
EXPORT_DONE PIXEL 0 R0.____ EOP
===== SHADER_END ===============================================================
Piglit: ./piglit summary console -d results/*_gpu_noglx
name: unpatched_gpu_noglx patched_gpu_noglx
---- ------------------- -----------------
pass: 18016 18021
fail: 748 743
crash: 7 7
skip: 1124 1124
timeout: 0 0
warn: 13 13
incomplete: 0 0
dmesg-warn: 0 0
dmesg-fail: 0 0
changes: 0 5
fixes: 0 5
regressions: 0 0
total: 19908 19908
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94900
Tested-by: Heiko Przybyl <lil_tux@web.de>
Tested-on: Barts PRO HD6850
Signed-off-by: Heiko Przybyl <lil_tux@web.de>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Eric Anholt [Tue, 27 Dec 2016 17:00:14 +0000 (09:00 -0800)]
editorconfig: Fix up the tab rendering width.
Our editorconfig file looked sensible, saying that we wanted to indent
with spaces and use 3/4/whatever space indentation. However, the spec has
this little surprise:
"tab_width: a whole number defining the number of columns used to
represent a tab character. This defaults to the value of indent_size
and doesn't usually need to be specified."
so once my editor started respecting editorconfig, the files that have
tabs left in them started getting rendered wrong, showing up like this in
brw_program.c:
case GL_COMPUTE_PROGRAM_NV: {
struct brw_program *prog = rzalloc(NULL, struct brw_program);
if (prog) {
prog->id = get_new_program_id(brw->screen);
return _mesa_init_gl_program(&prog->program, target, id);
}
else
return NULL;
}
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Chad Versace [Thu, 29 Dec 2016 21:05:27 +0000 (13:05 -0800)]
meta: Disable dithering during glGenerateMipmap
Fixes tests 'dEQP-GLES3.functional.texture.mipmap.*.generate.rgba5551*' on
Intel Broadwell 0x1616.
The GL 4.5 spec describes the algorithm of glGenerateMipmap as:
The contents of the derived images are computed by repeated, filtered
reduction of the level base image. [...] No particular filter algorithm is
required, though a box filter is recommended as the default filter.
Consider a texture for which all pixels are identical at level 0.
From the spec's description above, one may reasonably assume that the "filtered
reduction" of level 0 produces a new miplevel for which again all pixels are
identical. For any 2x2 subspan of identical pixels, it is difficult to see how
the "filtered reduction" of that subspan can produce a pixel that differs from
the source pixels.
Dithering during _mesa_meta_GenerateMipmap() violated that reasonable
assumption.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99210
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org
Romain Failliot [Tue, 3 Jan 2017 15:41:22 +0000 (10:41 -0500)]
doc/features.txt: update for freedreno
I lost track of who created initial patch (Ilia?).. Romain rebased it.
I pushed it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95460
Signed-off-by: Rob Clark <robdclark@gmail.com>
Robert Bragg [Wed, 22 Apr 2015 18:40:34 +0000 (11:40 -0700)]
i965: Remove perf monitor/query backend
In its current state the unified i965 backend for
AMD_performance_monitor and INTEL_performance_query isn't able to report
meaningful Observation Architecture metrics since we haven't so far had
the necessary kernel support to fully configure the OA unit, nor the
corresponding support for normalizing the counters into a form that can
be usefully interpreted by application developers (as opposed to raw
values that may, for example, scale by the number of EUs there are).
So that we can focus on implementing just one of these extensions fully
and since we anticipate some significant backend changes as we look to
use a new kernel interface to configure the OA unit, this patch removes
the current backend. This will simplify our ability to update the
frontend infrastructure and backend interface before updating our
support for performance counters.
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Christian König [Wed, 14 Dec 2016 14:03:35 +0000 (15:03 +0100)]
vl/zscan: fix "Fix trivial sign compare warnings"
The variable actually needs to be signed, otherwise converting it to a
float doesn't work as expected.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98914
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Fixes:
1fb4179f927 ("vl: Fix trivial sign compare warnings")
Nayan Deshmukh [Tue, 3 Jan 2017 10:47:47 +0000 (16:17 +0530)]
st/va: error handling
handle the cases when vl_compositor_set_csc_matrix(),
vl_compositor_init_state() and vl_compositor_init() fail
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Nayan Deshmukh [Tue, 3 Jan 2017 10:47:46 +0000 (16:17 +0530)]
st/vdpau: error handling
handle the cases when vl_compositor_set_csc_matrix(),
vl_compositor_init_state() and vl_compositor_init() fail
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Nayan Deshmukh [Tue, 3 Jan 2017 10:47:45 +0000 (16:17 +0530)]
vl/compositor: implement error handling
pipe_buffer_map and pipe_buffer_create may return NULL
Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Iago Toral Quiroga [Thu, 23 Jun 2016 07:22:09 +0000 (09:22 +0200)]
i965/vec4: enable ARB_gpu_shader_fp64 for Haswell
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Tue, 6 Sep 2016 09:46:26 +0000 (11:46 +0200)]
i965/vec4: adjust spilling costs for 64-bit registers.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Tue, 6 Sep 2016 06:56:05 +0000 (08:56 +0200)]
i965/vec4: prevent spilling of DOUBLE_TO_SINGLE destination
FROM_DOUBLE opcodes are setup so that they use a dst register
with a size of 2 even if they only produce a single-precison
result (this is so that the opcode can use the larger register to
produce a 64-bit aligned intermediary result as required by the
hardware during the conversion process). This creates a problem for
spilling though, because when we attempt to emit a spill for the
dst we see a 32-bit destination and emit a scratch write that
allocates a single spill register, making the intermediary writes
go beyond the size of the allocation.
Prevent this by avoiding to spill the destination register of these
opcodes.
Alternatively, we can avoid this by splitting the opcode in two: one
that produces a 64-bit aligned result and one that takes the 64-bit
aligned result as input and produces a 32-bit result from it.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 9 Sep 2016 10:21:06 +0000 (12:21 +0200)]
i965/vec4: avoid spilling of registers that mix 32-bit and 64-bit access
When 64-bit registers are (un)spilled, we need to execute data shuffling
code before writing to or after reading from memory. If we have instructions
that operate on 64-bit data via 32-bit instructions, (un)spills for the
register produced by 32-bit instructions will not do data shuffling at all
(because we only see a normal 32-bit istruction seemingly operating on
32-bit data). This means that subsequent reads with that register using DF
access will unshuffle data read from memory that was never adequately
shuffled when it was written.
Fixing this would require to identify which 32-bit instructions write
64-bit data and emit spill instructions only when the full 64-bit
data has been written (by multiple 32-bit instructions writing to different
offsets of the same register) and always emit 64-bit unspills whenever
64-bit data is read, even when the instruction uses a 32-bit type to read
from them.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 1 Sep 2016 12:38:57 +0000 (14:38 +0200)]
i965/vec4: support basic spilling of 64-bit registers
The current spilling code can't spill vgrf allocations larger than 1
but SIMD4x2 doubles require 2 vgrfs, so we need to permit this case (which
is handled properly for DF data types by emitting 2 scratch messages and
doing data shuffling). We accomplish this by not auto-disabling spilling
for vgrf allocations with a size of 2, and then disable spilling on any
register with an offset != 0B (which indicates array access).
Disable spilling of partial DF reads/writes because these don't read/write
data for both logical threads and our scratch messages for 64-bit data
need data for both threads to be present.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 1 Sep 2016 10:01:02 +0000 (12:01 +0200)]
i965/vec4: run scalarize_df() after spilling
Spilling of 64-bit data requires data shuffling for the corresponding
scratch read/write messages. This produces unsupported swizzle regions
and writemasks that we need to scalarize.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 1 Sep 2016 12:23:26 +0000 (14:23 +0200)]
i965/vec4: prevent src/dst hazards during 64-bit register allocation
8-wide compressed DF operations are executed as two separate 4-wide
DF operations. In that scenario, we have to be careful when we allocate
register space for their operands to prevent the case where the first
half of the instruction overwrites the source of the second half.
To do this we mark compressed instructions as having hazards to make
sure that ther register allocators assigns a register regions for the
destination that does not overlap with the region assigned for any
of its source operands.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 18 Aug 2016 09:15:56 +0000 (11:15 +0200)]
i965/vec4/scalarize_df: support more swizzles via vstride=0
By exploiting gen7's hardware decompression bug with vstride=0 we gain the
capacity to support additional swizzle combinations.
This also fixes ZW writes from X/Y channels like in:
mov r2.z:df r0.xxxx:df
Because DF regions use 2-wide rows with a vstride of 2, the region generated
for the source would be r0<2,2,1>.xyxy:DF, which is equivalent to r0.xxzz, so
we end up writing r0.z in r2.z instead of r0.x. Using a vertical stride of 0
in these cases we get to replicate the XX swizzle and write what we want.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Tue, 19 Jul 2016 07:28:04 +0000 (09:28 +0200)]
i965/vec4/scalarize_df: do not scalarize swizzles that we can support natively
Certain swizzles like XYZW can be supported by translating only the first two
64-bit swizzle channels to 32-bit channels. This happens with swizzles such
that the first two logical components, when translated to 32-bit channels and
replicated across the second dvec2 row, select the same channels specified by
the 3rd and 4th logical swizzle components.
Notice that this opens up the possibility that some instructions are not
scalarized and can end up with XY or ZW 32-bit writemasks. Make sure we always
scalarize in such cases.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 1 Jul 2016 07:26:32 +0000 (09:26 +0200)]
i965/vec4: split instructions that read 64-bit interleaved attributes
Stages that use interleaved attributes generate regions with a vstride=0
that can hit the gen7 hardware decompression bug.
v2:
- Make static the function and fix indent (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 1 Jul 2016 07:28:31 +0000 (09:28 +0200)]
i965/vec4: dump subnr for FIXED_GRF
This came in handy when debugging the payload setup for Tess Eval,
since it prints correct subnr for attributes that can be loaded
in the second half of a register.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 15 Sep 2016 08:49:40 +0000 (10:49 +0200)]
i965/vec4/tes: consider register offsets during attribute setup
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 1 Jul 2016 07:22:34 +0000 (09:22 +0200)]
i965/vec4/tes: fix setup_payload() for 64bit data types
Use a width of 2 with 64-bit attributes.
Also, if we have a dvec3/4 attribute that gets split across two registers
such that components XY are stored in the second half of a register and
components ZW are stored in the first half of the next, we need to fix
regioning for any instruction that reads components Z/W of the attribute.
Notice this also means that we can't support sources that read cross-dvec2
swizzles (like XZ for example).
v2: don't assert that we have a single channel swizzle in the case that we
have to fix up Z/W access on the first half of the next register. We
can handle any swizzle that does not cross dvec2 boundaries, which
the double scalarization pass should have prevented anyway.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 1 Jul 2016 07:24:12 +0000 (09:24 +0200)]
i965/vec4/tes: fix input loading for 64bit data types
v2: use byte_offset() instead of offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 30 Jun 2016 09:03:17 +0000 (11:03 +0200)]
i965/vec4/tcs: fix outputs for 64-bit data
v2: use byte_offset() instead of offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 1 Jul 2016 09:35:06 +0000 (11:35 +0200)]
i965/vec4/tcs: fix input loading for 64-bit data
v2: use byte_offset() instead of offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Samuel Iglesias Gonsálvez [Fri, 1 Jul 2016 09:37:56 +0000 (11:37 +0200)]
i965/vec4/gs: fix input loading for 64bit data
v2 (Iago):
- Adapt 64-bit path to component packing changes.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 1 Jul 2016 07:01:56 +0000 (09:01 +0200)]
i965/vec4: fix store output for 64-bit types
We need to shuffle the data before it is written to the URB. Also,
dvec3/4 need two vec4 slots.
v2: use byte_offset() instead of offset().
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 6 Oct 2016 08:25:13 +0000 (10:25 +0200)]
i965/vec4: fix attribute setup for doubles
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 6 Oct 2016 07:57:31 +0000 (09:57 +0200)]
i965/vec4: fix indentation in lower_attributes_to_hw_regs()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 15 Jul 2016 11:02:27 +0000 (13:02 +0200)]
i965/vec4: make emit_pull_constant_load support 64-bit loads
This way callers don't need to know about 64-bit particularities and
we reuse some code.
v2:
- use byte_offset() instead of offset()
- only mark the surface as used once
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 13 Jul 2016 08:45:13 +0000 (10:45 +0200)]
i965/vec4: fix move_push_constants_to_pull_constants() for 64-bit data
v2: adapt to changes in offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 13 Jul 2016 08:21:18 +0000 (10:21 +0200)]
i965/vec4: fix indentation in move_push_constants_to_pull_constants()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 29 Jun 2016 06:41:11 +0000 (08:41 +0200)]
i965/vec4: fix move_uniform_array_access_to_pull_constant() for 64-bit data
v2: adapt to changes in offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Tue, 28 Jun 2016 10:03:09 +0000 (12:03 +0200)]
i965/vec4: fix scratch writes for 64bit data
Mostly the same stuff as usual: we ned to shuffle the data before we
write and we need to emit two 32-bit write messages (with appropriate
32-bit writemask channels set) for a full dvec4 scratch write.
v2: use byte_offset() instead of offset().
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Tue, 28 Jun 2016 10:02:24 +0000 (12:02 +0200)]
i965/vec4: fix scratch reads for 64bit data
v2: Setup for a 64-bit scratch read by checking the type size of the
correct register
v3: Use byte_offset() instead of offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 17 Feb 2016 09:05:02 +0000 (10:05 +0100)]
i965/vec4: fix scratch offset for 64bit data
A vec4 is 16 bytes and a dvec4 is 32 bytes so for doubles we have
to multiply the reladdr by 2. The reg_offset part is in units of 16
bytes and is used to select the low/high 16-byte chunk of a full
dvec4, so we don't want to multiply that part of the address.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Tue, 28 Jun 2016 09:54:07 +0000 (11:54 +0200)]
i965/vec4: do not split scratch read/write opcodes
64-bit scratch read/writes require to shuffle data around so we need
to have access to the full 64-bit data. We will do the right thing
for these when we emit the messages.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 23 Jun 2016 08:40:47 +0000 (10:40 +0200)]
i965/vec4: Do not use DepCtrl with 64-bit instructions
The BDW PRM says that it is not supported, but it seems that gen7 is also
affected, since doing DepCtrl on double-float instructions leads to
GPU hangs in some cases, which is probably not surprising knowing that
this is not supported in new hardware iterations. The SKL PRMs do not
mention this restriction, so it is probably fine.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 23 Jun 2016 08:35:50 +0000 (10:35 +0200)]
i965/vec4: extend the DWORD multiply DepCtrl restriction to all gen8 platforms
v2:
- Add Broxton as Intel's internal PRMs says that it is needed (Matt).
Reviewed-by: Matt Turner <mattst88@gmail.com>
Samuel Iglesias Gonsálvez [Wed, 22 Jun 2016 13:13:45 +0000 (15:13 +0200)]
i965/vec4: don't copy propagate misaligned registers
This means we would copy propagate partial reads or writes and that can affect
the result.
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 13 Jul 2016 07:11:35 +0000 (09:11 +0200)]
i965/vec4: don't propagate single-precision uniforms into 4-wide instructions
Otherwise we end up producing code that violates the register region
restriction that says that when execsize == width and hstride != 0
the vstride can't be 0.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 23 Jun 2016 06:34:53 +0000 (08:34 +0200)]
i965/vec4: Prevent copy propagation from violating pre-gen8 restrictions
In gen < 8 instructions that write more than one register need to read
more than one register too. Make sure we don't break that restriction
by copy propagating from a uniform.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 16 Jun 2016 11:41:48 +0000 (13:41 +0200)]
i965/vec4: prevent copy-propagation from values with a different type size
Because the meaning of the swizzles and writemasks involved is different,
so replacing the source would lead to different semantics.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Connor Abbott [Thu, 13 Aug 2015 22:44:14 +0000 (15:44 -0700)]
i965/vec4: don't constant propagate 64-bit immediates
v2: Also check if the instruction source target is 64-bit. (Samuel)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 12 Feb 2016 13:05:11 +0000 (14:05 +0100)]
i965/vec4: Fix SSBO stores for 64-bit data
In this case we need to shuffle the 64-bit data before we write it
to memory, source from reg_offset + 1 to write components Z and W
and consider that each DF channel is twice as big.
v2: use byte_offset() instead of offset().
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 13 Jul 2016 11:34:55 +0000 (13:34 +0200)]
i965/vec4: Fix SSBO loads for 64-bit data
Same requirements as for UBO loads.
v2:
- use byte_offset() instead of offset() (Iago)
- keep the const. offset as an immediate like the original code did (Juan)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 13 Jul 2016 10:10:18 +0000 (12:10 +0200)]
i965/vec4: Fix UBO loads for 64-bit data
We need to emit 2 32-bit load messages to load a full dvec4. If only
1 or 2 double components are needed dead-code-elimination will remove
the second one.
We also need to shuffle the result of the 32-bit messages to form
valid 64-bit SIMD4x2 data.
v2:
- use byte_offset() instead of offset() (Iago)
- keep the const. offset as an immediate like the original code did (Juan)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 22 Jun 2016 09:44:15 +0000 (11:44 +0200)]
i965/vec4: Add a shuffle_64bit_data helper
SIMD4x2 64bit data is stored in register space like this:
r0.0:DF x0 y0 z0 w0
r1.0:DF x1 y1 z1 w1
When we need to write data such as this to memory using 32-bit write
messages we need to shuffle it in this fashion:
r0.0:DF x0 y0 x1 y1
r0.1:DF z0 w0 z1 w1
and emit two 32-bit write messages, one for r0.0 at base_offset
and another one for r0.1 at base_offset+16.
We also need to do the inverse operation when we read using 32-bit messages
to produce valid SIMD4x2 64bit data from the data read. We can achieve this
by aplying the exact same shuffling to the data read, although we need to
apply different channel enables since the layout of the data is reversed.
This helper implements the data shuffling logic and we will use it in
various places where we read and write 64bit data from/to memory.
v2 (Curro):
- Use the writemask helper and don't assert on the original writemask
being XYZW.
- Use the Vec4 IR builder to simplify the implementation.
v3 (Iago):
- Use byte_offset() instead of offset().
v3:
- Fix typo (Matt)
- Clarify the example and fix indention (Matt).
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 28 Sep 2016 11:03:00 +0000 (13:03 +0200)]
i965/vec4: support multiple dispatch widths and groups in the IR builder.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 8 Jun 2016 09:04:34 +0000 (11:04 +0200)]
i965/vec4: Lower 64-bit MAD
The previous patch made sure that we do not generate MAD instructions
for any NIR's 64-bit ffma, but there is nothing preventing i965 from
producing MAD instructions as a result of lowerings or optimization
passes. This patch makes sure that any 64-bit MAD produced inside the
driver after translating from NIR is also converted to MUL+ADD before
we generate code.
v2:
- Use a copy constructor to copy all relevant instruction fields from
the original mad into the add and mul instructions
v3:
- Rename the lowering and fix commit log (Matt)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 8 Jun 2016 09:05:51 +0000 (11:05 +0200)]
i965/vec4/nir: do not emit 64-bit MAD
RepCtrl=1 does not work with 64-bit operands so we need to use RepCtrl=0.
In that situation, the regioning generated for the sources seems to be
equivalent to <4,4,1>:DF, so it will only work for components XY, which
means that we have to move any other swizzle to a temporary so that we can
source from channel X (or Y) in MAD and we also need to split the instruction
(we are already scalarizing DF instructions but there is room for
improvement and with MAD would be more restricted in that area)
Also, it seems that MAD operations like this only write proper output for
channels X and Y, so writes to Z and W also need to be done to a temporary
using channels X/Y and then move that to channels Z or W of the actual dst.
As a result the code we produce for native 64-bit MAD instructions is rather
bad, and much worse than just emitting MUL+ADD. For reference, a simple case
of a fully scalarized dvec4 MAD operation requires 15 instructions if we use
native MAD and 8 instructions if we emit ADD+MUL instead. There are some
improvements that we can do to the emission of MAD that might bring the
instruction count down in some cases, but it comes at the expense of a more
complex implementation so it does not seem worth it, at least initially.
This patch makes translation of NIR's 64-bit FMMA instructions produce MUL+ADD
instead of MAD. Currently, there is nothing else in the vec4 backend that emits
MAD instructions, so this is sufficient and it helps optimization passes see
MUL+ADD from the get go.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 1 Jun 2016 06:35:37 +0000 (08:35 +0200)]
i965/vec4: Skip swizzle to subnr in 3src instructions with DF operands
We make scalar sources in 3src instructions use subnr instead of
swizzles because they don't really use swizzles.
With doubles it is more complicated because we use vstride=0 in
more scenarios in which they don't produce scalar regions. Also
RepCtrl=1 is not allowed with 64-bit operands, so we should avoid
this.
v2: Fix typo (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Mon, 30 May 2016 07:08:04 +0000 (09:08 +0200)]
i965/vec4: fix indentation in pack_uniform_registers
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 29 Jun 2016 08:49:47 +0000 (10:49 +0200)]
i965/vec4: fix pack_uniform_registers for doubles
We need to consider the fact that dvec3/4 require two vec4 slots.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Mon, 18 Jul 2016 10:04:13 +0000 (12:04 +0200)]
i965/vec4: teach register coalescing about 64-bit
Specifically, at least for now, we don't want to deal with the fact that
channel sizes for fp64 instructions are twice the size, so prevent
coalescing from instructions with a different type size.
Also, we should check that if we are coalescing a register from another
MOV we should be writing the same amount of data in both operations, otherwise
we end up wiring more or less than the original instruction. This can happen,
for example, when we have split fp64 MOVs with an exec size of 4 that only
write one register each and then a MOV with exec size of 8 that reads both.
We want to avoid the pass to think that it can coalesce from the first split
MOV alone. Ideally we would like the pass to see that it can coalesce from both
split MOVs instead, but for now we keep it simple.
Finally, the pass doesn't support coalescing of multiple registers but in the
case of normal SIMD4x2 double-precision instructions they naturally write two
registers (one per vertex) and there is no reason why we should not allow
coalescing in this case. Change the restriction to bail if we see instructions
that write more than 8 channels, where the channels can be 32-bit or 64-bit.
v2:
- Make sure that scan_inst and inst write the same amount of data.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 25 May 2016 12:29:39 +0000 (14:29 +0200)]
i965/disasm: fix subreg for dst in Align16 mode
There is a single bit for this, so it is a binary 0 or 1 meaning
offset 0B or 16B respectively.
v2:
- Since brw_inst_dst_da16_subreg_nr() is known to be 1, remove it
from the expression (Curro)
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Mon, 18 Jul 2016 11:43:00 +0000 (13:43 +0200)]
i965/vec4: implement access to DF source components Z/W
The general idea is that with 32-bit swizzles we cannot address DF
components Z/W directly, so instead we select the region that starts
at the the 16B offset into the register and use X/Y swizzles.
The above, however, has the caveat that we can't do that without
violating register region restrictions unless we probably do some
sort of SIMD splitting.
Alternatively, we can accomplish what we need without SIMD splitting
by exploiting the gen7 hardware decompression bug for instructions
with a vstride=0. For example, an instruction like this:
mov(8) r2.x:DF r0.2<0>xyzw:DF
Activates the hardware bug and produces this region:
Component: x0 y0 z0 w0 x1 y1 z1 w1
Register: r0.2 r0.3 r0.2 r0.3 r1.2 r1.3 r1.2 r1.3
Where r0.2 and r0.3 are r0.z:DF for the first vertex of the SIMD4x2
execution and r1.2 and r1.3 are the same for the second vertex.
Using this to our advantage we can select r0.z:DF by doing
r0.2<0,2,1>.xyxy and r0.w by doing r0.2<0,2,1>.zwzw without needing
to split the instruction.
Of course, this only works for gen7, but that is the only hardware
platform were we implement align16/fp64 at the moment.
v2: Adapted to the fact that we now do this after converting to
hardware registers (Iago)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Tue, 24 May 2016 09:01:27 +0000 (11:01 +0200)]
i965/vec4: translate 64-bit swizzles to 32-bit
The hardware can only operate with 32-bit swizzles, which is a rather
limiting restriction. However, the idea is not to expose this to the
optimization passes, which would be a mess to deal with. Instead, we let
the bulk of the vec4 backend ignore this fact and we fix the swizzles right
at codegen time.
At the moment the pass only needs to handle single value swizzles thanks to
the scalarization pass that runs before it.
Notice that this only works for X/Y swizzles. We will add support for Z/W
swizzles in the next patch, since they need a bit more work.
v2 (Sam):
- Do not expand swizzle of 64-bit immediate values.
v3:
- Do this after translation to hardware registers instead of doing it right
before so we don't need the force_vstride0 flag (Curro).
- Squashed patch that included FIXED_GRF in the list of register files that
need this translation (Iago).
- Remove swizzle assignments for VGRF and UNIFORM files in
convert_to_hw_regs(), they will be set by apply_logical_swizzle() (Iago).
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Tue, 24 May 2016 07:20:51 +0000 (09:20 +0200)]
i965/vec4: add a scalarization pass for double-precision instructions
The hardware only supports 32-bit swizzles, which means that we can
only access directly channels XY of a DF making access to channels ZW
more difficult, specially considering the various regioning restrictions
imposed by the hardware. The combination of both things makes handling
ramdom swizzles on DF operands rather difficult, as there are many
combinations that can't be represented at all, at least not without
some work and some level of instruction splitting depending on the case.
Writemasks are 64-bit in general, however XY and ZW writemasks also work
in 32-bit, which means these writemasks can't be represented natively,
adding to the complexity.
For now, we decided to try and simplify things as much as possible to
avoid dealing with all this from the get go by adding a scalarization
pass that runs after the main optimization loop. By fully scalarizing
DF instructions in align16 we avoid most of the complexity introduced
by the aforementioned hardware restrictions and we have an easier path
to an initial fully functional version for the vector backend in Haswell
and IvyBridge.
Later, we can improve the implementation so we don't necessarily
scalarize everything, iteratively adding more complexity and building
on top of a framework that is already working. Curro drafted some ideas
for how this could be done here:
https://bugs.freedesktop.org/show_bug.cgi?id=92760#c82
v2:
- Use a copy constructor for the scalar instructions so we copy all
relevant instructions fields from the original instruction.
v3: Fix indention in one switch (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 17 Jun 2016 06:47:29 +0000 (08:47 +0200)]
i965/vec4: split double-precision SEL
There is a hardware bug affecting compressed double-precision SEL
instructions in align16 mode by which they won't read predication mask
properly. The bug does not affect other predicated instructions
and it does not affect SEL in Align1 mode either. This was found
empirically and verified by Curro in the simulator.
Fix this by splitting double-precision SEL in Align16 mode to use an
execution size of 4.
v2: Check that the dst type is 64-bit, since we can have 16-wide single
precision bcsel instructions that also write 2 registers.
v3: Replace bcsel by SEL in all the comments as bcsel is the nir opcode
but SEL is the actual assembly instruction (Matt).
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 15 Sep 2016 09:30:32 +0000 (11:30 +0200)]
i965/vec4: teach cmod propagation about different execution sizes
We can't propagate the conditional modifier from one instruction to
another of a different execution size / group, since that would change
the channels affected by the conditional.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 16 Jun 2016 11:49:55 +0000 (13:49 +0200)]
i965/vec4: teach CSE about exec_size, group and doubles
v2: adapt to changes in offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 17 Jun 2016 06:21:19 +0000 (08:21 +0200)]
i965/disasm: print NibCtrl for instructions with execsize < 8
v2 (Curro):
- Print it also for execsize < 4.
- QtrCtrl is still in effect, so print 2 * qtr_ctl + nib_ctl + 1
- Do not read the nib ctl from the instruction in gen < 7,
the field only exists in gen7+.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 29 Jun 2016 06:40:27 +0000 (08:40 +0200)]
i965/vec4: dump NibCtrl for instructions with execsize != 8
v2: do it in the same fashion as the FS backend for consistency (Curro)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 17 Jun 2016 06:49:44 +0000 (08:49 +0200)]
i965/vec4: make the generator set correct NibCtrl for SIMD4 DF instructions
From the HSW PRM, Command Reference, QtrCtrl:
"NibCtrl is only allowed for SIMD4 instructions with a DF (Double Float)
source or destination type."
v2: Assert that the type is DF (Samuel)
v3: Don't set the default group to 0 and then set it only for 4-wide
instructions. Instead, assert that exec size and group are always
a correct match and then always set the default group from the
instruction. (Curro)
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Mon, 29 Aug 2016 08:41:45 +0000 (10:41 +0200)]
i965/vec4: add a SIMD lowering pass
Generally, instructions in Align16 mode only ever write to a single
register and don't need any form of SIMD splitting, that's why we
have never had a SIMD splitting pass in the vec4 backend. However,
double-precision instructions typically write 2 registers and in
some cases they run into certain hardware bugs and limitations
that we need to work around by splitting the instructions so we only
write to 1 register at a time. This patch implements a SIMD splitting
pass similar to the one in the scalar backend.
Because we only use double-precision instructions in Align16 mode
in gen7 (gen8+ is fully scalar and gens < 7 do not implement fp64)
the pass should be a no-op on any other generation.
For now the pass only handles the gen7 restriction where any
instruction that writes 2 registers also needs to read 2 registers.
This affects double-precision instructions reading uniforms, for
example. Later patches will extend the lowering pass adding a few
more cases.
v2:
- Move the simd lowering pass after the main optimization loop and
run copy-propagation and dce if it reports progress (Curro)
- Compute number of registers written instead of fixing it to 1 (Iago)
- Use group from backend_instruction (Iago)
- Drop assertion that checked that we only split 8-wide instructions
into 4-wide. (Curro)
- Don't assume that instructions can only be 8-wide, we might want
to use 16-wide instructions in the future too (Curro)
- Wrap gen7 workarounds in a conditional to ease adding workarounds
for other gens in the future (Curro)
- Handle dst/src overlap hazard (Curro)
- Use the horiz_offset() helper to simplify the implementation (Curro)
- Drop the assertion that checks that each split instruction writes
exactly one register (Curro)
- Use the copy constructor to generate split instructions with all
the relevant fields initialized to the values in the original
instruction instead of copying only a handful of them manually (Curro)
v3 (Iago):
- When copying to a temporary, allocate the number of registers required
for the copy based on the size written of the lowered instruction
instead of assuming that all lowered instructions produce single-register
writes
- Adapt to changes in offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 25 Aug 2016 10:02:43 +0000 (12:02 +0200)]
i965: move the group field from fs_inst to backend_instruction.
Just like the exec_size, we are going to need this in the vec4 backend
when we implement a simd splitting pass.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 25 Aug 2016 08:02:45 +0000 (10:02 +0200)]
i965/vec4: add a horiz_offset() helper
This will come in handy when we implement a simd lowering pass in a
follow-up patch.
v2: use byte_offset()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Juan A. Suarez Romero [Fri, 10 Jun 2016 11:55:00 +0000 (13:55 +0200)]
i965/vec4: handle 32 and 64 bit channels in liveness analysis
Our current data flow analysis does not take into account that channels
on 64-bit operands are 64-bit. This is a problem when the same register
is accessed using both 64-bit and 32-bit channels. This is very common
in operations where we need to access 64-bit data in 32-bit chunks,
such as the double packing and packing operations.
This patch changes the analysis by checking the bits that each source
or destination datatype needs. Actually, rather than bits, we use
blocks of 32bits, which is the minimum channel size.
Because a vgrf can contain a dvec4 (256 bits), we reserve 8
32-bit blocks to map the channels.
v2 (Curro):
- Simplify code by making the var_from_reg helpers take an extra
argument with the register component we want.
- Fix a couple of cases where we had to update the code to the new
way of representing live variables.
v3:
- Fix indent in multiline expressions (Matt)
- Fix comment's closing tag (Matt)
- Use DIV_ROUND_UP(inst->size_written, 16) instead of 2 * regs_written(inst)
to avoid rounding issues. The same for regs_read(i). (Curro).
- Add asserts in var_from_reg() to avoid exceeding the allocated
registers (Curro).
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Iago Toral Quiroga [Mon, 30 May 2016 11:36:30 +0000 (13:36 +0200)]
i965/vec4: dump the instruction execution size
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Mon, 29 Aug 2016 08:45:47 +0000 (10:45 +0200)]
i965/vec4: use the IR's execution size
In the vec4 backend the generator sets to 8 the execution size for all
instructions by default, however, to implement 64-bit floating-point we
will need to split certain instruction into smaller sizes so we need the
IR to convey this information like we do in the scalar backend. This patch
uses the execution size from the vec4 IR.
We will use this feature in a later patch when we implement a SIMD
splitting pass.
v2:
- Drop the assertion on the execution size being 8 or 4 (Curro)
- Use exec_size from backend_instruction (Curro)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Mon, 30 May 2016 11:20:31 +0000 (13:20 +0200)]
i965/vec4: fix regs_read() for doubles
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Mon, 30 May 2016 11:31:25 +0000 (13:31 +0200)]
i965/vec4: fix size_written for doubles
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 25 Aug 2016 09:49:53 +0000 (11:49 +0200)]
i965: move exec_size from fs_instruction to backend_instruction
We are going to need this in the vec4 backend too.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Samuel Iglesias Gonsálvez [Thu, 7 Jul 2016 11:35:30 +0000 (13:35 +0200)]
i965/vec4: use the new helper function to create double immediates
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 9 Mar 2016 15:37:33 +0000 (16:37 +0100)]
i965/vec4: add a helper function to create double immediates
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 (Curro):
- Use swizzle() and writemask() helpers and make tmp const.
v3 (Iago):
- Adapt to changes in offset()
Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 18 Feb 2016 08:24:16 +0000 (09:24 +0100)]
i965/vec4: fix optimize predicate for doubles
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 5 Feb 2016 09:12:57 +0000 (10:12 +0100)]
i965/vec4: implement fsign() for doubles
v2: use a MOV with a conditional_mod instead of a CMP, like we do in d2b, to skip
loading a double immediate.
v3: Fix comment (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 17 Feb 2016 12:08:47 +0000 (13:08 +0100)]
i965/vec4: implement d2b
v2 (Curro):
- Generate the flag register with a MOV with conditional_mod instead of a CMP
instruction, which has the benefit that we can skip loading a DF
0.0 constant.
- Avoid the PICK_LOW_32BIT + MOV by using the flag result and a
SEL to set the boolean result.
v3:
- Fix comment (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 17 Feb 2016 10:12:19 +0000 (11:12 +0100)]
i965/vec4: implement d2i, d2u, i2d and u2d
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 29 Jun 2016 11:08:25 +0000 (13:08 +0200)]
i965/vec4: implement HW workaround for align16 double to float conversion
From the BDW PRM, Workarounds chapter:
"DF->f format conversion for Align16 has wrong emask calculation when
source is immediate."
Notice that Broadwell and later are strictly scalar at the moment though, so
this is not really necessary.
v2: Instead of moving the immediate to a vgrf and converting from there, just
convert the double immediate to float in the compiler and move the result
to the destination (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 29 Jun 2016 11:07:35 +0000 (13:07 +0200)]
i965/vec4: add helpers for conversions to/from doubles
Use these helpers to implement d2f and f2d. We will reuse these helpers when
we implement things like d2i or i2d as well.
v2:
- Rename the helpers (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Wed, 17 Feb 2016 09:32:05 +0000 (10:32 +0100)]
i965/vec4: Rename DF to/from F generator opcodes
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>
Iago Toral Quiroga [Mon, 15 Feb 2016 09:07:42 +0000 (10:07 +0100)]
i965/vec4: fix register allocation for 64-bit undef sources
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 12 Feb 2016 12:10:06 +0000 (13:10 +0100)]
i965/vec4: make opt_vector_float ignore doubles
The pass does not support doubles in its current form.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Fri, 12 Feb 2016 07:47:21 +0000 (08:47 +0100)]
i965/vec4: fix get_nir_dest() to use DF type for 64-bit destinations
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>
Iago Toral Quiroga [Wed, 5 Oct 2016 08:54:35 +0000 (10:54 +0200)]
i965/vec4: fix indentation in get_nir_src()
Reviewed-by: Matt Turner <mattst88@gmail.com>
Iago Toral Quiroga [Thu, 13 Aug 2015 22:34:24 +0000 (15:34 -0700)]
i965/vec4/nir: implement double comparisons
v2:
- Added newline before if() (Matt)
Reviewed-by: Matt Turner <mattst88@gmail.com>