this allows a frontend to punt creation of a nir shader down to the
driver's compilation thread, which is useful in the event that the
shader being created is so big that it will cause immediate blocking
from running common nir passes
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18198>
For those drivers that don't make full use of the 64 bits in
pipe_query_result.u64.
Applications will make use of it via GL_QUERY_COUNTER_BITS to handle
when the value rolls over.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
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/10770>
We have fine NIR lowering for this (already called from mesa/st), no need
for a separate GLSL pass.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18361>
Drivers that don't use compile queues can use a common implementation. Drivers
that do can tail call into the common implementation.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18351>
Every driver uses the nir_lower_system_values path now.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18327>
We need to move some earlier (so they are <= 255 like the comment says)
and add a few 64-bit ones.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17894>
vaDeriveImage should check if the underlying gallium driver can map contiguous planes
before skipping with disallowlist.
Fixes: a585d95803 ("radeonsi/vcn: WA 10bit encoding crash in vaapi")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18300>
[why]
to enhance va video encoding quality
[how]
use va encoding quality_level interface, and provide
default value and encoding quality adjustment options,
so that users can finetune encoding quality and performance
from va quality interface. (limited to VCNs)
There are 3 settings added:
- preset modes: speed, balance, quality
they are using different encoding strategies
- vbaq modes:
vbaq mode is using variance based strategy
to improve the subjective image quality
- pre-encoding modes:
Using scaled down input image for pre-encoding to have
better rate-control reaction and consume more memory
in the same time. Only preencoding-4x mode is enabled.
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Reviewed-by: Boyuan Zhang <boyuan.zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17994>
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>
Provide a use flag to let the driver know that the allocated buffer will
be used for frontbuffer rendering. For example, bandwidth compressed
formats should usually be avoided for frontbuffer rendering to avoid the
visual corruption that results from this display racing with the GPU
writing header data vs. pixel data.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17799>
These should be the enum not unsigned.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com> (panfrost)
Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com> (v3d)
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17747>
Line these up with Mesa, prepare for fallout.
zink: the one where Mike gets overfriendly with enum layouts.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17747>
This tells the drivers to expect depth values outside the 0..1 range.
This is used for support VK_EXT_depth_range_unrestricted, but could
also be used for GL_NV_depth_buffer_float in GL.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17612>
Add process_frame to pipe_video codec
Add new structures/caps for video post-processing with rotation,
flip, alpha blending, crop, and scaling, via the video engine.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17557>
Win32 memory objects can be imported by name (const void *
that will be interpreted as const wchar_t *)
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Marek Olák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17446>
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>
GL_MAP_UNSYNCHRONIZED_BIT depends on the app having its threading
handled correctly. This allows us to force disable the bit when
they get it wrong.
CC: 22.1 22.0 <mesa-stable>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17199>
The RADEON_GEM_USERPTR_ANONONLY flag is hardcoded here which excludes
shared memory pages. DRM is actually capable of supporting shared file-
backed memory, but only if it's read-only. This mutability intent has to
be conveyed through the stack, so a flags argument is added to the winsys
regime to pass RADEON_FLAG_READ_ONLY.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16115>
st/mesa will expose GL_ARM_shader_framebuffer_fetch_depth_stencil
if this new capability is supported by the driver.
Signed-off-by: Pavel Asyutchenko <sventeam@yandex.ru>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13979>
this is for drivers like zink that may or may not
handle dithering and so getting blend state changes
when this state changes isn't useful
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17043>
This patch plumbs the YUV color space and range provided through
EGL_EXT_image_dma_buf_import all the way to nir_lower_tex().
NIR already accounts for the YUV color space courtesy of commit
d8fdb8da. However, the color space was wired only for i965/i915 (see
6c11a799) and not for Gallium.
Tested-by: Andres Calderon Jaramillo <andrescj@chromium.org>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16651>
piglit select tests fail, so add a gallium cap to disable
for crocus explicitly.
crocus may choose to enable hardware select only for GPU
SKU which tested to be OK again.
Fixes: 6489af145c ("mesa: enable HardwareAcceleratedSelect")
Closes: #6644
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16955>
There's really just one case where this is supported; on GCC for x86.
All other cases do nothing, so let's remove the complexity that is no
longer needed.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16908>
There's no reason to have standard includes in two different sections of
the header, let's merge them. While we're at it, let's sort the includes
as well.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16908>
This skips the preamble for following IBs if the queue receives IBs from
the same context back-to-back. This eliminates VGT_FLUSH (for tess and
legacy GS) and PS_PARTIAL_FLUSH (for gfx11) in those cases if the preamble
contains them.
v2: only use this on gfx10+ due to stability issues on Stoney and limited
testing
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16885>
This is a clearer name for what it does than MUL_ZERO_WINS, and matches up
to the new name in shader_info.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16176>
When lower_wpos_pntc is used, the state tracker inserts code to
transform gl_PointCoord.y according to a uniform, to account for
API-requested point coordinate origin and framebuffer orientation. With
the transformation, driver-supplied point coordinates are expected to
have an upper left origin.
If the hardware point coordinate supports (only) a lower left origin,
the backend has to use lower_wpos_pntc and then lower *again* to flip
back. This ends up transforming twice, which is wasteful:
a = load point coord Y with lower left origin
a' = 1.0 - a
a'' = uniform_transform(a')
However, lower_wpos_pntc is quite capable of transforming for a lower
left origin too, it just needs to flip the transformation. Add a CAP
specifying the point coordinate origin convention, rather than assuming
upper-left. This simplifies the Asahi code greatly.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16829>
