RGP traces need a dump of shader code in order to display ISA and
instruction trace. Previously, this was read back from GPU at trace
creation time. However, for future changes that implements upload shader
to invisible VRAM, the upload destination will be a temporary staging
buffer and will be only accessible during shader creation.
To allow dumping in such cases, copy the shader code to a separate buffer
at creation time, if thread tracing is enabled.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21513>
some drivers may provide this in heaps that get used by non-staging resources,
so avoid extra copies in that case
unlike the previous attempt at this optimization, this utilizes the screen-based
context for thread-safe transfers, which should avoid races/crashes
fix#8171
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21452>
G13 does not support sampler descriptor LOD biasing, so this needs to be lowered
to shader code for APIs that require this functionality. Add an option to do
this lowering while doing our other backend texture lowerings. This generates
lod_bias_agx texture instructions which the driver is expected to lower
according to its binding model.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21276>
Track the LOD bias of samplers and upload them at draw time to uniform
registers. This could be optimized in the future.
Vulkan will probably want to pull from a descriptor set instead.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21276>
Add a new texture opcode that returns the LOD bias of the sampler. This will be
used on AGX to lower sampler LOD bias to txb and friends. This needs to be a
texture op (and not a new intrinsic) to handle both bindless and bindful
samplers across GL and Vulkan in a uniform way.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21276>
Now that we're working on lowered I/O, passing in the dual source blend colour
via a sideband doesn't make any sense. The primary source blend colours are
implicitly passed in as the sources of store_output intrinsics; likewise, we
should get dual source blend colours from their respective stores. And since
dual colours are only needed by blending, we can delete the stores as we go.
That means nir_lower_blend now provides an all-in-one software lowering of dual
source blending with no driver support needed! It even works for 8 dual-src
render targets, but I don't have a use case for that.
The only tricky bit here is making sure we are robust against different orders
of store_output within the exit block. In particular, if we naively lower
x = ...
primary color = x
y = ...
dual color = y
we end up emitting uses of y before it has been defined, something like
x = ...
primary color = blend(x, y)
y = ...
Instead, we remove dual stores and sink blend stores to the bottom of the block,
so we end up with the correct
x = ...
y = ...
primary color = blend(x, y)
lower_io_to_temporaries ensures that the stores will be in the same (exit)
block, so we don't need to sink further than that ourselves.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21426>
Power-of-two SW stack sizes are prone to causing collisions in the
hashing function used by the L3 to map memory addresses to banks,
which can cause stack accesses from most DSSes to bottleneck on a
single L3 bank. Fix it by padding the SW stack stride by a single
cacheline if it was a power of two. This has been reported by Felix
DeGrood to improve Quake2 RTX performance by ~30% on DG2-512 in
combination with other RT patches Lionel Landwerlin has been working
on.
Many thanks to Felix DeGrood for doing much of the legwork and
providing several iterations of Q2RTX performance counter dumps which
eventually prompted me to consider the hash collision theory and
motivated this patch, and for providing additional performance counter
dumps confirming that there is no longer an appreciable imbalance in
traffic across L3 banks after this change.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21461>
Do this by removing the compatibility table and only using hard coded shaders
when present. The hard coded shaders, along with the hard coding framework
itself, can be dropped once the compiler is capable of compiling the hard coded
shaders. In the meantime we don't want to risk regressing things that we know
work because we temporarily can't test them.
This restriction is being dropped now as the new compiler framework has been
merged and we want to make use of it so it can be developed further.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21495>
After 16 entries, we fall back to the previous logic that used a hash
map to link the resource's state per context.
Preventing hash map churn by cheaply tracking up to 16 context's worth
of states per resource significantly reduces CPU cost in
find_or_create_state_entry
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21528>
Now that turnip can support multiple kernel-mode drivers in a single
build, re-work the meson option to have a single list of KMDs, rather
than special options to enable kgsl for turnip or virtio for gallium.
It is temporarily a bit awkward as gallium does not yet support kgsl
and turnip does not yet support virtio. But both of those are planned
or in-progress, so long term a single list is the most sensible option.
TODO freedreno/drm support to build with only virtio support.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21394>
1) Allow the two different entrypoints for drm vs non-drm (kgsl) to
coexist.
2) Split the generic drm related device initialization from the msm
specifics. This will simplify adding support for additional drm
based kernel mode drivers (ie. virtgpu)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21394>
Because kgsl sync primitives are not drm_syncobj, the kgsl kernel
support needs the ability to patch in it's own entrypoints related
to fences, etc. The current entrypoint table magic using weak syms
won't work if we are building both kgsl and drm support into one
binary, so switch to runtime patching in the kgsl specific entry-
points.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21394>
To allow support for multiple KMD's to coexist, split out vfuncs. This
doesn't quite *yet* let us have kgsl and msm coexist, because of the
different vk entrypoints needed by the kgsl backend.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21394>
The end goal is a single build that supports kgsl (non-drm) as well
as msm and virtgpu (both drm). First lets move around some files to
accomodate that.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21394>
Seems this document has moved since last we updated this link. But
instead of chasing the exact CDN link, let's link to the document on
Intel's website. There's both a download-link there, as well as the
ability to read the document online.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21448>
This allows us to also inherit `-mfpmath=sse` added in previous commit.
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21371>
Since cull_mask is only one byte, we can trivially store it in the same
register as the flags. This leaves us with a 2% performance gain in
Quake II RTX:
Totals from 7 (14.00% of 50) affected shaders:
VGPRs: 720 -> 688 (-4.44%)
CodeSize: 213052 -> 212980 (-0.03%); split: -0.05%, +0.02%
MaxWaves: 67 -> 70 (+4.48%)
Instrs: 39429 -> 39394 (-0.09%); split: -0.15%, +0.06%
Latency: 1096258 -> 1096943 (+0.06%); split: -0.05%, +0.11%
InvThroughput: 230661 -> 222963 (-3.34%); split: -3.42%, +0.08%
VClause: 1208 -> 1206 (-0.17%); split: -0.25%, +0.08%
Copies: 5321 -> 5269 (-0.98%); split: -1.22%, +0.24%
Branches: 1903 -> 1902 (-0.05%)
PreVGPRs: 650 -> 645 (-0.77%)
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21470>
Fix a build error with -Dvulkan-beta=true:
../src/gallium/drivers/zink/zink_screen.c: In function ‘zink_internal_create_screen’:
../src/gallium/drivers/zink/zink_screen.c:2764:20: error: ‘struct zink_device_info’ has no member named ‘have_KHR_portability_subset’
2764 | if (screen->info.have_KHR_portability_subset) {
| ^
../src/gallium/drivers/zink/zink_screen.c:2765:60: error: ‘struct zink_device_info’ has no member named ‘portability_subset_feats’
2765 | screen->have_triangle_fans = (VK_TRUE == screen->info.portability_subset_feats.triangleFans);
| ^
Fixes: e02cdb397e ("zink: prefer vulkan_core.h over vulkan.h")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21491>
now that the mem type is passed directly to pb, there have to be enough
slabs to allocate all the mem types (not heaps), so create memoryTypeCount
slabs to allow this
fixes#8369
Fixes: f6d3a5755f ("zink: zink_heap isn't 1-to-1 with memoryTypeIndex"
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21526>
