| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
pointed out by clang (stored value never read)
|
|
|
|
| |
pointed out by clang (stored value never read)
|
|
|
|
|
|
|
|
|
| |
This makes bin/gl-3.2-layered-rendering-gl-layer-render fail only with
2DMS_ARRAY, which is expected given the lackluster MSAA support. However
all the regular types pass.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Bruce Cherniak <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expectations.
Currently the GLSL-to-TGSI translation pass assumes it can use
floating point source modifiers on the UCMP instruction. See the bug
report linked below for an example where an unrelated change in the
GLSL built-in lowering code for atan2 (e9ffd12827ac11a2d2002a42fa8eb1)
caused the generation of floating-point ir_unop_neg instructions
followed by ir_triop_csel, which is translated into UCMP with a negate
modifier on back-ends with native integer support.
Allowing floating-point source modifiers on an integer instruction
seems like rather dubious design for a transport IR, since the same
semantics could be represented as a sequence of MOV+UCMP instructions
instead, but supposedly this matches the expectations of TGSI
back-ends other than tgsi_exec, and the expectations of the DX10 API.
I take no responsibility for future headaches caused by this
inconsistency.
Fixes a regression of piglit glsl-fs-tan-1 on softpipe introduced by
the above-mentioned glsl front-end commit. Even though the commit
that triggered the regression doesn't seem to have made it to any
stable branches yet, this might be worth back-porting since I don't
see any reason why the bug couldn't have been reproduced before that
point.
Suggested-by: Roland Scheidegger <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99817
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
| |
General protection and prevents us from smashing the stack
on the first clear state validation (a7b8d50bcb). Fixes crash
using icc.
Reviewed-by: Bruce Cherniak <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This massively decreases VGPR spilling for DiRT Showdown, because we
no longer have to use v4i32 for 2D fetches when level == 0.
We now use v2i32 for those cases.
DiRT Showdown - Spilled VGPRs: -26 (-81%)
This surprisingly doesn't have any useful effect on performance (+ 0.05%).
|
|
|
|
| |
for better code generation in radeonsi
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Initially this was a workaround for a bug introduced in LLVM 4.0
in the SimplifyCFG pass that caused image instrinsics to disappear
(because they were badly sunk). Finally, this is a win because it
decreases SGPR spilling and increases the number of waves a bit.
Although, shader-db results are good I think we might want to
remove it in the future once the issue is fixed. For now, enable
it for LLVM >= 4.0.
This also fixes a rendering issue with the speedometer in Dirt Rally.
More information can be found here https://reviews.llvm.org/D26348.
Thanks to Dave Airlie for the patch.
v2: - add a FIXME comment
- use if (HAVE_LLVM >= 0x0400) instead
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99484
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97988
Signed-off-by: Samuel Pitoiset <[email protected]>
Cc: 17.0 <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
Will also help when the src sampler register will be
TGSI_FILE_CONSTANT for bindless.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Analogous to previous commit
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Tested-by: Mike Lothian <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This refactors out the code and fixes it up to be used
for images later. It uses the code in the current RAT binding
for compute.
Reviewed-by: Edward O'Callaghan <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This moves the code to create CB info out into
a separate function so it can be reused in images
code to create RATs.
Reviewed-by: Edward O'Callaghan <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
This refactors out the code to setup a texture resource
so we can reuse it later from the images code.
Reviewed-by: Edward O'Callaghan <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This takes the code required to initialise a buffer resource
out of the texture buffer code, into it's own function.
This is going to be used for the image support later.
Reviewed-by: Edward O'Callaghan <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
In order to make ARB_shader_image_load_store, we have to share
the CB space with RATs, so we should only steal the dual src
space if we have dual src enabled.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The NIR story on conversion opcodes is a mess. We've had way too many
of them, naming is inconsistent, and which ones have explicit sizes was
sort-of random. This commit re-organizes things and makes them all
consistent:
- All non-bool conversion opcodes now have the explicit size in the
destination and are named <src_type>2<dst_type><size>.
- Integer <-> integer conversion opcodes now only come in i2i and u2u
forms (i2u and u2i have been removed) since the only difference
between the different integer conversions is whether or not they
sign-extend when up-converting.
- Boolean conversion opcodes all have the explicit size on the bool and
are named <src_type>2<dst_type>.
Making things consistent also allows nir_type_conversion_op to be moved
to nir_opcodes.c and auto-generated using mako. This will make adding
int8, int16, and float16 versions much easier when the time comes.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
| |
otherwise, cached shaders aren't dumped.
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
| |
This should prevent cases when a buffer was incorrectly mapped without
synchronization just because this wasn't done.
Cc: 13.0 17.0 <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the following segmentation fault:
signal SIGSEGV: invalid address (fault address: 0x0)
frame #0: 0x00007fffe718e117 radeonsi_dri.so hud_draw_background_quad hud_context.c:170
167
168 assert(hud->bg.num_vertices + 4 <= hud->bg.max_num_vertices);
169
-> 170 vertices[num++] = (float) x1;
171 vertices[num++] = (float) y1;
172
173 vertices[num++] = (float) x1;
(lldb) bt
* frame #0: 0x00007fffe718e117 radeonsi_dri.so`hud_draw_background_quad
frame #1: 0x00007fffe718f458 radeonsi_dri.so`hud_draw
frame #2: 0x00007fffe712967f radeonsi_dri.so`dri_flush
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow-up of patch:
"radeon_cs_create_fence: check null return from radeon_winsys_bo_create"
radeon_drm_cs_flush
radeon_cs_create_fence
radeon_winsys_bo_create
Signed-off-by: Julien Isorce <[email protected]>
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the following segmentation fault:
radeon_drm_cs_add_buffer (bo=0x0) at radeon_drm_cs.c
-> if (!bo->handle)
(gdb) bt
0 radeon_drm_cs_add_buffer (bo=0x0) at radeon_drm_cs.c
1 0x00007fffe73575de in radeon_cs_create_fence radeon_drm_cs.c
2 0x00007fffe7358c48 in radeon_drm_cs_flush radeon_drm_cs.c
Signed-off-by: Julien Isorce <[email protected]>
Signed-off-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rely on nir for optimization, to reduce compile times. Very minimal impact
on shader-db:
total instructions in shared programs: 104170 -> 104199 (0.03%)
total dwords in shared programs: 209664 -> 209728 (0.03%)
total full registers used in shared programs: 7156 -> 7161 (0.07%)
total half registers used in shader programs: 109 -> 109 (0.00%)
total const registers used in shared programs: 24222 -> 24224 (0.01%)
half full const instr dwords
helped 12 107 103 112 98
hurt 11 104 105 115 102
But shader db runtime dropped from ~29.3s user to ~20.4s user.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
| |
Fixes: 62cff793785 ("gallium: add P016 format")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100180
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Advertise 10bpp support if the driver supports decoding to a P016 surface.
v2: Advertise 10bpp for the decoder as well.
Signed-off-by: Christian König <[email protected]>
Signed-off-by: Mark Thompson <[email protected]>
|
|
|
|
|
|
|
| |
We support P010 and P016 as targets for 10bpp video decoding.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Mark Thompson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
No hardware I know off can actually support P010 natively. But we can easily
support P016 and as long as nobody decodes anything into the lower 6bits it
doesn't make any difference to P010.
v2: allow P0160 for post processing as well
v3: fix post processing once more
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Mark Thompson <[email protected]>
|
|
|
|
|
|
|
| |
This makes debugging of decoding problems quite a bit easier.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Mark Thompson <[email protected]>
|
|
|
|
|
|
|
| |
No need to have that twice.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Mark Thompson <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Just use whatever the state tracker allocated.
v2: fix msb mode
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Mark Thompson <[email protected]>
|
|
|
|
|
|
|
|
| |
The firmware expects the value in pixel not bytes. Didn't made a difference
so far because we only used 8bpp surfaces.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Mark Thompson <[email protected]>
|
|
|
|
|
|
|
| |
Just simply the description of the planes.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Mark Thompson <[email protected]>
|
|
|
|
|
|
|
| |
Same layout as NV12, but 16bit per channel instead of 8.
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Mark Thompson <[email protected]>
|
|
|
|
|
|
|
| |
They do the same thing we just moved the function to be
accessible to all of Mesa.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
They do the same thing we just moved the function to be
accessible to all of Mesa.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
They do the same thing we just moved the function to be
accessible to all of Mesa.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
This will allow us to use it outside of gallium for things like
compressing shader cache entries.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
This will help us moving the file to the shared src/util dir.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
This will help us move u_queue.c here eventually and also provide
string function wrappers for anyone wishing to port disk_cache.c
to windows.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
| |
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
Looks like they have been unused since 2008 b8a7eef242f6bb97d90f.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
| |
This is not used anywhere and Visual Studio looks to have
supported memmove() for a long time if not always.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
| |
These are python2 scripts and the generic "python" may point to
python3.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
| |
It is not guaranteed to be in /bin
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Andreas Boll <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Just like the the dozens of other shaders, the file is parsed by
separate tool and not executed.
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
| |
Analogous to earlier commit(s).
Signed-off-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|