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>
Previously we'd burn 4 minutes waiting for curl to bang its head
trying to get results which would never emerge. Change this so we don't
fail on a 404, and also pull the retry down quicker, so we'll spend a
maximum of 2 minutes waiting for a server to come back, and no minutes
when the results aren't there to be fetched.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34244>
The new s3-proxy we have on fd.o is just a redirecting agent: it queries
the policy and, if allowed, returns a URL with temporary credentials
where the client can pull the real data from.
This means that nginx would see /fdo-opa/mesa-rootfs/misc?key=foo and
/fdo-opa/mesa-rootfs/misc?key=bar as distinct objects, not knowing that
it could cache only on the base URL.
Strip the query params from the nginx cache key so we can actually do
caching.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34244>
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>
In 35df3925ca ("brw: ensure VUE header writes in HS/DS/GS stages") I
misread the PRMs and thought that the VF would initialize the header.
What actually happens is that the VF does not write valid values in
there and the PRMs explicitly say that the VS shader should overwrite
whatever is in there.
We could avoid writing the header in some cases when no HW is going to
read back the header. For example with rendering disables through
3DSTATE_STREAMOUT::RenderingDisable. But those cases are dynamic and
the compiler is not able to tell. So just always write the header.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 35df3925ca ("brw: ensure VUE header writes in HS/DS/GS stages")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12880
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34211>
I didn't find dedicated 24bit intrinsics, but I also haven't looked that hard.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33871>
There are named and generic noop callbacks. The named ones can print
the GL function being called, while the generic ones can't. Remove
the generic ones.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34002>
