| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
InstanceID is in VGPR2, not 1.
One more failure that CTS didn't catch up...
Reported-by: Alex Smith <[email protected]>
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
|
| |
This shouldn't be scanned in the pipeline.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
| |
Unused.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this initialization the temp registers used in tgsi_declaration
may used random indices, and this may result in failing translation from TGSI
with an error message "GPR limit exceeded", because the random index is greater
then the allowed limit implying that the shader uses more temporary registers then
available.
Signed-off-by: Gert Wollny <[email protected]>
Cc: <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First try with a "soft" depth, to try to schedule sfu instructions
further from their consumers, but fall back to hard depth (which might
result in stalling) if nothing else is avail to schedule.
Previously the consumer of a sfu instruction could end up scheduled
immediately after (since "hard" depth from sfu to consumer would be 0).
This works because legalize pass would insert a (ss) sync bit, but it
is sub-optimal since it would cause a stall.
Instead prioritize other instructions for 4 cycles if they would no
cause a nop to be inserted. This minimizes the stalling. There is a
slight penalty in general to overall # of instructions in shader (since
we could end up needing nop's later due to scheduling the "deeper" sfu
consumer later), but ends up being a wash on register pressure.
Overall this seems to be worth a 10+% gain in fps. Increasing the
"soft" depth of sfu consumer beyond 4 helps a bit in some cases, but 4
seems to be a good trade-off between getting 99% of the gain and not
increasing instruction count of shaders too much.
It's possible a similar approach could help for tex/mem instructions,
but the (sy) sync bit seems to trigger a switch to a different thread-
group to hide memory latency (possibly with some limits depending on
number of registers used?).
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
| |
If the blit isn't changing format, but is changing tiling, just lie and
call things ARGB (since the exact component order doesn't matter for a
tiling blit).
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Overall a nice 5-10% gain for most games. And more for things like
glmark2 texture benchmark.
There are some rough edges. In particular, the hardware seems to only
support tiling or component swap. (Ie. from hw PoV, ARGB/ABGR/RGBA/
BGRA are all the same format but with different component swap.) For
tiled formats, only ARGB is possible. This isn't a big problem for
*sampling* since we also have swizzle state there (and since
util_format_compose_swizzles() already takes into account the component
order, we didn't use COLOR_SWAP for sampling). But it is a problem if
you try to render to a tiled BGRA (for example) surface.
The next patch introduces a workaround for blitter, so we can generate
tiled textures in ABGR/RGBA/BGRA, but that doesn't help the render-
target case. To handle that, I think we'd need to keep track that the
tiled format is different from the linear format, which seems like it
would get extra fun with sampler views/etc.
So for now, disabled by default, enable with FD_MESA_DEBUG=ttile. In
practice it works fine for all the games I've tried, but makes piglit
grumpy.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
| |
The rules are sufficiently different for a5xx with tiled textures, so
split this out into something that can be implemented per-generation.
The a5xx specific implementation will come in a later patch.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
| |
Trivial. Found by Coccinelle.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
zlib provides a faster slice-by-4 CRC32 implementation than the
traditional single byte lookup one used by mesa. As most supported
platforms now link zlib unconditionally, we can easily use it.
Improvement for a 1MB buffer (avg MB/s, n=100, zlib 1.2.8):
i5-6600K C2D E4500
mesa zlib mesa zlib
443 1443 225% +/- 2.1% 403 1175 191% +/- 0.9%
It has been verified the calculation results stay the same after this
change.
Signed-off-by: Grazvydas Ignotas <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The next change wants to use some optional zlib functionality, however
not all platforms currently use zlib. Based on earlier Jordan Justen's
patches and their review feedback.
Signed-off-by: Grazvydas Ignotas <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Grazvydas Ignotas <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes a number of int64 piglit tests, for example:
generated_tests/spec/arb_gpu_shader_int64/execution/built-in-functions/fs-sign-i64vec2.shader_test
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
| |
These will be used in the following patch.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
V2: just zero-extend the 32-bit value.
Fixes a number of int64 piglet tests, for example:
generated_tests/spec/arb_gpu_shader_int64/execution/conversion/frag-conversion-explicit-bool-int64_t.shader_test
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assert() is replaced by unreachable(), to avoid following building error:
external/mesa/src/gallium/drivers/radeonsi/si_shader.c:1967:1:
error: control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
1 error generated.
Fixes: c797cd6 ("ac: add load_patch_vertices_in() to the abi")
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
| |
Fixes a bunch of arb_gpu_shader_fp64 piglit tests for example:
generated_tests/spec/arb_gpu_shader_fp64/execution/built-in-functions/fs-mix-double-double-double.shader_test
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
| |
Prevents potential infinite loops when a non-dispatched or discarded
channel never triggers the loop break condition.
|
|
|
|
|
| |
I think this should be equivalent other than power, and it's the kind of
comparison we use for nir_op_ieq.
|
|
|
|
| |
I was trying to do a NULL-destination UF, and it got removed.
|
|
|
|
|
|
|
|
| |
I had 3.x putting swizzling in the texture state only for 16-bit texture
returns, and in the shader for 32-bit. This may be due to having mixed up
the return channel setup on 3.x back before I had moved it into the
compiler. On 4.x, the non-border-color texwrap tests are passing nicely
with both 16 and 32-bit returns with swizzling in the texture state.
|
| |
|
|
|
|
|
| |
Now that the actions are reused for centroid and nonperspective, give them
a more generic name.
|
|
|
|
|
| |
The fxcd/fycd instructions now return half-integer pixel centers when not
doing sample-rate shading.
|
|
|
|
| |
Revealed that I was writing past the TSDA, not the Z buffer as I expected.
|
|
|
|
|
|
|
| |
The LDVARY signal now writes an arbitrary register, so I took out the
magic src register file and replaced it with an instruction with LDVARY
set so we have somewhere to hang a QFILE_TEMP destination for register
allocation.
|
| |
|
| |
|
|
|
|
|
|
| |
The V3D 3.x series of TMU writes with meaning depending on the texture
type is replaced with writes to specific registers for each texture
argument semantic.
|
|
|
|
|
| |
V3D 4.x texturing changes enough that #ifdefs would just make a mess of
it.
|
|
|
|
|
| |
For V4.1 texturing, I need the V4.1 XML, so the main compiler needs to
stop including V3.3 XML.
|
|
|
|
|
| |
We no longer have the small depth-specific output format enum, and instead
depth is just at the end of the output image format enum.
|
|
|
|
|
| |
The RGBX8 formats were dropped from V3D 4.x, but we don't really need them
anyway (we already handle other non-alpha formats by forcing A to 1).
|
| |
|
| |
|
|
|
|
|
| |
I want the library's entrypoints to still be unversioned, but the actual
packet dumping needs to be per-version.
|
|
|
|
|
| |
This is a major performance boost on all of V3D, but is required on V3D
4.x where shaders are always either 2- or 4-threaded.
|
|
|
|
|
|
|
|
|
|
| |
This fills in the delay slots of thread end as much as we can (other than
being cautious about potential TLBZ writes).
In the process, I moved the thread end THRSW instruction creation to the
scheduler. Once we start emitting THRSWs in the shader, we need to
schedule the thread-end one differently from other THRSWs, so having it in
there makes that easy.
|
|
|
|
| |
Apparently the VPM writes need to be flushed out before we end the shader.
|
|
|
|
|
| |
This required extending the CL submit ioctl, because the tile alloc/state
buffer setup has moved from the BCL to register writes.
|
|
|
|
|
| |
I had a .ifb being decoded weird in sampid, so this is to check that .ifb
is fine.
|
| |
|
|
|
|
|
| |
This is needed for LDVPM on V3D 4.x, but will also be needed for keeping
values out of the accumulators across THRSW.
|
|
|
|
|
|
|
|
|
|
|
| |
Now, instead of a magic write register for VPM stores we have an
instruction to do them (which means no packing of other ALU ops into it),
with the ability to reorder the VPM stores due to the offset being baked
into the instruction.
VPM loads also gain the ability to be reordered by packing the row into
the A argument. They also no longer write to the r3 accumulator, and
instead must be stored to a physical register.
|
|
|
|
|
| |
I had all the packing code in this file at one point, but these defines
now live in qpu_pack.c.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This required moving the register accesses to a separate v3dx file, since
the register definitions for each V3D version collide. It seems that
initializing the v3d_hw from a file dictating 3.3
(v3d_simulator_wrapper.cpp) is safe, though.
|
|
|
|
| |
Signals are more complicated than that, and tables ended up being better.
|