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>
GL functions were exported by luck because we incorrectly used
link_with in meson, which exports functions only if the static lib is
used. link_whole guarantees that the functions are always exported
even if the static lib is unused.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34002>
It's used by the symbols check test, so let's feed the same file into
python to define public GL functions because the lists are identical.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34002>
- include the generated header directly instead of including
MAPI_ABI_HEADER
- remove the MAPI_MODE_BRIDGE macro
- must move code into .c files since we don't have the macros anymore
- clean up #includes
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34002>
Using the same .c file in 4 different static/shared libs is difficult to
read. Having them separate will make it possible to simplify the code.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34002>
