A lot of code zero-initializes pipe_sampler_state, and sets the states
the non-zero fields manually. This means that normalized_coords is the
"default" setting.
However, setting normalized_coords to true isn't allways allowed, and
we'd need to check PIPE_CAP_TEXRECT first. So it's not really the ideal
default here. There's recently been found quite a bit of bugs in this
area, where the state-tracker didn't properly lower texrects.
Let's switch this around to avoid more bugs like this in the future.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18971>
- use avc seq parameters
- clean up pipe_264_enc_picture_desc structure
- clean up get_param function
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18877>
reads flags field from CurrPic struct in pps for VA_PICTURE_H264_LONG_TERM_REFERENCE. If found, Curr_pic.frame_idx wil be used for the long term reference index
In get_picture_storage, check if current frame is ltr, and whether its ref frame is ltr.
In radeon_enc_slice_header, adds the ref_pic_list_modification_flag_l0 and long_term_reference_flag for ltr
v2: fix code formatting issues
Reviewed-by: Ruijing Dong ruijing.dong@amd.com
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18219>
HRD parameters and filler data enable and skip frame
enable data are needed even though some application
doesn't use them.
Also for per picture rate control, max_qp and min_qp
are added.
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Reviewed-By: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18534>
why:
max au size and per picture rate control data structure
need to follow the input
how:
have max_frame_size as the input to rate control
also re-calculate other rate control related params
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18534>
why:
getEncParamPreset functions overwrite the incoming
messages.
how:
To change a location after the decoder is created,
so that if no incoming message the default ones
will be used otherwise the new messages will
overwrite the default values.
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18534>
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>
