I'm going to encapsulate all of the logic dealing with register types in
this file.
Rename the parameters for the hardware encodings from type -> hw_type at
the same time.
Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>
After the last patch converted things into enums, I helpfully got a
compiler warning about these missing from the switch statement.
Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>
The hardware encodings often mean different things depending on whether
the source is an immediate.
Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>
These vaguely corresponded to the hardware encodings, but that is purely
historical at this point. Reorder them so we stop making things "almost
work" when mixing enums.
The ordering has been closen so that no enum value is the same as a
compatible hardware encoding.
Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>
UB and B type encodings are the same as UV and VF. Noticed when writing
the following patch.
Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>
The destination stride must be equivalent to a dword if VF is used.
Also, since the only compaction table entires with "i:vf" have the
destination as "r:f" specifically check that the destination is of type
float.
Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>
Note that there's no point in testing on G45, since its compaction is
the same as Gen5. Same logic applies to Gen7 variants and low-power
parts.
Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>
Both statically linking libLLVMCore and dynamically linking libLLVM causes
duplicated symbols in gallium_dri.so and it fails to dlopen. We don't
really need to link libLLVMCore, but just need generated headers to be
built first. Dynamically linking to libLLVM instead is enough to do
that. Thanks to Qiang Yu for finding the root cause.
With this change, we can align all versions and just have libLLVM as a
shared lib dependency.
This also requires changes in the M and N versions of LLVM to export the
include paths for libLLVM. AOSP master is okay.
Fixes: 26aee6f4d5 ("Android: rework LLVM build support")
Reported-by: Mauro Rossi <issor.oruam@gmail.com>
Cc: 17.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Signed-off-by: Rob Herring <robh@kernel.org>
To find if the format is supported YUYV by sampling factor which
is embedded from bitstream. So we could use this info for buffer
reallocation on the correct format.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
So we have to detect it for reallocation of de-interlaced buffers
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
The current tier 1 mjpeg firmware only supports at the bitstream
level, the later tier 2 support will be at the buffers level with
newer hardware.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
There is no need of dpb buffer for mjpeg codec
v2: check dpb_size instead of format
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
"Alloc for render" is a terrible name for a flag because it means
basically nothing. What the flag really does is allocate a busy BO
which someone theorized at one point in time would be more efficient if
you're planning to immediately render to it. If the flag really means
"alloc a busy BO" we should just call it that.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
In 76e2f390f9, when Topi switched num_samples from 0 to 1 for
single-sampled, he accidentally switched the last parameter in the call
to miptree_create_for_teximage from 0 to 1 thinking it was num_samples
when it was actually layout_flags. Switching from 0 to 1 added the
MIPTREE_LAYOUT_ACCELERATED_UPLOAD flag which causes us to allocate a
busy BO instead of an idle one. This caused the subsequent CPU upload
to consistently stall. The end result was a 15% performance drop in the
SynMark v7 DrvRes microbenchmark. This restores the old behavior and
fixes the performance regression.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Fixes: 76e2f390f9
Bugzilla: https://bugs.freedesktop.org/102260
Cc: mesa-stable@lists.freedesktop.org
