There's no need to re-check the DRI-config setting here; we either
already got nearest filtering already, or the we applied a work-around
to avoid incomplete textures. In either case, these should be nearest,
no need to check for it again.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18292>
mesa/gallium and util_format have different handling of alpha channels:
* mesa/gallium always uses w for the alpha swizzle
* util_format uses the actual component
for drivers which need to use the latter handling, this quirk will use the right
border color
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17687>
this is for drivers (like freedreno) which need the format in the sampler
state in order to accurately handle border colors
when set, drivers MAY receive a format in the sampler state if the frontend
supports it (e.g., nine does not), and the cso sampler cache will include
the format member of the struct
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17189>
When the stencil aspect of a depth+stencil texture is sampled, it's
actually integer. Also fixup st_translate_color() that assumed it was
float. This fixes the border color on zink+turnip.
v2: Add "|| texBaseFormat == GL_STENCIL_INDEX" to catch the case where
S8 is emulated as D24S8.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
Apparently the quantization math isn't cheap.
This further reduces overhead by 2% for drawoverhead/8 textures.
The improvement is measured by looking at the sysprof percentage delta and
multiplying by 2 (because we have the frontend and gallium threads with
equal overhead, so the benefit is doubled compared to 1 thread).
Both per-sampler and per-unit lod bias values are quantized.
The difference in behavior is that both values are quantized separately
and then added up, instead of first added up and then quantized.
The worst case error is +- 1/256 in the reduced precision, i.e. off by one
in a fixed-point representation, which should be fine.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11339>
- pipe_sampler_state is added into gl_sampler_attrib.
- The border color field is redundant, so the non-gallium field is removed.
- Other GL fields are still tracked because of glGet.
- Some fields are not set by GL functions because they are always derived
from multiple states.
- The behavior in GL functions is the same as st_convert_sampler.
This reduces overhead by 2% for drawoverhead/8 textures, and more is going
to be done.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11339>
v2: Add all the Y21x tests to the A530 expected fail list. All of the
YUV image import tests fail on this platform, and nobody has been able
to investigate why.
v3: Update the comment describing the zeroed bits in Y212. Suggested by
Emma.
v4: Add all Y21x test to the rpi3 expected fail list.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9610>
when this is not set, this triggers shader and sampler state updates any time a sampler
starts or stops using GL_CLAMP, applying bitmasks needed to run nir_lower_tex
and setting CLAMP_TO_BORDER/CLAMP_TO_EDGE as necessary to mimic the behavior
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8756>
Move the fields that should be restored by glPopAttrib into the Attrib
structure, which is the only portion of texture objects that is restored
by glPopAttrib. Also moves fields that should not be restored by glPopAttrib
out of the Attrib structure.
This is based on the GL 4.6 Compatibility spec.
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8181>
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>
st/dri:
this adds a table (similar to the one in i965) which provides
mappings for turning various planar formats into multiple sampler views.
whereas only NV12 and IYUV were supported, now many more formats are
supported here:
* P0XX
* YUV4XX
* YVU4XX
* AYUV
* XYUV
* YUYV
* UYVY
the table is used directly to handle image creation, simplifying
a lot of code and resolving related TODO/FIXME items where workarounds were
previously in place to manage NV12 and IYUV formats exclusively
st/mesa:
the changes here relate to setting up samplers for the planar formats.
this requires:
* checking for driver support for all the sampler formats
* creating the samplers with the corresponding formats and swizzling
* running nir_lower_tex with the appropriate options to trigger the lowering
for each plane->sampler
fixeskwg/mesa#36
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
GL_STENCIL_INDEX uses GL_INTENSITY for the border color, which is nicer
to hardware that doesn't read the stencil border value from the X channel.
This fixes a bunch of dEQP tests on Vega & Raven.
Cc: 18.1 18.2 <mesa-stable@lists.freedesktop.org>
Some locking is unfortunately required, because well-formed GL programs
can have multiple threads racing to access the same texture, e.g.: two
threads/contexts rendering from the same texture, or one thread destroying
a context while the other is rendering from or modifying a texture.
Since even the simple mutex caused noticable slowdowns in the piglit
drawoverhead micro-benchmark, this patch uses a slightly more involved
approach to keep locks out of the fast path:
- the initial lookup of sampler views happens without taking a lock
- a per-texture lock is only taken when we have to modify the sampler
view(s)
- since each thread mostly operates only on the entry corresponding to
its context, the main issue is re-allocation of the sampler view array
when it needs to be grown, but the old copy is not freed
Old copies of the sampler views array are kept around in a linked list
until the entire texture object is deleted. The total memory wasted
in this way is roughly equal to the size of the current sampler views
array.
Fixes non-deterministic memory corruption in some
dEQP-EGL.functional.sharing.gles2.multithread.* tests, e.g.
dEQP-EGL.functional.sharing.gles2.multithread.simple.images.texture_source.create_texture_render
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This fixes sequences like:
1. Context 1 samples from texture with sRGB decode enabled
2. Context 2 samples from texture with sRGB decode disabled
3. Context 1 samples from texture with sRGB decode disabled
Previously, step 3 would see the prev_sRGBDecode value from context 2
and would incorrectly use the old sampler view with sRGB decode enabled.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
