This just adds support to the decoder, not actual SB support.
v1.1: fixup GDS relative mode. (Glenn).
Reviewed-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This function is going to get a lot messier with tessellation
so I'm going to use some macros to try and clean some bits
of common code up.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This moves to using an array of hw stages for the atoms.
Note this drops the 23 from the vertex shader, this value
is calculated internally when shaders are bound, so not
required here.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This changes the r600 specific GPR adjustment code
to use the stage defines, and arrays.
This is prep work for the tess changes later.
Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add a list of defines for the HW stages.
We will use this for GPR calculations amongst other things.
Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Use NULL tests of the form `if (ptr)' or `if (!ptr)'.
They do not depend on the definition of the symbol NULL.
Further, they provide the opportunity for the accidental
assignment, are clear and succinct.
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Use NULL tests of the form `if (ptr)' or `if (!ptr)'.
They do not depend on the definition of the symbol NULL.
Further, they provide the opportunity for the accidental
assignment, are clear and succinct.
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
These are unnecessary and are likely just left overs from prior
work.
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
On SM20 this gives:
total instructions in shared programs : 6299222 -> 6294240 (-0.08%)
total gprs used in shared programs : 944139 -> 944068 (-0.01%)
total local used in shared programs : 54116 -> 54116 (0.00%)
local gpr inst bytes
helped 0 126 2781 2781
hurt 0 55 11 11
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This way $r1 = $r0 + 4; c1[$r1] becomes c1[$r0+4].
On SM35:
total instructions in shared programs : 6206257 -> 6185058 (-0.34%)
total gprs used in shared programs : 911045 -> 910722 (-0.04%)
total local used in shared programs : 39072 -> 39072 (0.00%)
local gpr inst bytes
helped 0 417 4195 4195
hurt 0 280 0 0
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
This works when the add also has an immediate. This often happens in
address calculations. These addresses can then be inlined as well.
On code targeted to SM35:
total instructions in shared programs : 6223346 -> 6206257 (-0.27%)
total gprs used in shared programs : 911075 -> 911045 (-0.00%)
total local used in shared programs : 39072 -> 39072 (0.00%)
local gpr inst bytes
helped 0 119 3664 3664
hurt 0 74 15 15
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Even if the rasterizer has scissor disabled, we'll have whatever
vc4->scissor bounds were last set when someone set up a scissor, so we
shouldn't clip to them in that case.
Fixes piglit fbo-blit-rect, and a lot of MSAA tests once they're enabled.
We could potentially handle scissored blits when they're tile aligned, but
it doesn't seem worth it. If you're doing a scissored blit, you're
probably a testcase.
Fixes piglit's fbo-scissor-blit fbo
This implements more performance metrics than the previous support,
but some other metrics still need to be figured out.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
These performance metrics will be re-introduced in an upcoming
patch that will follow the same design as Fermi.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
inst_issued is performance metric not a hardware event on Kepler (SM30).
It will be re-introduced in an upcoming patch.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
SM30 is the compute capability version for GK104/GK106/GK107.
This also introduces a new signal group selection called UNK0F.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Move these to 'disasm' instead of the more verbose 'optmsgs' since, like
the tgsi dumps, it is useful without the more verbose compiler logging
enabled.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
For MSAA, we store full resolution tile buffer contents, which have their
own tiling format. Since they're full resolution buffers, we have to
align their size to full tiles.
We were checking that the blit started at 0 and was 1:1, but not that it
went to the full width of the surface, or that the width was aligned to a
tile. We then told it to blit to the full width/height of the surface,
causing contents to be stomped in a bunch of MSAA tests that happen to
include half-screen-width blits to 0,0.
I've played with a few different approaches to tweak instruction
priority according to how much they increase/decrease register pressure,
etc. But nothing seems to change the fact that compared to original
(pre-multiple-block-support) scheduler, in some edge cases we are
generating shaders w/ 5-6x higher register usage.
The problem is that the priority queue approach completely looses the
dependency between instructions, and ends up scheduling all paths at the
same time.
Original reason for switching was that recursive approach relied on
starting from the shader outputs array. But we can achieve more or less
the same thing by starting from the depth-sorted list.
shader-db results:
total instructions in shared programs: 113350 -> 105183 (-7.21%)
total dwords in shared programs: 219328 -> 211168 (-3.72%)
total full registers used in shared programs: 7911 -> 7383 (-6.67%)
total half registers used in shader programs: 109 -> 109 (0.00%)
total const registers used in shared programs: 21294 -> 21294 (0.00%)
half full const instr dwords
helped 0 322 0 711 215
hurt 0 163 0 38 4
The shaders hurt tend to gain a register or two. While there are also a
lot of helped shaders that only loose a register or two, the more
complex ones tend to loose significanly more registers used. In some
more extreme cases, like glsl-fs-convolution-1.shader_test it is more
like 7 vs 34 registers!
Signed-off-by: Rob Clark <robclark@freedesktop.org>
It causes confusion in sched if we need to split_addr() since otherwise
we wouldn't easily know which block the new addr instr will be scheduled
in. So just side-step the whole situation.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
We'll need to add similar for ir3_instruction, but following the pattern
to use 'id' seems confusing. Let's just go w/ generic 'data' as the
name.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Undefining the NDEBUG is relevant for release build, as they are the
ones that set it.
[Emil Velikov: split from previous patch]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
This follows the src/util/u_atomic_test.c model of undefining NDEBUG
unconditionally throughouth the XvMC tests, to force asserts regardless
of debug mode.
The comment on u_atomic_test.c is also fixed (read 'debug' where it
should have been 'release').
v2: s/debug/release/ in relevant comments
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
[Emil Velikov: keep the src/util/ hunk as separate patch]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Add missing `const` specifier for pointer pointing to a const struct.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Should have been part of commit f53f9eb8d4 "glapi: add GetPointervKHR
to the ES dispatch".
v2: comment out the ES1.1 symbol and use the same description (pattern)
as elsewhere (Matt)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93235
Fixes: f53f9eb8d4 "glapi: add GetPointervKHR to the ES dispatch".
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Tested-by: Vinson Lee <vlee@freedesktop.org> (v1)
Tested-by: Michel Dänzer <michel.daenzer@amd.com>