With this issue 'mpv --hwdec=vdpau --vo=vdpau <stream>' fails
for vdpau decode if the stream height is 4096. Vdpau decode of
height upto 4096 is necessary usecase on amdgpu driver for VI
and newer platforms.
The fix is in driver specific implementation of "Decoder
Query Capabilities" API to return 4096 for VI and newer
platforms. With this fix vdpauinfo reports height support as
4096 and mpv for vdpau decode works fine for 4096 height streams.
Signed-off-by: Tamil velan <Tamil-Velan.Jayakumar@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 353a4f844f)
The hardware simply doesn't support that correctly.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit e148a3b6e9)
This fixes some use-after-free situations in dEQP when an xfb state is
removed, and then a clear is triggered, which only does a partial
validation. It would attempt to read the no-longer-valid buffers,
resulting in crashes.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit ff085d014e)
[Emil Velikov: macro names do not need 3D_ ]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Conflicts:
src/gallium/drivers/nouveau/nvc0/nvc0_shader_state.c
src/gallium/drivers/nouveau/nvc0/nvc0_state.c
If running with a software renderer backend, the timeout may be
insufficient, and we don't want to release busy buffers too early.
In practice, SVGA gpu lockups are extremely rare.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 395c7b8fa1)
Reported-by: Brian Paul <brianp@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviwed-by: Brian Paul <brianp@vmware.com>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 24ad7e16cd)
There is an old if statement (dated to 2011) that prevented doing
endian swap for colorformat, in case the buffer is marked as
PIPE_USAGE_STAGING.
This is now wrong because st_ReadPixels() reads into a destination
texture that is marked with PIPE_USAGE_STAGING. Therefore, even if
the texture is rendered correctly to the monitor, when reading it
back we get unswapped/wrong values.
This patch makes the check_rgba() function in gl-1.0-readpixsanity
piglit test pass in big-endian.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 914d4967d7)
There is an old if statement (dated to 2011) that prevented doing
endian swap for colorformat, in case the buffer is marked
as PIPE_USAGE_STAGING.
This is now wrong because st_ReadPixels() reads into a destination
texture that is marked with PIPE_USAGE_STAGING. Therefore, even if
the texture is rendered correctly to the monitor, when reading it
back we get unswapped/wrong values.
This patch makes the check_rgba() function in gl-1.0-readpixsanity
piglit test pass in big-endian.
v2: removed duplicate call to r600_colorformat_endian_swap() inside
evergreen_init_color_surface_rat()
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit ef5183faea)
Otherwise the build will fail, when the library is in a non default
location.
v2 [Emil Velikov]
- drop the unneeded cflags from targets/opencl.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Fixes: 7f585a6a98 "configure.ac: use pkg-config for libelf"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93524
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 04bc09fdf9)
In builds with clang, there are several errors related to the enum
alu_op_flags like this:
src/gallium/drivers/r600/sb/sb_expr.cpp:887:8:
error: case value evaluates to -1610612736, which cannot be narrowed to
type 'unsigned int' [-Wc++11-narrowing]
These are due to the MSB being set in the enum. Fix these errors by
making the enum values unsigned as needed. The flags field that stores
this enum also needs to be unsigned.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Cc: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 51b22bd468)
Fix compiles with clang that have this C++11 error:
src/gallium/drivers/radeon/r600_pipe_common.h:662:34:
error: invalid suffix on literal; C++11 requires a space between literal
and identifier [-Wreserved-user-defined-literal]
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Cc: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
(cherry picked from commit 92dd38df5a)
Enabling this warning doesn't generate any warnings with gcc, but is an
unknown option for clang, so drop it.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Rob Clark <robdclark@gmail.com> (v1)
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
v2: keep the warning around, commented out
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 0156a33aa3)
MESA_DRI_MODULE_PATH is only getting set for classic DRI drivers and may or
may not be set correctly for gallium_dri.so depending on the makefile
include ordering. For Android 6 and earlier it is fine, but with build
system changes in AOSP master, it is not.
Move the path variables to a single place at the top level and introduce
MESA_DRI_MODULE_REL_PATH for Android 5 and later which require relative
paths. With this, there is a single variable to change.
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 8949edf018)
[Emil Velikov: resolve trivial conflicts]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Conflicts:
src/egl/Android.mk
This function is currently broken for BE. I assume it's because of
util_pack_color(). Until I fix this path, I prefer to disable it so users
would be able to see correct colors on their desktop and applications.
Together with the two following patches:
- gallium/r600: Don't let h/w do endian swap for colorformat
- gallium/radeon: remove separate BE path in r600_translate_colorswap
it fixes BZ#72877 and BZ#92039
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit a640ad15e1)
Since the rework on gallium pipe formats, there is no more need to do
endian swap of the colorformat in the h/w, because the conversion between
mesa format and gallium (pipe) format takes endianess into account (see
the big #if in p_format.h).
v2: return ENDIAN_NONE only for four 8-bits components
(V_0280A0_COLOR_8_8_8_8)
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit e3dfc0e095)
After further testing, it appears there is no need for
separate BE path in r600_translate_colorswap()
The only fix remaining is the change of the last if statement, in the 4
channels case. Originally, it contained an invalid swizzle configuration
that never got hit, in LE or BE. So the fix is relevant for both systems.
This patch adds an additional 120 available visuals for LE and BE,
as seen in glxinfo
v2:
Tested for regressions by running piglit gpu.py with CAICOS (r600g) on
x86-64 machine. No regressions found.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 9559071ed6)
It appears that it actually needs to be aligned to the datum size, so it
was 1 when testing with R8, but it can be as high as 16 with RGBA32.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit aa3b85fd18)
[Emil Velikov: squash trivial conflicts]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Conflicts:
src/gallium/drivers/nouveau/nv50/nv50_screen.c
Because I changed the swizzle check, I also need to adapt the return
values for each check.
It's basically almost the same as before, we just cross between STD and
STD_REV, and cross between ALT and ALT_REV
This fixes the rgba test in gl-1.0-readpixsanity (piglit) and also
fixes tri-flat (mesa demos).
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 439b5b008f)
This patch fixes a bug when building a pack instruction.
For POWER (altivec), in case the destination is signed and the
src width is 32, we need to use vpkswss. The original code used vpkuwus,
which emits an unsigned result.
This fixes the following piglit tests on ppc64le:
- spec@arb_color_buffer_float@gl_rgba8-drawpixels
- shaders@glsl-fs-fogscale
I've also corrected some coding style issues in the function.
v2: Returned else statements to vmware style
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
(cherry picked from commit 679a654a77)
The current code in r600_translate_colorswap uses the swizzle information
to determine which colorswap to use.
This works for BE & LE when the nr_channels is <4, but when nr_channels==4
(e.g. PIPE_FORMAT_A8R8G8B8_UNORM), this method can not be used for both BE
and LE, because the swizzle info is the same for both of them.
As a result, r600g doesn't support 24bit color formats, only 16bit, which
forces the user to choose 16bit color in X server.
This patch fixes this bug by separating the checks for LE and BE and
adapting the swizzle conditions in the BE part of the checks.
Tested on an Evergreen GPU (Cedar GL FirePro 2270) running inside POWER7
Big-Endian Machine.
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
CC: "11.2" "11.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 4b7e219e61)
When there's a predicate, it just goes onto the sources list. If the
quadop only has a single regular source, we will end up thinking that
the predicate is the second source. Check explicitly for the predSrc so
that we don't accidentally emit the wrong thing.
This fixes a bunch of dEQP-GLES3.functional.shaders.derivate.* tests.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit ca23c8081f)
Fixup to commit 03b3eb90d - the number of buffers could be larger than
the number of elements, in which case we'd pass a negative argument to
PUSH_SPACE, which would be bad. While we're at it, merge it with the
other PUSH_SPACE at the top of the function.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 2065e380b2)
nvc0_vbo has explicit push space checking enabled, so we must run
PUSH_SPACE by hand. A few spots missed that.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 03b3eb90d7)
[Emil Velikov: resolve trivial conflicts]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Conflicts:
src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
The spill logic will insert convert ops when moving between files. It
seems like the emission logic wasn't quite ready for these converts.
Tested on fermi, and visually looked at nvdisasm output for maxwell.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 1a0fde1f52)
When a fragment shader is used that has no outputs but does conditional
discard (KILL_IF), all fragments are killed without this patch.
By comparing various register settings, my conclusion is that the exec mask
is either not properly forwarded to the DB by NULL exports or ends up being
unused, at least when there is _only_ a NULL export (the ISA documentation
claims that NULL exports can be used to override a previously exported exec
mask).
Of the various approaches I have tried to work around the problem, this one
seems to be the least invasive one.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93761
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The scaling list should be filled out with zig zag scan
v2: integrate zig zag scan for list 4x4 to vl(Christian)
v3: move list determination out from the loop(Ilia)
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
(cherry picked from commit 6ad2e55a14)
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
(cherry picked from commit 4f598f2173)
If an instruction has multiple defs, we have to do a lot more checks to
make sure that we can move it forward. Among other things, various code
likes to do
a, b = tex()
if () c = a
else c = b
which means that a single phi node will have results pointing at the
same instruction. We obviously can't propagate the tex in this case, but
properly accounting for this situation is tricky. Just don't try for
instructions with multiple defs.
This fixes about 20 shaders in shader-db, including the dolphin efb2ram
shader.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 3ca941d60e)
It appears that the nvidia render engine is quite picky when it comes to
linear surfaces. It doesn't like non-256-byte aligned offsets, and
apparently doesn't even do non-256-byte strides.
This makes arb_clear_buffer_object-unaligned pass on both nv50 and nvc0.
As a side-effect this also allows RGB32 clears to work via GPU data
upload instead of synchronizing the buffer to the CPU (nvc0 only).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> # tested on GF108, GT215
Tested-by: Nick Sarnie <commendsarnex@gmail.com> # GK208
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 3ca2001b53)
When using the "shared" vertex array configuration strategy, we bind
each of the buffers as a separate array. However there can be holes in
such vertex buffer lists, so just emit a disable for those.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 438d421f8b)
Just make sure that after we've submitted, we get to at least 5
(global) submits ago before we go on to do more. Prevents up to
seconds of lag with window movement in X with xcompmgr -c. There may
be useful tuning to do in the future, but for now this gets us
usability.
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 3fba517bdd)
On an error return, the returned seqno will probably be unset, so we'd
lose track of what we've submitted so far for waiting on in the
future.
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit 2a449ce7c9)
When RA fails, and we spill, we have to clean everything up before doing
RA again. We were forgetting to reset the hi/lo linked lists - at
least the hi list is guaranteed to still have pointers to now-deleted
RIG nodes.
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 19ae5de981)
This fixes a VM fault and possible lockup in high memory pressure situations.
Cc: "11.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
(cherry picked from commit 1067e6eb55)
Specifically, when the API switches from using a GS to not using a GS and then
back to using the same GS again, we do not have to re-send all the GS state,
but we do have to send VGT_GS_MODE. So make VGT_GS_MODE consistently be a part
of the VS state.
This fixes a rendering bug in Dolphin, but surely other applications are
affected as well.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93648
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 004fcd4230)
By using whole static libraries the android buildsystem provides
whole-archive (alike) solution. This means that we don't need to worry
about the order of the static libraries and any reverse, recursive or
circular dependencies that they have between one another.
Without this the linker will discard any unused hunks of one library
and we'll end up with unresolved symbols as those are required by
another static library. This issue has become more prominent with the
introduction of pipe-loader.
Whole static libraries has been used in i915/i965 for a very long
time, so we might do the same.
v2:
- Better commit message (Ilia)
- Keep external dependencies as [normal] static libs (Mauro)
Cc: mesa-stable@lists.freedesktop.org
Cc: Mauro Rossi <issor.oruam@gmail.com>
Reported-by: Mauro Rossi <issor.oruam@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit f29a772a7e)
The buffers are referenced from r600_update_driver_const_buffers()
-> r600_set_constant_buffer() -> u_upload_data(), but nothing
ever releases the reference. Similar case with driver_consts.
Found using valgrind.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
[Emil Velikov: resolve trivial conflicts]
(cherry picked from commit 0153ff8379)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Apparently, nobody has combined stippling with a fragment shader
containing immediates in almost five years...
Fixes a bug in Kodi with radeonsi reported by Christian König.
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
Tested-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit e6281a2850)
I'm not sure about the consequences of this bug, but it's definitely
dangerous.
This applies to SI, CIK, VI.
Cc: 11.0 11.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
(cherry picked from commit dc96a18d24)
Experimentally, 4M causes corruption and slowness, try to ramp it up
with size instead.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit b16c9be4a5)
H264 doesn't have a bitplane bo. We just need a device reference, so use
the one from the client.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit b5f2f7073f)
First off, we can't flush in the middle of a command. Secondly
requesting the extra push space might cause a flush to happen. If that
flush happens, we'd have to do the PUSH_REFN again. So instead do
PUSH_REFN after the push space request. This helps avoid rare crashes
with supertuxkart in libdrm due to assertion failures.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit c1d14c6817)
[Emil Velikov: resolve trivial conflict]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Conflicts:
src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c
Quads need to respect winding order, too - not just triangles.
Fixes rendering in GFXBench 4.0's tessellation benchmark.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 65d3f85eb3)
Make sure to make conversion unsigned when we're ANDing the high bits
away. Fixes corruption in dolphin.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 724134f683)
