This is a pretty rare situation but this can happen though.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
It's what all the call-sites once, so gets rid of a bunch of inlined
glsl_get_base_type() at the call-sites.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
I tried first creating the auxiliary buffer the same time with the
color buffer. That, however, led me into a situation where we would
later create the rest of the mip-levels and the compression would
need to be disabled (it is only supported for single level buffers).
Here we try to create it on demand just before the hardware starts
to render. This is similar what we do with fast clear buffers,
their creation is deferred until the first clear.
This setup also gives the opportunity to detect if the miptree
represents the temporaty texture used internally in the mesa core.
This texture is mostly written by cpu and therefore enabling
compression for it doesn't make much sense.
Note that a heuristic is included. Floating point formats are not
enabled yet as they are only seen to hurt performance.
Some highlights with window system driver kept fixed to default
and only the application driver changing:
Manhattan: 8.32152% +/- 0.355881%
Offscreen: 9.09713% +/- 0.340763%
Glb trex: 8.46231% +/- 0.460624%
Offscreen: 9.31872% +/- 0.463743%
v2 (Ben): Re-use msaa layout type for single sampled case.
v3: Moved the deferred allocation of mcs to brw_try_draw_prims() and
brw_blorp_blit_miptrees() instead.
v4: (Ken): Drop MIPTREE_LAYOUT_ACCELERATED_UPLOAD when allocating mcs.
Do not enable for scanout buffers
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
v2: Add support for blorp and removed the support for meta
v3 (Ben): Add assertion on compressed non-fast clear - must
be partial clear.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Blorp blits use sampling engine which is capable of resolving
on the fly. Buffers are still resolved for blitter engine. Current
understanding is that blitter doesn't understand lossless compression.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Until now mcs was associated to single sampled buffers only for
fast clear purposes and it was therefore the responsibility of the
clear logic to allocate the aux buffer when needed. Now that normal
3D render or blorp blit may render with mcs enabled also, they need
to prepare the mcs just as well.
v2: Do not enable for scanout buffers
v3 (Ben):
- Fix typo in commit message.
- Check for gen < 9 and return early in brw_predraw_set_aux_buffers()
- Check for gen < 9 and return early in intel_miptree_prepare_mcs()
v4: Check for msaa_layput and number of samples to determine if
lossless compression is to used. Otherwise one cannot distuingish
between fast clear with and without compression.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Consider later on adding specific disable flags such as
MIPTREE_LAYOUT_DISABLE_AUX_MCS = 1 << 3, /* CCS_D */
MIPTREE_LAYOUT_DISABLE_AUX_CCS_E = 1 << 4,
MIPTREE_LAYOUT_DISABLE_AUX = MIPTREE_LAYOUT_DISABLE_AUX_MCS |
MIPTREE_LAYOUT_DISABLE_AUX_CCS_E,
and equivalent boolean/enums into miptree.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
v2: Check explicitly against base type of GL_FLOAT instead of
using _mesa_is_format_integer_color(). Otherwise we miss
GL_UNSIGNED_NORMALIZED.
v3 (Ben): Also call intel_miptree_supports_non_msrt_fast_clear()
in order to really check everything.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
v2 (Ben): Use combination of msaa_layout and number of samples
instead of introducing explicit type for lossless
compression (intel_miptree_is_lossless_compressed()).
v3 (Ben): Do not set fast claer state in surface state setup.
Moved into brw_postdraw_set_buffers_need_resolve()
using a separate patch.
v4: Support for blorp
v5 (Ben): Re-use gen8_get_aux_mode()
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Also use the opportunity to drop the unused surface type argument.
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
v2 (Ben): Introduce union for fast clear and resolve ops
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
This hasn't been visible before. It showed up with lossless
compression with:
dEQP-GLES3.functional.fbo.color.repeated_clear.sample.tex2d.rgb8
Current fast clear logic kicks color resolves even for gpu sampling.
In the test case this results into trashing of the fast color clear
state between two subsequent clears, and therefore each clear is
performed correctly.
With lossless compression the resolves are unnecessary and therefore
the clear state indicates that the buffer is already cleared. Without
considering if the previous color value was the same as the new,
clears that need to be performed are skipped and the buffer ends up
holding old pixel values.
v2 (Ken): Fix the comparison for gen < 9
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
I'd originally left this off because Orbital Explorer was hanging the
GPU, but it seems to be working these days. There have been a bunch
of changes since then, so we probably fixed something.
On my Broadwell laptop, both Synmark/GSCloth and Orbital Explorer seem
to run at approximately the same framerate in either mode. This is
despite large reductions in instruction count for Synmark, and large
increases for Orbital Explorer. It apparently just doesn't matter.
Switching to scalar mode will gain us fp64 support in the next release,
as vec4-mode support isn't yet ready.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Three Shadow of Mordor geometry shaders increase by a single
instruction, but the number of spills/fills in Orbital Explorer
is reduced from 194:1279 -> 82:454. No other programs are affected.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This looks like leftover cruft from an earlier attempt at writing
point size hacks. Each vertex has its own copy of gl_PointSize,
so accessing any vertex other than 0 would cause this to fail.
The tests seem to work fine without it.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Just trying to keep things from getting too ugly in the next commit.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
BLORP never touches these, and they're all non-pipelined. Some
are fairly large packets as well.
I haven't tried to benchmark this; the effect is likely to be small.
However, we may as well stop the pointless papercuts; maybe they'll
add up someday.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Class "ir_constant" had a bunch of constructors where the pointer member
"array_elements" had not been initialized. This could have lead to unsafe
code if something had tried to write anything to it. This patch fixes
this issue by initializing the pointer to NULL in all the constructors.
This issue was discovered by Coverity.
CID: 401603, 401604, 401605, 401610
Signed-off-by: Jakob Sinclair <sinclair.jakob@openmailbox.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
The SAMPLEMASK semantic should only return the bits set covered by the
current invocation. However we were always retrieving the covmask, which
returns the covered samples of the whole pixel.
When not doing per-sample invocation, this is precisely what we want.
However when doing per-sample invocation, we have to select the
sampleid'th bit and only return that. Furthermore, this means that we
have to have a 1:1 correlation for invocations and samples.
This fixes most
dEQP-GLES31.functional.shaders.sample_variables.sample_mask_in.*
tests. A few failures remain due to disagreements about nr_samples==1
logic as well as what happens with MSAA x2 RTs when the shading fraction
is 0.5.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This adds a first tentative .mailmap file, to canonicize contributor
name/emails in shortlogs and other statistical endeavours.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
According to the GLSL spec, if the user uses the fma() intrinsic to
generate a precise-consumed value, and you have it in your hardware, you
shouldn't split it. For a while now, we've been splitting all ffma's
up-front and then planned to fuse them later which isn't valid. Correctly
handling the GLSL behaviour fixes rendering corruptions in Tomb Raider.
The only reason why doing this possibly helped before was for ARB programs
which is handled by the previous commit.
Shader-db results on Haswell:
total instructions in shared programs: 7560300 -> 7561510 (0.02%)
instructions in affected programs: 56265 -> 57475 (2.15%)
helped: 86
HURT: 291
The only shaders in the database that are affected are from "Shadow of
Mordor" which is the first app in our database to use fma(). We could, at
some point in the future, split inexact ffma opcodes which would fix the
shader-db regressions since Shadow of Mordor doesn't ues precise. However,
this fixes a bug now and and the shader-db impact is fairly small.
Reported-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Unlike fma() in GLSL, MAD in ARB programs is 100% splittable. Just emit
the split version and let the optimizer fuse them later.
Shader-db results on Haswell:
total instructions in shared programs: 7560379 -> 7560300 (-0.00%)
instructions in affected programs: 143928 -> 143849 (-0.05%)
helped: 443
HURT: 250
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The i965 driver has its own pass for fusing mul+add combinations that's
much smarter than what nir_opt_algebraic can do so we don't want to get the
nir_opt_algebraic one just because we didn't set lower_ffma.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Previous rename of lower-output-to-temps pass predated merging of anv,
and apparently vulkan wasn't enabled in my local builds so overlooked
this when rebasing.
Reported-by: Mark Janes <mark.a.janes@intel.com>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
We'll need this for a nir pass to lower builtin-uniform access.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Prep work to reduce the noise in the next patch.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Going to convert this pass to parameterized lower_io_to_temporaries, and
we want the user to be able to specify whether to lower outputs or
inputs or both. The restriction of running this pass before validate
to avoid output reads no longer applies.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
A pass to lower complex (struct/array/mat) inputs/outputs to primitive
types. This allows, for example, linking that removes unused components
of a larger type which is not indirectly accessed.
In the near term, it is needed for gallium (mesa/st) support for NIR,
since only used components of a type are assigned VBO slots, and we
otherwise have no way to represent that to the driver backend. But it
should be useful for doing shader linking in NIR.
v2: use glsl_count_attribute_slots() rather than passing a type_size
fxn pointer
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Handled by tgsi_emulate for glsl->tgsi case.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The goal is to allow the pipe driver to request something other than
TGSI, but detect whether what is getting is TGSI vs what it requested.
The pipe drivers will always have to support TGSI (and convert that into
whatever it is that they prefer), but in some cases we should be able to
skip the TGSI intermediate step (such as glsl->nir vs glsl->tgsi->nir).
I think pipe_compute_state should get similar treatment. Currently,
afaict, it has one user and one consumer, which has allowed it to be
sloppy wrt. supporting alternative IR's.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The use of transfer_inline_write() in TexSubImage path (see fb9fe352ea)
exposed a bug for "layer_first" resources (ie. a4xx) not setting correct
layer_stride.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Currently, when cross validating global variables, all global variables
seen in the shaders that are part of a program are saved in a table.
When checking a variable this already exist in the table, we check both
are initialized to the same value. If the already saved variable does
not have an initializer, we copy it from the new variable.
Unfortunately this is wrong, as we are modifying something it is
constant. Also, if this modified variable is used in
another program, it will keep the initializer, when it should have none.
Instead of copying the initializer, this commit replaces the old
variable with the new one. So if we see again the same variable with an
initializer, we can compare if both are the same or not.
v2: convert tabs in whitespaces (Kenenth Graunke)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Juha-Pekka found this back in May 2015:
<1430915727-28677-1-git-send-email-juhapekka.heikkila@gmail.com>
From the discussion, obviously it would be preferable to make
ralloc_size no longer return zeroed memory, but Juha-Pekka found that
it would break Mesa.
In <56AF1C57.2030904@gmail.com>, Juha-Pekka mentioned that patches
exist to fix i965 when ralloc_size is fixed to not zero memory, but
the patches have not made their way to mesa-dev yet.
For now, let's stop doing the double zeroing of rzalloc buffers.
v2:
* Move ralloc_size code to rzalloc_size, and add a comment as
suggested by Ken.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
