Make the filename more descriptive and since the file is used by
multiple drivers, move it into appropriate util/ directory.
Cosmetics:
- use SPDX license tag
- add newline before main function
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27804>
This has been confusing for some time, as from a xml file with the
suffix v33 (so suggesting just one version) we were generating the
headers for v33, v40, v41 and v71.
So now there is a header for the vc4 driver, and one header for the
v3d/v3dv (so v3d "platform") drivers.
FWIW, this means that now the name of the original xml and the header
files generated doesn't maintain a so similar pattern, but again the
equivalence were not there anyway.
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25851>
Using as reference the spec for 7.1.5. This include totally new
packets, and redefine some that already existed on v42.
Full list:
* Add Depth Bounds Test Limits
* Redefine Tile Binning Mode Cfg
* Redefine Cfg Bits. There are some changes on the fields:
* Line Rasterization is now 1 bit size
* Depth Bounds Enable (that takes one of the bits of Line Rasterization)
* Early-Z/Early-Z updates enable bits (16-17) figure now as reserved.
* New Z-Clipping mode field
* Redefine Tile Rendering Mode Cfg (Common). Changes with respect to v42:
* New log2 tile height/width fields starting at bit 52/55
* Due those two news, end pad is smaller
* sub-id has now a size of 3. Bit 4 is reserved.
* Number of render targets: this field max value is now 7 (not
reflected on the xml).
* Maximum BPP is removed on v71 (now bits 40-41 are reserved)
* Depth Buffer disable: on bit 44
* Update Store Tile Buffer General
* Adding Cfg Render Target Part1/2/3 packets: they replace v4X "Tile
Rendering Mode Cfg (Color)" (real name "Rendering Configuration
(Render Targets Config)"), "Tile Rendering Mode Cfg (Clear Colors
Part1)", "Tile Rendering Mode Cfg (Clear Colors Part2)", and "Tile
Rendering Mode Cfg (Clear Colors Part3)". On those old versions,
the first packet is used to configure 4 render targets. Now that 8
are supported, invididual per-render-target are used.
* Update ZS clear values packet.
* Add new v71 output formats
* Define Clear Render Targets (Replaces Clear Tile Buffers from v42)
* Redefine GL Shader State Record. Changes copared with v42:
* Fields removed:
* "Coordinate shader has separate input and output VPM blocks"
(reserved bit now)
* "Vertex shader has separate input and output VPM blocks"
(reserved bit now)
* "Address of table of default attribute Values." (we needed to
change the start position for all the following fields)
* New field:
* "Never defer FEP depth writes to fragment shader auto Z writes
on scoreboard conflict"
* Redefine clipper xy scaling: Now it uses 1/64ths of pixels, instead
of 1/256ths
* Update texture shader state.
* Notice we don't use an address type for these fields in the XML
description. This is because the addresses are 64-bit aligned
(even though the PRM doesn't say it) which means the 6 LSB bits
are implicitly 0, but the fields are encoded before the 6th bit
of their starting byte, so we can't use the usual trick we do
with address types where the first 6 bits in the byte are
implicitly overwritten by other fields and we have to encode this
manually as a uint field. This would mean that if we had an
actual BO we would also need to add it manually to the job's
list, but since we don't have one, we don't have to do anything
about it.
* Add new RB_Swap field for texture shader state
* Document Cb/Cr addresses as uint fields in texture shader state
* Fixup Blend Config description: we now support 8 RTs.
* TMU config parameter 2 has new fields
* Add new clipper Z without guardband packet in v71
* Add enums for the Z clip modes accepted in v71
* Fix texture state array stride packing for V3D 7.1.5
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
This adds 7.1 to the list of available V3D_VERSION, and first changes
on the simulator needed to get it working.
Note that we needed to touch all those 4 codebases because it is
needed if we want to use V3D_DEBUG=clif with the simulator, that it is
the easier way to see which packets a vulkan program is using.
About the simulator, this commit only handle the rename of some
registers. Any additional changes needed to get a proper support for
v71 will be handled them on following commits.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25450>
These are split between fine and coarse coordinates. We have only been
using fine until now, so we kept the same naming convention we had
prior to V3D 4.1 for simplicity, but we will start using the coarse
coordinates soon too.
Also, the signedness was reversed: coarse coordinates are signed and
fine coordinates are unsigned.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23489>
The first argument is the name of the library, and the second argument
is the list of files; those two got a bit mixed up.
Fixes: 1ae8018a6a ("meson: Add support for the vc4 driver.")
Fixes: 4f3e380fa0 ("meson: Add support for the vc5 driver.")
Signed-off-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18593>
Add the supported line rasterization modes as enums in the XML packet
definition.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15407>
We have a "maximum bpp of all render targets" field for several
packets. For them we were defining manually the possible values. But
all the possible values are the ones defined at the already defined
type "Internal BPP". So in practice we were defining the possible BPP
values twice.
Also for those fields, sometimes we were using the "Internal BPP" type
and in some other cases we were not, so this commit also adds some
consistency.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11976>
Use a unsigned int type in the loop to avoid unintended sign extensions.
Fixes CID#1414500 (Unintended sign extension [SIGN_EXTENSION]).
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10060>
Given what a niche developer tool CLIF dumps are, no sense requiring
libexpat just for that.
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9764>
This adds an enum to the load tile buffer that forces the alpha channel
to be set to 1. This will be required later to load RGBX formats.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7816>
There are two bits for the vector size of a vertex input, with the
value 0 meaning 4 components. The CLE decoder seems to try and dump
"4" instead of "0" is to be a bit more user friendly, but it had an
off-by-one error that would cause it to dump "2" instead.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7271>
We were configuring the TLB to use ABGR1555, but that doesn't really
give us what we want. There were two issues:
* We were using the wrong Texture Data Format and Output Image
Format. In fact those we need to use were not included on the
packet file.
* Even using the correct one, we need to do a RB swap to match the
semantics of the Vulkan format.
This patch fixes both issues. As we are here we keep the formats we
were already used, that would provide support for r5g5b5a1.
So this patch makes tests like the following going from skip to pass:
dEQP-VK.texture.filtering.2d.formats.r5g5b5a1_unorm.nearest
And the following test from fail to pass:
dEQP-VK.texture.filtering.2d.formats.a1r5g5b5_unorm.nearest
Note that the R5G5B5A1_UNORM_PACK16 is not mandatory, but as we
already made the effort to understand them and get them working let's
just keep it on the list
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
This uses a meson builtin to handle -fvisibility=hidden. This is nice
because we don't need to track which languages are used, if C++ is
suddenly added meson just does the right thing.
Acked-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4740>
Let's make it clear what includes are being added everywhere, so that
they can be cleaned up.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4360>
According to the documentation, the 1-way dispatch width is only supported
with geometry shaders.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Every code address starts at bit 3 (addresses must be 64-bit aligned),
with the first 3 bits used to specify threading and NaN propagation
parameters for the shader program.
We generally skip "reserved" bits, however, doing this when the
reserved field is the last in a struct and it is large enough can
make us compute incorrect (smaller) struct sizes which can
lead to corrupt CLs. In particular, the "Tess/Geom Common Params"
struct has a reserved field at the end that is 8-bit, so if we
don't include this we compute a packet size that is 1 byte smaller
than it shold, making the next packet we emit start 1 byte
earlier and therefore leading to incorrect CL data from that point
forward.
The name of one of the fields was not correct.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Fixes: 8d43e2b2de ("meson: add -Werror=empty-body to disallow `if(x);`")
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
We can use the PRIMITIVE_COUNTS_FEEDBACK packet to write various primitive
counts to a buffer, including the number of primives written to transform
feedback buffers, which will handle buffer overflow correctly.
There are a couple of caveats with this:
Primitive counters are reset when we emit a 'Tile Binning Mode Configuration'
packet, which can happen in the middle of a primitives query, so we need to
read the buffer when we submit a job and accumulate the counts in the context
so we don't lose them.
We also need to do the same when we switch primitive type during transform
feedback so we can compute the correct number of recorded vertices from
the number of primitives. This is necessary so we can provide an accurate
vertex count for draw from transform feedback.
v2:
- When computing the number of vertices for a primitive, pass in the base
primitive, since that is what the hardware will count.
- No need to update primitive counts when switching primitive types if
the base primitives are the same.
- Log perf warning when mapping the primitive counts BO for readback (Eric).
- Only emit the primitive counts packet once at job end (Eric).
- Use u_upload mechanism for the primitive counts buffer (Eric).
- Use the XML to generate indices into the primitive counters buffer (Eric).
Fixes piglit tests:
spec/ext_transform_feedback/overflow-edge-cases
spec/ext_transform_feedback/query-primitives_written-bufferrange
spec/ext_transform_feedback/query-primitives_written-bufferrange-discard
spec/ext_transform_feedback/change-size base-shrink
spec/ext_transform_feedback/change-size base-grow
spec/ext_transform_feedback/change-size offset-shrink
spec/ext_transform_feedback/change-size offset-grow
spec/ext_transform_feedback/change-size range-shrink
spec/ext_transform_feedback/change-size range-grow
spec/ext_transform_feedback/intervening-read prims-written
Reviewed-by: Eric Anholt <eric@anholt.net>
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
4.1 and 4.2 both have the same 16k limit, but it I'm seeing GPU hangs in
the CTS at 8k and 16k. 4k at least lets us get one 4k display working.
Cc: mesa-stable@lists.freedesktop.org
The sampler border color is encoded in the TMU's blending format (half
floats, 32-bit floats, or integers) and must be clamped to the format's
range unorm/snorm/int ranges by the driver. Additionally, the TMU doesn't
know about how we're abusing the swizzle to support BGRA, A, and LA, so we
have to pre-swizzle the border color for those.
We don't really want to spend half a kb on sampler states in most cases,
so skip generating the variants when the border color is unused or is
0,0,0,0.
In trying to enable compute shaders, I found that a bunch of deqp-gles31's
compute stuff wanted to interact with indirect dispatch. This was easy to
do on its own.
Currently we have two sets of functions for bit counts, one in gallium
and one in core mesa. The ones in core mesa are header only in many
cases, since they reduce to "#define _mesa_bitcount popcount", but they
provide a fallback implementation. This is important because 32bit msvc
doesn't have popcountll, just popcount; so when nir (for example)
includes the core mesa header it doesn't (and shouldn't) link with core
mesa. To fix this we'll promote the version out of gallium util, then
replace the core mesa uses with the util version, since nir (and other
non-core mesa users) can and do link with mesautils.
Acked-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
