-Dcairo-tests=false currently results into enabling cairo support if it
was found. Same for valgrind.
v2:
* Use underscore-prefixed variables to not change type of variable
* Use empty array for "fake" dependency instead of real empty object
v3:
* Fix typo
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
The existing format modifier definitions were merged prematurely, and
recent work has unveiled that the definitions are suboptimal in several
ways:
- The format specifiers, except for one, are not Tegra specific, but
the names don't reflect that.
- The number space is split into two, reserving 32 bits for some
"parameter" which most of the modifiers are not going to have.
- Symbolic names for the modifiers are not using the standard
DRM_FORMAT_MOD_* prefix, which makes them awkward to use.
- The vendor prefix NV is somewhat ambiguous.
Fortunately, nobody's started using these modifiers, so we can still fix
the above issues. Do so by using the standard prefix. Also, remove TEGRA
from the name of those modifiers that exist on NVIDIA GPUs as well. In
case of the block linear modifiers, make the "parameter" smaller (4
bits, though only 6 values are valid) and don't let that leak into any
of the other modifiers.
Finally, also use the more canonical NVIDIA instead of the ambiguous NV
prefix.
This is based on commit 5843f4e02fbe86a59981e35adc6cabebee46fdc0 from
Linux v4.16-rc1 and also updates modetest to use the new defines.
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Avoid compiler warnings when the val parameter is an expression.
This is based on commit 5843f4e02fbe86a59981e35adc6cabebee46fdc0 from
Linux v4.16-rc1.
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
In order to lessen future alignment issues, lets switch to
fixed width integers where possible.
This excludes the data_owner since it is a pid_t which
in theory could be larger than 32 bits.
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
The name member of gralloc_handle_t is no longer needed and has been removed.
The version field has also been bumped.
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
The version variable will be used for versioning of this
struct and the corresponding accessor functions.
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
This struct is used in mesa and drm_hwcomposer.
Versions of if have been implemented in several grallocs:
drm_gralloc, gbm_gralloc, minigbm and intel-minigbm.
Other than the 1:1 move of the struct a new generic name
has been chosen and variables have had comments added to them.
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
for(( i=1; i < 100; i++))
do
echo "Hello, Welcome $i times "
sudo ./amdgpu_test -s 1 -t 5
done
with above stricpt, run in two terminals, will reproduce Felix's swap leeking issue.
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
issue: UMD allocates top 4GB, but don't do anything, just reserve top 4GB space,
but the performance of VP13 drops from 162fps to 99fps.
root cause:
our va hole list of vamgr is too long by time going.
fix:
reusing old hole as much as possible can make the list shortest.
result:
performance recovers as non-list path, next patch will remove non-list code path.
Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Otherwise we get an EFAULT, at least on a 64-bit kernel.
Fixes: 2048a9e7 "drm: add drmSyncobjWait wrapper"
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Otherwise we'll end up without the macros set during configure stage.
And effectively error out in sanity tests such as the mmap static
assert.
To reproduce, do a multilib build - 32bit build on 64bit machine.
Cc: Fabio Pedretti <pedretti.fabio@gmail.com>
Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Fixes: 33dcc29f7c ("amdgpu: Add VMID reservation per GPU context test.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104819
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
While at it, align with the other half on the next line.
Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
In case of a kernel that is new enough to support multiple submit-
queues, but with an adreno generation which doesn't support multiple
prioritized ringbuffers, we'd attempt to open a submit-queue with
prio=1 (medium), which is rejected by the kernel.
This could happen either w/ an older mesa (which uses fd_pipe_new())
or a newer mesa which defaults to prio=1 if no pipe context priority
flags are set.
The simple answer to fix both cases is to clamp the requested priority
according to the number of rings. This might not do exactly what you
want, if we hypothetically had 2 rings (it would result in requested
medium priority being high priority instead of low priority). But the
number of rings (for hw gen's that support this) is purely a software
construct, so the easy answer there is to have the kernel advertise at
least 3 rings if it supports more than one. There isn't really any
reason to do otherwise.
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Igor Gnatenko
Andrey Grodzovsky
Thierry Reding
Marek Olšák
Robert Foss
Michel Dänzer
Dylan Baker
Chunming Zhou
Bas Nieuwenhuizen
Emil Velikov
Eric Engestrom
Rob Clark