When there is no elements in struct/interface, the alignment of it should be 1 instead of 0.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23841>
In addition to the hexadecimal and float (when applicable), print the
signed and unsigned representations. Representations may be omitted based
on information about the value:
- If gather types has unambiguous information, we use it;
- Float is omitted for 8 bit values;
- Signed decimal is omitted for positive values;
- Unsigned decimal is omitted for small values (representation is same as hex);
Note for now the "terse form" that appear in SSA uses is unchaged.
Based on a patch by Mike Blumenkrantz.
Examples:
```
// Just used as float. Omitted decimals.
vec4 32 ssa_81 = load_const (0x3f800000, 0x3f800000, 0x3e4ccccd, 0x3f800000) = (1.000000, 1.000000, 0.200000, 1.000000)
vec1 32 ssa_28 = load_const (0x3e4ccccd = 0.200000)
// Just a small integer. Omitted float and decimal.
vec1 32 ssa_45 = load_const (0x00000001)
// Larger positive integers. Omitted float.
vec1 32 ssa_39 = load_const (0x00002000 = 8192)
vec1 32 ssa_30 = load_const (0x000000ff = 255)
vec1 32 ssa_28 = load_const (0x00000010 = 16)
// Integers with negative values.
load_const (0xff = -1 = 255)
load_const (0xff80 = -128 = 65408)
load_const (0xffff = -1 = 65535)
// Same value, in the first case we know is used as an integer.
load_const (0xffffffe0 = -32 = 4294967264)
load_const (0xffffffe0 = -nan = -32 = 4294967264)
```
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23562>
If the src_type is not available, untie by looking at the results from
nir_gather_ssa_types(). If that is ambiguous, just pick uint.
Now in print_const_from_load() when the type is invalid, print the full
constant form (with both padded hex and float); when the passed type
is valid, print the terse form based on it.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23562>
The existing helper returns a `nir_src *` so expects a non-const instr.
We plan to use this function in queries that don't modify the shader, so
create (and use internally) a variant that returns the index instead.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23562>
If we infer a type for a reg, just ignore and keep going. This will allow
to use this pass even when registers are present.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23562>
The files included are extremely large and hurt compile time of
everything that inludes half_float.h directly or indirectly.
Compile time of a fresh RADV build:
before 32.477s 32.661s 32.625s
after 25.116s 24.928s 25.114s
v2: Include xmmintrin instead (Marek Olšák)
after 25.552s 25.811s 25.678s
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23871>
There's no point in bloating the vertex_info struct everywhere with
information that's only used by i915 in a single place. Let's explicitly
store the hwinfo when needed, instead of piggy-backing on vertex_info.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23851>
Previously the code assumed that you could only have depth-stencil
attachments so no stencil only or depth only, for ZLS load/stores.
This isn't true as we can have stencil only attachments so the
ZLS depth and stencil store/load enable have to be set separately.
Other ZLSCTL setup has also been adjusted for separate depth-stencil.
E.g. the z{load,store}format, and {load,store}twiddled.
Co-Authored-By: Soroush Kashani <soroush.kashani@imgtec.com>
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Signed-off-by: Soroush Kashani <soroush.kashani@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23830>
Called copy_image_to_buffer_texel_buffer, that reuses
copy_image_linear_texel_buffer, by setting up a image destination from
the buffer destination.
This fixes new ycbcr tests added recently (1.3.6.0) like:
dEQP-VK.ycbcr.copy.*.*.*buffer*
that were failing due lack of a codepath handling them.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23864>
In order to have common code to create a image from a buffer, that we
plan to use later on a new codepath.
This refactor adds three new methods:
* One that gathers all the info required to create the structures and
implement the operation
* One that creates the image from the buffer, based on that info
* One that creates a BlitRegion from that info
This seems like too much splitting, but we needed to do it in this
way, because we can't ensure that future uses of this common code
would use a BlitRegion.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23864>
Done by hand at each call site but going very quickly with funny Vim motions and
common regexes. This is a very common idiom in NIR.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23807>
Most users of nir_foreach_function actually want the nir_function_impl, not the
nir_function, and want to skip empty functions (though some graphics-specific
passes sometimes fail to do that part). Add a nir_foreach_function_impl macro
to make that case more ergonomic.
nir_foreach_function_impl(impl, shader) {
...
foo(impl)
}
is equivalent to:
nir_foreach_function(func, shader) {
if (func->impl) {
...
foo(func->impl);
}
}
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23807>
git://anongit.freedesktop.org/drm/drm 2222dcb0775d36de28992f56455ab3967b30d380
The motivation for this change in to get the uapi changes from:
commit 81b1b599dfd71c958418dad586fa72c8d30d1065
Author: Fei Yang <fei.yang@intel.com>
Date: Tue Jun 6 12:00:42 2023 +0200
drm/i915: Allow user to set cache at BO creation
Specifically, the I915_GEM_CREATE_EXT_SET_PAT extension.
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/22878>
The Vulkan specification indicates that if memory types have
properties which are a strict subset of another type's, then they
should appear before that memory type. Otherwise the specification
does not require a specific ordering of memory types.
But, it appears that Aztec Ruins and the Vulkan CTS make an assumption
that the first host-accessible memory type is host-coherent and select
it when they expect data written by the CPU to become visible without
calling vkFlushMappedMemoryRanges(), even though flushing is required
by the spec, which leads to misrendering and hangs on MTL platforms.
We found that other drivers also put a host-coherent, but not cached
memory type as the first host-accessible memory type, so let's do the
same in order to match the expectations of such broken applications.
Host-coherent uncached memory types are currently implemented with a
WC CPU map on non-LLC platforms, so there shouldn't be a huge
performance penalty from this: If an application intends to do heavy
R/W CPU access on a memory range it's expected to loop over the
available memory types and select one marked as host-cached -- If an
application fails to do that and simply selects the first available
type it seems more robust to stay on the safe side and give them a
host-coherent type rather than a cached one.
Rework:
* Jordan: Add initial explanation to body of commmit message.
* Curro: Add additional comments to commit message.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878>
