Commit f9a074dd55 ("dri2/android: Bypass throttling") dropped
unnecessary throtting in the SwapBuffers() path for android. But
unfortunately MSAA resolve got tangled up in the throttle reason
flag. So add a new flag that indicates "no throttingling, but yes
please do MSAA resolve".
Fixes: f9a074dd55 ("dri2/android: Bypass throttling")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22719>
by having va av1 caps enabled, av1 vaapi encoding
is enabled.
Reviewed-by: Sil Vilerino <sivileri@microsoft.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22585>
We had a lot of implicit locks going on even though there was strictly no
need in doing so. This makes the compilation APIs more atomic while also
providing a cleaner interface.
Not in the mood of splitting it up without deadlocking in the middle. So
it's one big commit sadly.
Signed-off-by: Karol Herbst <git@karolherbst.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22434>
It's not a lazy loaded type so doing the Once::call_once in every
Platform::get gives us a pointless atomic, which might be slow on some
platforms.
Every application has to call clGetPlatformIDs so we only need to do it
there.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22649>
Enabling fp64 support makes rarely sense, but in case we do claim it, we
should also tell if it's a pure software implementation.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22649>
Move loop var decls into loops.
Use designated initializers.
Replace some questionable memcpy/memset() calls with assignments.
Line-wrap, whitespace fixes.
Signed-off-by: Brian Paul <brianp@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22467>
Simplify the code which puts query results into the destination
buffer:
* Use a uint64 or uint32 pointer instead of uint8 to write the results
to the buffer for less casting and simplifient pointer incrementing.
* Use MIN2() macro to be more concise.
And fix some indentation.
Signed-off-by: Brian Paul <brianp@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22467>
return the matching drm format for YUYV pipe format in pipe_format_to_drm_format(), else
vlVaExportSurfaceHandle() fails to export a surface handle for YUYV surface.
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22497>
When wfog support is advertised, unless an orthogonal
projection matrix is detected, w is supposed to be used
instead of z for the fog equation when done in the pixel
shader.
Due to the spec being ambiguous, and tests being incomplete,
it seems we had got things wrong.
New tests confirm the behaviour.
For the explanation we will denote z_vs and w_vs the position
output's z and w channels in the vertex shader, and
z_ps, w_ps the position input z and w channels in the pixel shader.
w_ps = 1/w_vs
z_ps = z_vs/w_vs
In the programmable pixel shader, we used z_ps/w_ps, thus z_vs.
As basically z_vs and w_vs are usually in the same range, we didn't
notice an obvious difference with the correct behaviour.
In the ff pixel shader, we used z_ps for zfog and w_vs else.
z_ps was always used if a programmable vertex shader was detected.
This latter behaviour led to issue
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8341
While using z_ps/w_ps like for programmable ps fixes the issue visually
for the same reason as it did for programmable ps, it breaks
wine tests using XYZRHW. These tests show that when passing
pre-transformed vertices and an orthogonal projection matrix,
z_vs is used, and due to the XYZRHW property, this is not
recovered by the z_ps/w_ps computation (instead z_ps=z_vs).
For the game affected by the issue, the projection matrix set
is not orthogonal.
The direct3D spec indicates that the projection matrix must be
set correctly for fog to work properly, even if we do not use the
transformation pipeline (could be related to xyzrhw, or programmable vs
or both). Previous tests had shown that the projection matrix
has the last two values of the last column tested against 0 and 1,
in order to activate zfog or wfog.
The R500 spec indicates that either z or 1/1/w can be used as source
for the fog computation, but it is not clear whether this is z_vs or
z_ps.
Tests confirmed the intuition that the correct behaviour
is to use z_ps (zfog) when an orthogonal projection matrix is set
(the spec spirit being that in that case z_ps=z_vs),
and 1/w_ps (wfog) else (even if programmable shaders are used).
This patch introduces this behaviour.
Fixes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8341
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22583>
FOGTABLEMODE is 2 bits. It could thus
overwrite the part of the ps key reserved
for centroid interpolation.
Fix the size of FOGTABLEMODE and the key
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22583>
This puts the CL -> pipe_box logic in one place and also make sure the
pipe_box is filled in correctly so we neither read out of bounds nor do
nothing at all.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22506>
This fixes some CTS compiler tests where they relied on the cl_kernel
object to be released in time so it can recompile a program without
throwing CL_INVALID_OPERATION due to still having active kernel objects.
Fixes: 47a80d7ff4 ("rusticl/event: proper eventing support")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22510>
check and enable RGBP rt_format and support VaImage creation for the RGBP/ARGB.
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22388>
At the moment it's an all or nothing. A driver supporting fine-grained
system SVM can enable it in order to get full SVM support.
Lower levels could be emulated by userptrs and placing the bo at the same
locations in the GPU's VM as well, but that would require reworking quite
a bit on the drivers side.
For now supporting mmu_notifiers on the kernel side is the only way of
getting SVM support with Rusticl.
The only driver having the gallium bits wired up atm is Nouveau, but I
suspect it shouldn't be all to hard for iris and radeonsi as well.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19712>
The old code was kinda bogus as we mapped at (0, 0, 0), but then didn't
take the origin into account when specifiying the size of the access.
Just offset properly instead.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22449>
For the CL spec it really matters how a program object was created. We
never really cared all that much, but it didn't support the corner case of
having an empty string as the OpenCL C source code.
Enums feel like the more Rust way to do this kind of stuff anyway.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22280>
The code wasn't all the same, but the build version was wrong, e.g. the
compile flags specified need to be stored even on error.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22280>
