Instead of having a hardcoded table to convert between sRGB formats and
their linear-gamma equivalents (and vice-versa), generate this from the
information in the format table.
This requires adding a 'sublayout' attribute to differentiate between,
e.g. DXT1 and DXT3, which otherwise appear to be equivalent but for
their name prefix.
As an anonymous union is being used, we also need named initialisers for
the util_format_description entries.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29649>
u_format has always had its format table in CSV. This is kind of nice
for some things, but is a serious pain to extend, especially with
optional fields.
In going through our many (many, many) duplicated tables of format
mappings, it would've been nice to add some descriptions to our central
u_format table, such as mapping to DRM FourCC, to EGLImage mappings, and
to GL internalformats for EGLImage imports. Unfortunately, doing so with
more additional fields would just make the CSV totally unreadable.
Move the CSV table to a YAML-based table and adjust the Python parsers
to suit. The resulting generated files are identical before and after
the transition.
The new parser also has a significant amount of format validation to
make it easier to catch common errors.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29649>
When NV21 lowering with hardware sampling and shader CSC was added, the
incorrect PIPE_FORMAT_G8_B8R8_UNORM was used. That format is supposed to
represent vulkan NV12 instead.
This commit introduces PIPE_FORMAT_R8_B8G8_UNORM, which correctly describes the
gallium mapping for YUV CSC, with R as Y, instead of G as Y.
Fixes: 26e3be513d ("gallium/st: add support for PIPE_FORMAT_NV21 and PIPE_FORMAT_G8_B8R8_420")
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24266>
This new format is similar to PIPE_FORMAT_G8_B8_R8_420, but with R as Y, G as U
and B as V. The need for two diferent formats here is because gallium maps the
YUV channels differently from vulkan.
Some hardware, e.g. Mali GPUs, can sample from I420 but need CSC in shader,
this patch implements that.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24266>
The script that generates the format tables does not set every pipe_format.
In practice, the length of the format tables is equal to PIPE_FORMAT_COUNT.
I just added the explicit size to future-proof it.
(If the largest valid format is not part of the format tables,
there will be a mismatch between the array length and PIPE_FORMAT_COUNT)
Signed-off-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17490>
turnip was playing fast and loose with the name, using the R8_G8B8 format
name but actually setting the descriptors up to read G8_B8R8 like Vulkan
(sensibly) wants. This caused trouble when trying to make freedreno and
turnip share code. By having both orderings as format names, we can share
the descriptor code and also confuse readers less.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13443>
In looking at the profile of dEQP, GLES3 was spending 5-10% of its time in
ReadPixels, and almost all of that is b8g8r8a8_unorm8. It's really slow
because we're getting about 47MB/s by doing uncached reads 32 bits at a
time in the code-generated unpack. If we use NEON to generate larger bus
transactions, we can speed things up to 136MB/s. In comparison, raw
ldr/str read/writes with no byte swapping can hit a max of 216MB/sec.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10014>
We have only a few callers of unpack that do rects, so add a helper that
iterates over y adding the strides. This saves us 36kb of generated code
and means that adding cpu-specific variants for RGBA format unpack will be
much simpler.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10014>
A single format either had the float, the sint, or the uint version.
Making the dst be void * lets us store them in the same slot and not have
logic in the callers to call the right one.
-6kb on gallium drivers
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6305>
Some of the generated functions can be useful without going through the
format table (filling border color struct in turnip). By not calling these
functions through the format table, we should eventually be able to garbage
collect the unused packing functions, and also allows LTOs to happen.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6093>
To make PIPE_FORMATs usable from non-gallium parts of Mesa, I want to
move their helpers out of gallium. Since u_format used
util_copy_rect(), I moved that in there, too.
I've put it in a separate directory in util/ because it's a big chunk
of related code, and it's not clear to me whether we might want it as
a separate library from libmesa_util at some point.
Closes: #1905
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Valentine Burley