Instead of creating a new context when a reset is encountered, we now
track whether the reset was reported back to the application. According
to the spec, the application should poll the reset status and recreate
the context when NO_ERROR encountered after a RESET.
From the EXT_robustness spec:
5. How should the application react to a reset context event?
RESOLVED: For this extension, the application is expected to query
the reset status until NO_ERROR is returned. If a reset is encountered,
at least one *RESET* status will be returned. Once NO_ERROR is again
encountered, the application can safely destroy the old context and
create a new one.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24224>
Truncate UV coordinates to fix incorrect chroma offset.
Adjust texture offsets to match this change:
0.5 on X
0.25 on Y (interlaced)
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24301>
The app might not have emitted any cs words before freeing
resources so it is valid for the csb relocation mark to be
uninitialised on `pvr_csb_finish()`.
Fixes the assert being hit for:
dEQP-VK.api.pipeline.pipeline_layout.lifetime.graphics
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24329>
The spec. guarantees the framebuffer width and height to be `> 0`
but the same is not true for the render area.
Previously a render area of `0` size would wrap around due to the
`- 1` so we now check for `0`.
Fixes:
pvr_packet_helpers.h:79: __pvr_uint: Assertion `v <= max' failed.
on
dEQP-VK.api.pipeline.renderpass.framebuffer_compatible_renderpass
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24329>
The number of geometry shader invocations is correctly counted by the
hardware for both NGG and the legacy GS path but it increments for
NGG VS/TES because they are merged with GS, but it shouldn't. Fix this
by emulating the number of geometry shader invocations.
This fixes piglit/bin/arb_query_buffer_object-qbo and recent
dEQP-VK.query_pool.statistics_query.gs_invocations_no_gs.* failures
with NGG.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24231>
NGG is enabled by default on RDNA1-2 but the driver might fallback to
legacy GS for some reasons, like XFB. On these generations, the number
of generated primitives by GS needs to be emulated from the NGG shader
because the hw doesn't increment the related pipelinestat counter.
In order to support NGG and legacy GS with that query (remember that
we can't know pipelines when starting/ending queries), we used to
reserve 2x 64-bit counters to store the GDS results, and the results
were accumulated.
Now that legacy GS also uses GDS counters, we can simplify this path
and overwrite the pipelinestat counter directly instead of having two
separate counters.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24231>
This will allow us to fix a bug with the number of geometry shader
invocations which increase for NGG VS or TES but shouldn't. And also
for simplifying the NGG vs legacy query path.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24231>
This user SGPR is only declared on chips that support NGG but might
fallback to legacy GS for some reasons, like XFB. It will be used to
emulate GS counters from shaders.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24231>
GLVND *really* kinda belongs in *both* GLX and EGL, but it feels silly
to repeat the same setting. So let's just report it under the GL
section, as that's generic enough to apply to both of other sections.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24317>
We have to lower images into image load + sampler residency.
There is also a restriction on sampler access with a compare, lower
those as 2 sampler instructions to meet the restriction.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23882>
The last component of sparse load is the residency data. We don't want
to touch/convert that value with the format lowering.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23882>
Purely from the backend point of view it's just an additional
parameter to sampler messages.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23882>
In case the case of kmsro and freedreno driver, freedreno will fail to
with the xmlconfig errors as the kmsro declaration doesn't have defaults
for the freedreno options. Instead of directly using v3d_driconf for
kmsro, add native kmsro_driconf, which optionally includes v3d and
freedreno options.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24218>
The kmsro (in theory) can be using any other driver. In order to
simplify handling of driver public headers, move kmsro definition to the
bottom of the drm_helper.h
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24218>
In 9ffd00bcf1 ("nir_to_tgsi: Pack our tex coords into vec4
nir_tex_src_backend[12]"), Emma added a pair of back-end sources to
nir_tex_instr to allow complex lowering to be done in NIR. This adds a
tiny bit more hw-specific back-end information that a NIR lowering pass
can communicate to the back-end compiler.
While the opcode contains most of the information needed, some thing
such as the presence of offsets is currently only communicated via the
presence of specific source types in the source list. This information
is gone when the texture instruction is lowered to back-end sources.
Adding a backend_flags field fixes this by allowing the lowering pass to
communicate a small amount of side-band information if needed.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22303>
Currently we don't properly support using he two IDX registers in the
same ALU CF, so work around this by enforcing a new CF if both indices
are used.
Fixes: d21054b4bc
r600/sfn: Add pass to split addess and index register loads
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24297>
Our implementation only preserves the provoking vertex if it is last,
and always preserving it would be more draw-time validation because the
vertex ordering is tied up with the tessellation domain origin. It turns
out we didn't notice this because the tests aren't good enough to catch
the issue.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24304>
