Support emission of the short imad, but also include it in the various
logic that tries to make it possible to emit.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
On NV50, we use 16-bit reg units (to make it all work with half-regs). A
few places assumed that it was always in 32-bit units.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This helps in the use of GALLIUM_DDEBUG_SKIP: first run a target application
with skip set to a very large number and note how many draw calls happen
before the bug. Then re-run, skipping the corresponding number of calls.
Despite the additional run, this can still be much faster than not skipping
anything.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When we know that hangs occur only very late in a reproducible run (e.g.
apitrace), we can save a lot of debugging time by skipping the flush and hang
detection for earlier draw calls.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
ARB_fragment_layer_viewport requires that if a fs reads layer or viewport
index but it wasn't output by gs (or vs with other extensions), then it reads
0. This never worked for llvmpipe, and is surprisingly non-trivial to fix.
The problem is the mechanism to handle non-existing outputs in draw is rather
crude, it will simply redirect them to whatever is at output 0, thus later
stages will just get garbage. So, rather than trying to fix this up (which
looks non-trivial), fix this up in llvmpipe setup by detecting this case there
and output a fixed zero directly.
While here, also optimize the hw vertex layout a bit - previously if the gs
outputted layer (or vp) and the fs read those inputs, we'd add them twice
to the vertex layout, which is unnecessary.
And do some minor cleanup, slots don't require that many bits, there was some
bogus (but harmless) float/int mixup for psize slot too, make the slots all
unsigned (we always put pos at pos zero thus everything else has to be positive
if it exists), and make sure they are properly initialized (layer and vp index
slot were not which looked fishy as they might not have got set back to zero
when changing from a gs which outputs them to one which does not).
This fixes the failures in piglit's arb_fragment_layer_viewport group
(3 each for layer and vp).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
This greatly reduces the number of SetSamplers() commands for some
applications.
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
The offset for loads is in src[0]. This was a copy+paste error in the
nir_intrinsic_load/store refactoring. This commit fixes a segfault in
ES31-CTS.compute_shader.work-group-size. I have no idea how piglit failed
to catch this...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93348
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
This is brw_gs_surface_state.c copy and pasted twice with search and
replace.
brw_binding_table.c code is similarly copy and pasted.
v2: Drop dword_pitch related fields.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>
Tessellation evaluation shaders work almost identically to vertex
shaders - we have a set of URB writes at the end of the program, and the
last one should terminate it.
Geometry shaders really are the special case, where multiple
EmitVertex() calls trigger URB writes in the middle of the program.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Tessellation evaluation shaders will use g4 instead. For now, make an
fs_reg called urb_handle and use that in place of hardcoding g1.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
This is a helper function for setting up the local invocation ID
payload according to the cs_prog_data generated by the compiler. It's
intended to be available to users of libi965_compiler so move it there.
GL likes to saturate your incoming color, but if that color's coming from
unpacking from unorms, there's no point. Ideally we'd have a range
propagation pass that cleans these up in NIR, but that doesn't seem to be
going to land soon. It seems like we could do a one-off optimization in
nir_opt_algebraic, except that doesn't want to operate on expressions
involving unpack_unorm_4x8, since it's sized.
total instructions in shared programs: 87879 -> 87761 (-0.13%)
instructions in affected programs: 6044 -> 5926 (-1.95%)
total estimated cycles in shared programs: 349457 -> 349252 (-0.06%)
estimated cycles in affected programs: 6172 -> 5967 (-3.32%)
No SSPD on openarena (which had the biggest gains, in its VS/CSes), n=15.
The caller isn't going to expect it from a return, so it would probably
get misinterpreted. If the caller had an unpack in its reg, that's fine,
but don't lose track of it.
I apparently broke this in a late refactor, in such a way that I decided
its tests were some of those interminable ones that I should just
blacklist from my testing. As a result, the refactors related to it were
totally wrong.
Mostly related to making sure the rasterizer can correctly
pick out the correct scissor box for the current viewport.
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
When GL_FRAMEBUFFER_SRGB is enabled any single-sampled renderbuffers
are resolved in intel_update_state because the hardware can't cope
with fast clears on SRGB buffers. In that case it's pointless to do a
fast clear because it will just be immediately resolved.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
SRGB buffers are not marked as losslessly compressible so previously
they would not be used for fast clears. However in practice the
hardware will never actually see that we are using SRGB buffers for
fast clears if we use the linear equivalent format when clearing and
make sure to resolve the buffer as a linear format before sampling
from it.
This is an important use case because by default the window system
framebuffers are created as SRGB so without this fast clears won't be
used there.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
SKL can't cope with the CCS buffer for SRGB buffers. Normally the
hardware won't see the SRGB formats because when GL_FRAMEBUFFER_SRGB
is disabled these get mapped to their linear equivalents. In order to
avoid relying on the CCS buffer when it is enabled this patch now
makes it flush the renderbuffers.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
For single-sampled textures the MCS buffer is only used to implement
fast clears. However the surface always needs to be resolved before
being used as a texture anyway so the the MCS buffer doesn't actually
achieve anything. This is important for Gen9 because in that case SRGB
surfaces are not supported for fast clears and we don't want the
hardware to see the MCS buffer in that case.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Adds MESA_META_FRAMEBUFFER_SRGB to the meta save state so that
GL_FRAMEBUFFER_SRGB will be disabled when performing the fast clear.
That way the render surface state will be programmed with the linear
equivalent format during the clear. This is important for Gen9 because
the SRGB formats are not marked as losslessly compressible so in
theory they aren't support for fast clears. It shouldn't make any
difference whether GL_FRAMEBUFFER_SRGB is enabled for the fast clear
operation because the color is not actually written to the framebuffer
so there is no chance for the hardware to apply the SRGB conversion on
it anyway.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Ilia Mirkin