Originally we only had a single bucket cache, and it was the main
allocation mechanism. Later on, we added one for device-local memory,
and then a third one for device-local-preferred. Each time, we just
copy and pasted the fields, keeping them all as direct members of the
bufmgr struct. This is getting a bit unwieldy.
This patch introduces an iris_bucket_cache structure to contain the
list of buckets and the number of buckets. It then replaces the three
inline copies with a bufmgr->bucket_cache[heap] array. This lets us
drop a bunch of copy and pasted code in favor of a loop over heaps.
This will also make it easier to add more heaps.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
Here renaming the PAT entries to a name that better express each
entry.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
Iris doesn't make any call to intel_flush_range*() functions so all BOs
created without BO_ALLOC_COHERENT are not coherent between CPU writes
and GPU reads.
A lot of places don't set BO_ALLOC_COHERENT not even command buffers
have it.
And this incoherency is causing most of tests to fail after
the patch that extracted("iris: Calculate iris_mmap_mode using
intel_device_info_pat_entry when possible") the mmap mode from the PAT
entry.
Before that patch MTL was creating BO with a WB PAT index but then
mmaping as WC.
So to fix this for now making the default PAT entry for Iris a WC one.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25447>
Turns out that besides the benefits from nir_move_vec_src_uses_to_dest
itself, it also creates new opportunities for vectorization. Enable it
for vertex shaders, there is a clear instruction win and the only
downside is some increased register presure. However this is mostly
concerning few Unigine Tropics and Sanctiary shaders where we go
11->14 or 10->13 used registers. According to the docs, the increased
register usage would only lower vertex processing concurency if we go
over 15 (R300) or 25 (R500) registers, so we should be safe here.
Fragment shaders are a mixed bag so leave them be for now.
Shader-db RV530
total instructions in shared programs: 129303 -> 128762 (-0.42%)
instructions in affected programs: 13887 -> 13346 (-3.90%)
helped: 99
HURT: 0
total temps in shared programs: 17355 -> 17543 (1.08%)
temps in affected programs: 730 -> 918 (25.75%)
helped: 4
HURT: 66
total cycles in shared programs: 197190 -> 196984 (-0.10%)
cycles in affected programs: 9998 -> 9792 (-2.06%)
helped: 65
HURT: 0
Shader-db RV370:
total instructions in shared programs: 84807 -> 84225 (-0.69%)
instructions in affected programs: 10203 -> 9621 (-5.70%)
helped: 92
HURT: 0
total temps in shared programs: 13036 -> 13231 (1.50%)
temps in affected programs: 787 -> 982 (24.78%)
helped: 4
HURT: 73
total cycles in shared programs: 133178 -> 132946 (-0.17%)
cycles in affected programs: 5911 -> 5679 (-3.92%)
helped: 58
HURT: 0
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25417>
* For now, move the visual mask flags into hgl_context.h
* This removes an un-needed dependency on GLView.h from glvnd
* Eventually, these need converted into normal EGL parameters
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26322>
Anybody will be tempted to factor out the if-else block code since it
looks like duplication but else block actually handles the ycbcr images
where the aspect masks are compatible but don't need to be the same.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26294>
vl_rbsp_fillbits may fill less than 32 bits if it removes emulation
prevention bytes, but will fill at least 16 bits. We need to call it
twice when reading more than 16 bits.
This fixes parsing H264 SPS packed header in va frontend when emulation
prevention bytes are at position where 32 bit values are read.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26276>
This flag indicates the requirement of helper invocations
in fragment shaders, independent from any present instructions.
This fixes the lowering of OpGroupNonUniformQuad* instructions.
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26026>
Set some state and implement dummy draws whenever viewport pointer
is being reprogrammed.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25987>
Add a helper that only emits hw_state, this makes it easier to modify
dirty state and call helper to emit only wanted state.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25987>
Set some state and implement dummy draws whenever viewport pointer
is being reprogrammed.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25987>
3b3b157961 removed setting the pipeline type
assuming that it was already set by nvk_pipeline_zalloc. That helper was
not actually being used, so this patch updates it to do so.
This does not fix anything as the NVK_PIPELINE_GRAPHICS = 0 anyway, so it
is just a code cleanup.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26329>
VTG_PRIMITIVES_OUT (VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT) seems to
always require a FLUSH_PENDING_WRITES.
This changes the behavior of every queries to ensure that we only flush
during end query.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26324>
In commit 1396dc1c a new output field was added as a parameter, but this
is a problem since the signature of the function are not versionned.
The flush function didn't have a versionned output struct. So what I'm
proposing here is that if the version of the input argument is new enough
(bumped to 2 here), then we re-use the existing argument, which until now
was directly a pointer to GLsync, and instead use it as a pointer to a
versioned struct.
We're just changing one pointer type to another, so in C, this should
be fine AFAIK.
Fixes: 1396dc1c
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26315>
It is a bad api and now unused.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26272>
useful for nir-based gallium meta, we have a tgsi equivalent already.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26272>
When given (e.g.) 3x 16-bit components to store on a device that
isn't using native 16-bit loads and stores, we should be lowering
that into one 32-bit store and one masked store. Instead, the logic
here ends up returning that the best we can do is one 8-byte store,
which is clearly wrong. Stores should round down, loads should
round up.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26293>
Those are not reused, so this will be the first and only allocation, so
no need to use the "realloc" variants.
For the fs_reg arrays, there's currently no particular reason to keep
them uninitialized, so zero-initialize them too -- not ideal but better
than random values.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26302>
