This works out to be a wash in terms of memory usage: We use more memory
to store the separate ALU instructions, but we optimize out a lot of code
as well. The main result, though, is that we do more of our work at link
time rather than draw time.
We don't want to bake the whole array into the FS key, because of the
hashing overhead. But we can keep a set of the arrays seen, and use a
pointer to the copy in as the array's proxy.
Between this and the previous patch, gl-1.0-blend-func now passes on
hardware, where previously it was filling the 256MB CMA area with shaders
and OOMing.
Drops 712 shaders from shader-db.
I found a shader in Tales of Maj'Eyal that contains:
if ssa_21 {
block block_1:
/* preds: block_0 */
...instructions that prevent the select peephole...
vec1 32 ssa_23 = imov ssa_4
vec1 32 ssa_24 = imov ssa_4.y
vec1 32 ssa_25 = imov ssa_4.z
/* succs: block_3 */
} else {
block block_2:
/* preds: block_0 */
vec1 32 ssa_26 = imov ssa_4
vec1 32 ssa_27 = imov ssa_4.y
vec1 32 ssa_28 = imov ssa_4.z
/* succs: block_3 */
}
block block_3:
/* preds: block_1 block_2 */
vec1 32 ssa_29 = phi block_1: ssa_23, block_2: ssa_26
vec1 32 ssa_30 = phi block_1: ssa_24, block_2: ssa_27
vec1 32 ssa_31 = phi block_1: ssa_25, block_2: ssa_28
Here, copy propagation will bail because phis cannot perform swizzles,
and CSE won't do anything because there is no dominance relationship
between the imovs. By making nir_opt_remove_phis handle identical moves,
we can eliminate the phis and rewrite everything to use ssa_4 directly,
so all the moves become dead and get eliminated.
I don't think we need to check "exact" - just the alu sources.
Presumably phi sources should match in their exactness.
On Broadwell:
total instructions in shared programs: 11639872 -> 11638535 (-0.01%)
instructions in affected programs: 134222 -> 132885 (-1.00%)
helped: 338
HURT: 0
v2: Fix return value to be NULL, not false (caught by Iago).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Previously, we allocated a new VGRF for every undefined definition.
Instead, this patch makes us allocate a new VGRF for every use of an
undefined definition. This makes sure that undefined values are
fully independent of one another, and have live ranges limited to
their single use. This allows register coalescing to combine the
source and destination of MOVs from undefined sources, eliminating
the MOV altogether.
On Broadwell:
total instructions in shared programs: 11641187 -> 11640214 (-0.01%)
instructions in affected programs: 70199 -> 69226 (-1.39%)
helped: 213
HURT: 1
v2: Add a comment (based on Iago's suggested one).
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Without this, the X server may accumulate stale Present event contexts
if a client performs several video decoding sessions using the same
window.
v2: Based on Chris Wilson's review:
* Use xcb_discard_reply() instead of free(xcb_request_check())
Reviewed-and-Tested-by: Leo Liu <leo.liu@amd.com>
Without this, the X server may accumulate stale Present event contexts
if a client ends up creating and destroying DRI drawables for the same
window.
v2: Based on Chris Wilson's review:
* Use xcb_present_select_input_checked so that protocol errors
generated by old X servers can be handled gracefully
* Use xcb_discard_reply() instead of free(xcb_request_check())
We were baking in the LOD of the source level to each shader. Instead,
pass it in as a uniform -- this requires storing it to a temp register,
but that's better than compiling a ton of separate shaders:
total instructions in shared programs: 115032 -> 115036 (0.00%)
instructions in affected programs: 96 -> 100 (4.17%)
LOST: 572
This helps in debugging memory pressure. It would be nice if we could
tell valgrind about it all the way from allocation time to destroy, but we
need a pointer to hand to VALGRIND_MALLOCLIKE_BLOCK.
The ranges are in units of bytes, not dwords. This wasn't caught by
piglit tests because ttn tends to make one big uniform file, so we only
had one UBO range with a src and dst offset of 0.
nir_opt_peephole_select has the job of removing IF statements with no side
effects. However, if the IF statement's successor didn't have any
instructions in it, we were skipping it, which occurred in mupen64 on vc4
with glsl_to_nir enabled:
instructions in affected programs: 6134 -> 4120 (-32.83%)
total uniforms in shared programs: 38268 -> 38219 (-0.13%)
No changes on Haswell shader-db.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
v_fma_f32 runs at FP64 rate (= slow). Alien Isolation and F1 2015 seem
to use fma for all d3d multiply-add instructions, which is silly.
This tries to restore performance for those games.
The main difference between v_mad_f32 and v_fma_f32 is that v_mad doesn't
support denormals, which we don't enable anyway, because they are slow too.
Also, there is code size reduction:
Totals from affected shaders:
VGPRS: 109796 -> 109808 (0.01 %)
Spilled SGPRs: 29995 -> 30022 (0.09 %)
Spilled VGPRs: 12 -> 13 (8.33 %) <-- it's just one shader going from 12 to 13
Code Size: 6667596 -> 6476356 (-2.87 %) bytes
Max Waves: 26931 -> 26899 (-0.12 %)
I've not actually tested real performance.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
We need to include mt->offset in the calculation of src pointer because its
value may be non-zero, for example in a cubemap texture.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Cc: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Chad Versace <chad@kiwitree.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Change-Id: I461ad5b204626d5a1c45611fc6b63735dcf29f63
Looks like a copy and paste error from f752effa08
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
swr rasterizer contains numerous data transfers between vectors
and ordinary C types. Fixing for strict aliasing will take time.
Reviewed-by: Matt Turner <mattst88@gmail.com>
AST_NUM_OPERATORS stores the dimension of the ast_operators
enumeration but was not updated after its last modification.
This doesn't add any real modification for any code paths but it makes
sense for coherence.
v2 (Eric Engestrom): Just place the define at the end of the
enumeration, not below.
Signed-off-by: Andres Gomez <agomez@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Once upon a time (commit 8313f44409) Paul added code for the unlit
centroid workaround (WaCopyUnlitCentroidBarys). His commit message
claims it fixed the EXT_framebuffer_multisample/interpolation {2,4}
{centroid-deriv,centroid-deriv-disabled} piglit tests but does not say
on which platform, though he cites the IVB PRM.
"3DSTATE_WM [DevIVB, DevHSW]" says
"[DevIVB]: Workaround: When Centroid Barycentric mode is required, HW
may produce incorrect interpolation results when a 2X2 pixels have
unlit pixels."
I later disabled it for Haswell (commit f6db414f3c) with no known ill
effects.
The Sandybridge page does not have this text, but the workarounds
database (see WaCopyUnlitCentroidBarys) says the issues applies *only*
to Sandybridge, and in fact in commit 1a2de7dce8 I note that disabling
the workaround on Sandybridge causes the tests Paul originally mentioned
to fail.
So this is, and always has been, a huge confusing mess.
Disabling the workaround indeed causes the tests Paul originally
mentioned to fail on Sandybridge but not on Ivybridge/Baytrail.
On Ivybridge:
total instructions in shared programs: 6914901 -> 6909599 (-0.08%)
instructions in affected programs: 106766 -> 101464 (-4.97%)
helped: 884
total cycles in shared programs: 70874764 -> 70813774 (-0.09%)
cycles in affected programs: 794144 -> 733154 (-7.68%)
helped: 688
HURT: 186
LOST: 1
GAINED: 6
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
it cut off the upper 32 bits
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Improves performance of OglBatch7 by 4.06851% +/- 1.17925% (n=169) on
Haswell, and cuts ~18k of .text:
text data bss dec hex filename
5824627 287816 29384 6141827 5db783 before/i965_dri.so
5806354 287816 29384 6123554 5d7022 after/i965_dri.so
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This can be used by the driver to get the command line which started
the process. Will be used by the VMware driver for extra logging.
For now, this is only implemented for Linux via /proc/self/cmdline
and Windows via GetCommandLine().
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This patch eliminates the redundant SetVertexBuffers and
SetIndexBuffer commands that are emitted for rebind purpose.
With this patch, the set commands will be skipped, but we will still
reference the associated resources to allow the kernel to
bring in the resources.
Tested with Lightsmark2008, Valley, MTT glretrace, piglit, conform.
Reviewed-by: Brian Paul <brianp@vmware.com>
There are cases where we hit u_vbuf path due to alignment or pitch-
alignment restrictions, but for an output-format that u_vbuf does not
support translating (yet the driver does support natively). In which
case we hit the memcpy() path and don't care that u_vbuf doesn't
understand it.
Fixes crash with debug build of mesa in:
dEQP-GLES3.functional.vertex_arrays.single_attribute.strides.fixed.user_ptr_stride17_components2_quads1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95000
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
AFAICT, it's never been used.
It was briefly nudged in the right direction here:
commit 10e5ffd496
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date: Sat Jan 25 17:19:10 2014 +0000
gbm: do not export _gbm_mesa_get_device
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
