KMD needs to be able to read and write the clear-color from CPU.
i915 can workaround it but Xe KMD will reject page flips with
clear-color bos that can be read from CPU.
So here it make sure that bos with the clear color information
are placed in a lmem portion that is CPU-visible, that is important in
PCIe small bar systems.
And as CCS in discrete GPUs are only supported in lmem this bo can't
become a IRIS_HEAP_DEVICE_LOCAL_PREFERRED(lmem + smem).
So here the IRIS_HEAP_DEVICE_LOCAL_CPU_VISIBLE_SMALL_BAR heap is selected.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26700>
Reference frame list is formed by each of the provided
recon_frame, while the assumption here is to use the API
provided by VAAPI interface, when a frame is marked as
"long term reference" by
av1->picture_flags.bits.long_term_reference
Its recon_frame will be kept in DPB marked by its
recon_frame as signature. When a future input requests
refering to it, it can go this way:
1. set av1->ref_frame_ctrl_l0.field.search_idx2 to indicate
which ref_frame_idx slot will be used.
x = av1->ref_frame_ctrl_l0.field.search_idx2;
2. n = av1->ref_frame_idx[x-1];
av1->reference_frames[n] as the signature to compare with.
if av1->reference_frames[n] is pointing to the
same video buffer (signature) as the one marked as
"long term reference". Then the new input is refering to
it only.
3. in SVC case, long terms are used for temproal_id 0 only,
because using long term means potentially scene change
could happen.
4. the "long term reference" recon_frame should be kept,
instead of being reused until it is no longer needed to
avoid signature duplication.
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/27771>
Add vcn4 av1 long term reference support.
So that frames can be controlled from application
side to refer to the identified reference, which
usually could provide better coding efficiency in
the case of scene chagne back and forth, just it
needs to identify and mark these frames before
using them.
We assume 2 long term reference frames should be
good in a key frame period, and these long term
references can be overwritten by marking new ones.
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/27771>
Here it borrowed the term "long term reference" to represent
the customized reference frame rather than the default ones used.
To enable that, it needs application to leverage VAAPI existing
interface to mark a frame as "long term reference", and then
it will be preserved in the DPB for later usage. This preserved
frame later could be refered to by having its signature used in
the ref_frame_idx[] list, and the index can be indicated by
RefFrameCtrl index2, which has not been used for other purpose.
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/27771>
We used to loop like this:
foreach (config_supported_by_driver) {
foreach (config_wl_knows_about) {
dri2_add_config(wl_config.rgba_masks, wl_config.rgba_shifts)) {
if (wl_config.rgba_masks != driver_config.rgba_masks ||
wl_config.rgba_shifts != driver_config.rgba_shifts) {
return NULL; /* driver config != wl config */
}
}
}
}
This is a pretty painful way to discover the relationship between the
different sets of configs, especially as we can just look up our Wayland
visual entry directly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
When we create a texture, we allocate a pipe_resource for it with a
given format. When we export the texture to an EGLImage, we go look
up what the GL format was and try to re-derive the pipe_format back
again.
Instead of doing that, just immediately reuse the pipe_format for the
image's format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
When we create a renderbuffer, we allocate a pipe_resource for it with a
given format. When we export the renderbuffer to an EGLImage, we go look
up what the GL format was and try to re-derive the pipe_format back
again.
Instead of doing that, just immediately reuse the pipe_format for the
image's format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
When the DRI frontend generates configs to pass to the APIs, store the
pipe_format in the internal gl_config structure. Doing this allows us to
nuke a few places where we try to retcon our way back from the config to
a pipe_format.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
Just get all the information we need from u_format, rather than keeping
it in hand-written tables.
If you have bisected any kind of failure to this commit, please build
the previous commit in debug mode (so that assertions are enabled) and
check if there are any runtime failures. If so, there is a difference
between the u_format descriptions and the handwritten descriptions that
this commit deletes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
Similar to util_format_get_component_bits, get the bit offset for a
particular channel in a given format.
Use this to calculate the shift/mask sets for formats when creating DRI
configs, as a prelude to ripping out and replacing the hardcoded table.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27709>
