CPS surfaces are marked as stencil compressed internally and
should use the fast clear depth stencil path for clearing when possible
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20741>
This particular scenario indicates that the CPB will be written to using
a fragment shader, disable compression to ensure the correct data is
read back from the surface later.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20741>
Compressed CPS surfaces operations such as copies and clears need to be
handled through the depth stencil hw to ensure that the aux data is
handled correctly.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20741>
Apparently hwconfig has not implemented this workaround.
This warning was noted on MTL and ADL.
> INTEL_HWCONFIG_TOTAL_GS_THREADS (336) != devinfo->max_gs_threads (312)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34243>
Previously we were printing this information whenever the driver
started, but that proved to noisy.
For example, if running thousands of tests, this would cause thousands
of warnings messages to be printed. (Assuming the driver was built in
debug mode.)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34243>
We will move this check into the `intel_dev_info` tool. Unfortunately,
this means we will be much less likely to notice inconsistencies, but
the current strategy has proven to be far too noisy.
For example, if the driver was built in debug mode, then when test
suites are running thousands of tests, the current approach can lead
to thousands of messages being printed.
Closes: mesa/mesa#12141
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34243>
Which is necessary for many common YCbCr formats.
Fixes: d74ea2c117 (llvmpipe: Implement dmabuf handling)
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34240>
RenderDoc has a hard-coded limit of 16B for descriptor captures and
we're currently burning 24B. Reducing is pretty easy, though, since
storage doesn't support multi-plane. Any storage image views will use
VK_IMAGE_ASPECT_PLANE_N_BIT.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34128>
We detect whenever a method hasn't changed from one generation to the
next and just `pub use` the older generation's method struct and any
enum types associated. This keeps each mthd module independently usable
with all necessary types while reducing the number of unique Rust types
and associated trait implementations generated. This drops the size of
libnvidia_headers.rlib from 84 MiB to 22 MiB and will hopefully make
Rust code a little less expensive to build.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34136>
This adds proper Method and Field classes and uses them instead of
the pile of dictionaries we had before. This is probably faster and
definitely more readable. I've verified with cl9097.h that this makes
no differenct to the generated C or Rust besides whitespace.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34136>
The low-end Turing cards (TU117 for sure) are SM73, not SM75. These are
the cards on which we have tensor cores but they're so slow as to be
almost useless. We're not back-porting this because nouveau currently
returns 75 for these cards and because Volta binaries work fine on
Turing so they'll just be a little slower. We have, however, seen this
advertised by NVRM so we want our handling of shader models to be
correct.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34201>
It's possible that the source is uniform but the destination is not. In
this case, we need to insert a copy or else we might accidentally
propagate a uniform into some place we don't expect it.
This fixes a bunch of fp64 KHR-Single-GL46.subgroups.arithmetic.* tests.
Fixes: d09d3f5246 ("nak/from_nir: Emit uniform instructions when !divergent")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34201>
Currently it is not possible to mmap() the exported dma-bufs from etnaviv
for writing, through the GBM APIs, such as gbm_bo_get_fd(). etna_bo_dmabuf()
calls drmPrimeHandleToFD() only with DRM_CLOEXEC flag, omitting DRM_RDWR.
A typical call sequence, ending in etna_bo_dmabuf, for illustration:
gbm_bo_get_fd -> gbm_dri_bo_get_fd -> dri2_query_image ->
dri2_query_image_by_resource_handle -> etna_resource_get_handle
-> etna_bo_dmabuf.
Signed-off-by: Nikolas Zimmermann <nzimmermann@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34213>
