DXPredCopyRegion supports copy between src and dst for depth_and_stencil
formats if src and dst have same formats.
tested ith piglit
v2: As per Brian's comment, allow DXPredCopyRegion for depth+stencil buffers
if the blit mask is PIPE_MASK_ZS.
Tested with piglit tests and added new piglit test
arb_framebuffer_object-depth-stencil-blit to test this particular testcase.
Reviewed-by: Brian Paul <brianp@vmware.com>
Piglit tests which uses arb_clear_texture extension, have memory leak issue.
pipe_surface created in svga_clear_texture() was not deleted which happens to be
the cause for memory leak.
tested all arb_clear_texture-* piglit tests with valgrid.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
v2: Accounted for the fact that svga_try_clear_render_target also
honors conditional rendering.
Testing done: Excercised all functions in a separate feature branch. Forced
emission of conditional rendering commands when necessary.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This fixes a build regression of commit 7115e56c21.
Sorry for the breakage, this second location for link dependencies escaped
my build tests.
Bugzilla: https://patchwork.freedesktop.org/patch/119816/
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Fixes GL45-CTS.geometry_shader.adjacency.adjacency_indiced_triangle_strip and
others.
This leaves the case of triangle strips with adjacency and primitive restarts
open. It seems that the only thing that cares about that is a piglit test.
Fixing this efficiently would be really involved, and I don't want to use the
hammer of degrading to software handling of indices because there may well
be software that uses this draw mode (without caring about the precise
rotation of triangles).
v2:
- skip the GS prolog entirely if workaround is not needed
- only check for TES (TES is always non-null when tessellation is used)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The copy shader only depends on the selector. This change avoids creating
separate code paths for monolithic vs. non-monolithic geometry shaders.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
For fixed function TCS, we keep the copying of VS outputs to TES inputs inside
the main function; the call to si_copy_tcs_inputs is moved accordingly.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This helps to achieve a gradual transition towards building monolithic shaders
via inlining.
no_prolog and no_epilog will be removed by the end of the series,
separate_prolog remains in use to control the PS input mapping.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Change the pass manager as well, since this is a module-level pass. No
noticeable run-time difference on shader-db.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The incompatible signature becomes an issue when the VS epilog gets merged
with the main vertex shader at the IR level.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This limitation was initially here because AMD_performance_monitor
doesn't allow to expose the real number of hardware counters. But
this actually really annoying when profiling with qapitrace.
Anyways, performance counters are mostly for developers and
failures are expected if you try to monitor more queries than
supported.
This breaks amd_performance_monitor_measure but it's expected.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Event not_predicated_off_thread_inst_executed is SM35+.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
As previously written, these opcodes use the SM5 semantics which is
incompatible with GLSL when bits == 0, offset == 32.
At some point we may want to add BFI_SM5 etc. opcodes, but all users
currently either want (and expect!) the GLSL semantics or don't care.
Bitfield inserts are generated by the GLSL lower_instructions and
lower_packing_builtins passes with constant bits and offset arguments,
so any workaround code that drivers may have to emit to follow GLSL
semantics should be optimized away easily for those uses.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When the video coded size is different from frame size, we need the result
buffers are same as coded size, which are not size compatible with encode
required size, so that simply use no tunnel for this case instead of frame
by frame converting.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Otherwise fails the check of matching between decoder size and buffers
size in kernel.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Add frontend dependency concept in the DRAW_CONTEXT, which
allows serialization of frontend work if necessary.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
This allows the post-processor to easily detect the API thread and to
process frame information. The frame information is needed to
optimized how data is processed from worker threads.
Reviewed-by: Bruce Cherniak <bruce.cherniak@intel.com>
No change in behavior. ralloc_size is equivalent to rzalloc_size.
That will change though.
Calls not switched to rzalloc_size:
- ralloc_vasprintf
- glsl_type::name allocation (it's filled with snprintf)
- C++ classes where valgrind didn't show uninitialized values
I switched most of non-glsl stuff to rzalloc without checking whether
it's really needed.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The options specified in the CLOVER_EXTRA_BUILD_OPTIONS shell
variable are appended to the options specified by the OpenCL program
in the clBuildProgram function call, if any.
Analogously, the options specified in the CLOVER_EXTRA_COMPILE_OPTIONS
and CLOVER_EXTRA_LINK_OPTIONS variables are appended to the options
specified in clCompileProgram and clLinkProgram function calls,
respectively.
v2:
* rename to CLOVER_EXTRA_COMPILER_OPTIONS
* use debug_get_option
* append to linker options as well
v3: code cleanups
v4: separate CLOVER_EXTRA_LINKER_OPTIONS options
v5:
* fix documentation typo
* use CLOVER_EXTRA_COMPILER_OPTIONS in link stage
v6:
* separate in CLOVER_EXTRA_{BUILD,COMPILE,LINK}_OPTIONS
* append options in cl{Build,Compile,Link}Program
Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by[v1]: Edward O'Callaghan <funfunctor@folklore1984.net>
v7 [Francisco Jerez]: Slight simplification.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
OpenCL apps can quote arguments they pass to the OpenCL compiler, most
commonly include paths containing spaces.
If the Clang OpenCL compiler was called via a shell, the shell would
split the arguments with respect to to quotes and then remove quotes
before passing the arguments to the compiler. Since we call Clang as a
library, we have to split the argument with respect to quotes and then
remove quotes before passing the arguments.
v2: move to tokenize(), remove throwing of CL_INVALID_COMPILER_OPTIONS
v3: simplify parsing logic, use more C++11
v4: restore error throwing, clarify a comment
Signed-off-by: Vedran Miletić <vedran@miletic.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
The emitter tried to emit sub instead of subr when src0 has
actually a NEG modifier.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 12.0 13.0" <mesa-stable@lists.freedesktop.org>
This affects GF100:GK110 chipsets, but not GM107+ where the
logic is a bit different. The emitters tried to emit sub
instead of subr when src0 has a NEG modifier.
This fixes the following piglit tests glsl-fs-loop-nested
and glsl-vs-loop-nested.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
GCN can use a completely different tile mode for FMASK.
FMASK allocation now skips one unrelated amdgpu_surface_init codepath as
hinted by the assertion.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
I expect no change in behavior, because r600_texture.c forces the same
tile mode as the base texture has.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
These just say whether libdrm can assume that the latest radeon_surface
definition is used by Mesa.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This removes input-only parameters from the radeon_surf structure.
Some of the translation logic from pipe_resource to radeon_surf is moved to
winsys/radeon.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
npix_y will be removed. level[0].npix_y will be removed too. nblk_y should
be the same as npix_y if the block height == 1. However, nblk_y is aligned
to the tile size, so it can be greater than npix_y.
If that's a problem, we'll have to save the input height of surface_init
and use that.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Maybe this is why SDMA has been broken for many amdgpu users?
SDMA is the only block which is used with imported textures and relies
on this variable. DB also uses it, but it doesn't get imported textures,
so it's unaffected.
I do get SDMA failures on Tonga before this patch if R600_DEBUG=testdma
is changed to use imported textures.
Cc: 11.2 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This should fix random GPU hangs on Hawaii and Fiji.
Cc: 11.2 12.0 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Oh my god, I wonder what catastrophic issues this was causing on SI.
Cc: 13.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
When restoring something from shader cache we won't have and don't
want to create a nir_shader this change detaches the two.
There are other advantages such as being able to reuse the
shader info populated by GLSL IR.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
total instructions in shared programs : 3499888 -> 3499445 (-0.01%)
total gprs used in shared programs : 453866 -> 453803 (-0.01%)
total local used in shared programs : 21621 -> 21621 (0.00%)
total bytes used in shared programs : 32078952 -> 32074936 (-0.01%)
local gpr inst bytes
helped 0 39 119 119
hurt 0 0 0 0
Signed-off-by: Karol Herbst <karolherbst@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Shared memory is local to CTA, thus we should only wait for
prior memory writes which are visible to other threads in
the same CTA, and not at global level. This should speedup
compute shaders which use shared memory.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Only one face of Cubetextures was locked when in DEFAULT Pool.
Fixes:
https://github.com/iXit/Mesa-3D/issues/129
CC: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Axel Davy <axel.davy@ens.fr>
In the format fallback path,
the height was used instead of the depth.
CC: "12.0 13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Axel Davy <axel.davy@ens.fr>
We are not sure exactly what needs to be 0 initialized,
but we are missing some cases. 0 initialize all our current
aligned allocation.
Fixes Tree of Savior visual issues.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Add implementation for align_calloc,
which is align_malloc + memset.
v2: add if (ptr) before memset.
Fix indentation.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Leak introduced by:
a83dce0128
The patch also moves the part to
release changed.vs_const_i and changed.vs_const_b
before the if (!cb.buffer_size) check,
to avoid reuploading every draw call if
integer or boolean constants are dirty, but the shaders
use no constants.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
CC: "13.0" <mesa-stable@lists.freedesktop.org>
nvdisasm does not print a .S even though the bit is set.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
radeonsi also does the same thing. I suspect that this is likely to be a
no-op in reality, but it brings nouveau code closer to what the blob
produces. Plus it makes sense to not try to do auto-derivatives on this.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
This allows the driver to signal that it can't handle random
interleaving of attributes across buffers. This is required for
ARB_transform_feedback3, and it's initialized to whatever the previous
value of PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME was except for nv50 where
it is disabled. Note that the proprietary drivers never expose
ARB_transform_feedback3 on any GT21x's (where nouveau previously did),
and after some effort I was unable to get it to work.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Getting stores to NIR regs to not generate new MOVs is tricky, since the
result we're trying to store into the NIR reg may have been from a
conditional update of a temp, or a series of packed writes. The easiest
solution seems to be to require that nir_store_dest()'s arg comes from an
SSA temp.
This causes us to put in a few more temporary MOVs in the NIR SSA dest
case, but copy propagation successfully cleans those up.
The shader-db change is modest:
total instructions in shared programs: 93774 -> 93598 (-0.19%)
instructions in affected programs: 14760 -> 14584 (-1.19%)
total estimated cycles in shared programs: 212135 -> 211946 (-0.09%)
estimated cycles in affected programs: 27005 -> 26816 (-0.70%)
but I was seeing patterns in some register-allocation failures in DEQP
tests that looked like the extra MOVs would increase maximum register
pressure in loops. Some debug code indicates that that's not the case,
though I'm still a bit confused by that result.
Now we aren't limited to 256MB total allocated across a driver instance,
just 256MB at one time. We're still copying in and out, which should get
fixed.
Rather than having simulator mode changes scattered around vc4_bufmgr.c
and vc4_screen.c, make vc4_bufmgr.c just call a vc4_simulator_ioctl, which
then dispatches to a corresponding implementation.
This will give the simulator support a centralized place to do tricks like
storing most BOs directly in simulator memory rather than copying in and
out.
This leaves special casing of mmaping BOs and execution, because of the
winsys mapping.
The loop is scanning until the original max_ip (size of the BO), but we
want to not examine any code after the PROG_END's delay slots. There was
a block trying to do that, except that we had some early continue
statements if the signal wasn't a PROG_END or a BRANCH.
The failure mode would be that a valid shader is rejected because some
undefined memory after the PROG_END slots is parsed as a branch and the
rest of its setup is illegal. I haven't seen this in the wild, but
valgrind was complaining and the new userland simulator code started
triggering it.
A constant value of float type is not necessarily a ConstantFP: it could also
be a constant expression that for some reason hasn't been folded.
This fixes a regression in GL45-CTS.arrays_of_arrays_gl.InteractionFunctionCalls2
that was introduced by commit 3ec9975555.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This reverts commits 1af0641db3 and
a6ad49cbbd.
st/mesa adjusts the rasterizer state for us now.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Long story short, 3D and CP are aliased on Fermi and initializing
compute after pushing the MS sample coordinate offsets seems to
corrupt 3D state for weird reasons.
I still don't have the faintest clue what is going on, but
this seems to only affect Fermi generation. A possible fix
could be to use two different channels, one for 3D and one
for CP.
This fixes a bunch of regressions pinpointed by piglit.
Fixes: "nvc0: fix up image support for allowing multiple samples"
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This makes shader-db reports results for compute shaders.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
With ARB_gpu_shader5, texture offsets can be any source, including TEMPs
and IN's. Make sure to process them as regular sources so that we pick
up masks, etc.
This should fix some CTS tests that feed offsets directly to
textureGatherOffset, and we were not picking up the input use, thus not
advertising it in the shader header.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Dave Airlie <airlied@redhat.com>
Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org>
The state tracker tries to attach the info to the wrong shader. This is
easy enough to protect against.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Cc: 12.0 13.0 <mesa-stable@lists.freedesktop.org>
The predicate is always CC_NOT_P as defined in
processSurfaceCoordsNVE4(), so we only want to emit OR.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
These constant value VS PARAM exports:
- 0,0,0,0
- 0,0,0,1
- 1,1,1,0
- 1,1,1,1
can be loaded into PS inputs using the DEFAULT_VAL field, and the VS exports
can be removed from the IR to save export & parameter memory.
After LLVM optimizations, analyze the IR to see which exports are equal to
the ones listed above (or undef) and remove them if they are.
Targeted use cases:
- All DX9 eON ports always clear 10 VS outputs to 0.0 even if most of them
are unused by PS (such as Witcher 2 below).
- VS output arrays with unused elements that the GLSL compiler can't
eliminate (such as Batman below).
The shader-db deltas are quite interesting:
(not from upstream si-report.py, it won't be upstreamed)
PERCENTAGE DELTAS Shaders PARAM exports (affected only)
batman_arkham_origins 589 -67.17 %
bioshock-infinite 1769 -0.47 %
dirt-showdown 548 -2.68 %
dota2 1747 -3.36 %
f1-2015 776 -4.94 %
left_4_dead_2 1762 -0.07 %
metro_2033_redux 2670 -0.43 %
portal 474 -0.22 %
talos_principle 324 -3.63 %
warsow 176 -2.20 %
witcher2 1040 -73.78 %
----------------------------------------
All affected 991 -65.37 % ... 9681 -> 3353
----------------------------------------
Total 26725 -10.82 % ... 58490 -> 52162
v2: treat Undef as both 0 and 1
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com> (v1)
Tested-by: Edmondo Tommasina <edmondo.tommasina@gmail.com> (v1)
Found that information message while replaying a trace from
Metro 2033 Redux. Mark that property as useless for now.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
The per-element fetch has quite some calculations which are constant,
these can be moved outside both the per-element as well as the main
shader loop (llvm can figure out it's constant mostly on its own, however
this can have a significant compile time cost).
Similarly, it looks easier swapping the fetch loops (outer loop per attrib,
inner loop filling up the per vertex elements - this way the aos->soa
conversion also can be done per attrib and not just at the end though again
this doesn't really make much of a difference in the generated code). (This
would also make it possible to vectorize the calculations leading to the
fetches.)
There's also some minimal change simplifying the overflow math slightly.
All in all, the generated code seems to look slightly simpler (depending
on the actual vs), but more importantly I've seen a significant reduction
in compile times for some vs (albeit with old (3.3) llvm version, and the
time reduction is only really for the optimizations run on the IR).
v2: adapt to other draw change.
No changes with piglit.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Previous attempts to zero initialize all inputs were not really optimal
(though no performance impact was measurable). In fact this is not really
necessary, since we know the max number of inputs used.
Instead, just generate fetch for up to max inputs used by the shader,
directly replacing inputs for which there was no vertex element by zero.
This also cleans up key generation, which previously would have stored
some garbage for these elements.
And also drop the assertion which indicates such bogus usage by a
debug_printf (the whole point of initializing the undefined inputs was to
make this case safe to handle).
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Compilation to actual machine code can easily take as much time as the
optimization passes on the IR if not more, so print this out too.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
For the texturing packs, things looked pretty terrible. For every
lerp, we were repacking the values, and while those look sort of cheap
with 128bit, with 256bit we end up with 2 of them instead of just 1 but
worse, plus 2 extracts too (the unpack, however, works fine with a
single instruction, albeit only with llvm 3.8 - the vpmovzxbw).
Ideally we'd use more clever pack for llvmpipe backend conversion too
since we actually use the "wrong" shuffle (which is more work) when doing
the fs twiddle just so we end up with the wrong order for being able to
do native pack when converting from 2x8f -> 1x16b. But this requires some
refactoring, since the untwiddle is separate from conversion.
This is only used for avx2 256bit pack/unpack for now.
Improves openarena scores by 8% or so, though overall it's still pretty
disappointing how much faster 256bit vectors are even with avx2 (or
rather, aren't...). And, of course, eliminating the needless
packs/unpacks in the first place would eliminate most of that advantage
(not quite all) from this patch.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
During dual instance encoding submission, if the second encode task and first
encode task have no reference dependency, e.g. p following with idr-frame,
there is a chance the second task will use for its reconstructed picture
buffer the same buffer used by first task for its reference/reconstructed
picture. In this case, buffer corruption may occur depending on encoding
speed. Fix is to force flush these two tasks separately to avoid race condition
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98005
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Neha Bhende
Thomas Hellstrom
Charmaine Lee
Nicolai Hähnle
Samuel Pitoiset
Marek Olšák
Leo Liu
George Kyriazis
Serge Martin
Vedran Miletić
Timothy Arceri
Karol Herbst
Brian Paul
Axel Davy
Ilia Mirkin
Eric Anholt
Roland Scheidegger
Boyuan Zhang