We now use `parse_debug_string` to parse debug strings from files, which
may have newlines in them. This change ensures that newline characters
are ignored during parsing, a similar change was made to
`parse_enable_string` for consistency.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32906>
Currently, nir_lower_printf depends on a per-nir_shader table, writing out
indices into the printf buffer. This works for real OpenCL implementations
(rusticl, microsoft) which can associate the printf buffer with a particular
kernel, I guess. (Actually it's not clear to me that it works well there either
but that's not my problem.)
This mechanism is unsuitable for internal driver shaders, where printfs with
unique format strings can come from many different nir_shaders. There are two
current solutions in tree to this for driver CL:
* Honeykrisp: Only use one single nir_shader (libagx). This prevents us from
using printf in common CL and requires extra driver tracking. It won't work
with my upcoming vtn_bindgen rework, which is why I'm addressing this now.
* Anv: Offset format-string indices by a dynamic "base identifier" using relocs
or a push constant, then pool format strings into a table from nir_shader's
across the device. The problem here is that these indices now depend on the
order that nir_shaders are seen (which causes a mess for caching if relocs are
used, or requires extra push constants and extra bookkeping if relocs aren't
used). And the driver tracking required to do this pooling correctly is even
more complicated than what Honeykrisp does. I do not want every driver in-tree
needing to go down this path, and it wouldn't work with my upcoming
vtn_bindgen.
This MR introduces an alternate approach: rather than writing indices into the
table, we instead hash the format string itself and write the hash. That doesn't
depend on what nir_shader we came from, so we can freely mix & match and get
consistent hashes. That greatly alleviates driver tracking burden. To make that
possible, we need a global hash table mapping hashed format identifiers to the
format strings themselves.
That approach still requires a step to "register" format strings into the table.
That step would not be required if we wrote the actual strings themselves into
the table, but that was ruled out for performance/code size reasons. However, we
do not want drivers to need to explicitly register all the strings they use,
because once we have OpenCL in common code via vtn_bindgen2, drivers won't know
all the strings they use. Fortunately, there's a neat solution for that too.
By making this global table a singleton (with internal locking), vtn_bindgen2
can automatically register format strings via a static constructor. In
conjunction with the infrastructure added here, that eliminates all driver
bookkeeping required for format-strings.
The code itself is inspired by the glsl type singleton. Is it pretty? Not
really, but it gets the job done well.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33067>
Each reg may store a list of conflict regs. This was handled by
util_dynarray, however each of those hold an extra pointer for
the ra_regs (which serves as mem_ctx for that). Since the usage
here is very simple, we just handle the array growth manually.
The initial size remains the same as before.
The mem_ctx of each ra_reg was being used to identify the case
in which the list wasn't used. Change to use a bool in the
ra_regs struct instead.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25744>
Each node stores a list of adjacent nodes. This was handled by
util_dynarray, however each of those hold an extra pointer for
the ra_graph (which serves as mem_ctx for that). Since the usage
here is very simple, we just handle the array growth manually.
For now keep using the same initial size as was being used by dynarray.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25744>
force_gl_names_reuse is changed to integer.
-1 means default (currently disabled), 0 means disabled, 1 means enabled
The names reuse initialization is moved to _mesa_alloc_shared_state ->
_mesa_InitHashTable instead of _mesa_HashEnableNameReuse.
It will be enabled by default.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32715>
Without this the game crashes during the loading screen.
The game uses vkUpdateDescriptorSetWithTemplate and, in certain cases,
passes VkDescriptorBufferInfo structures where the offset + range
exceeds the size of the buffer. This triggers an assertion when
vk_buffer_range() is called, causing the game to crash.
When the nvidia vendor id is used the range is consistently set to 65536.
Without it the range varies and is much smaller - never exceeding 1000.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12349
Cc: stable
Reviewed-by: Faith Ekstrand <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32764>
Source 2 games segfault if certain buffers are not able to use the same
memory types as images. CS2 specifically expects this to be the case for
vertex and index buffers (VK_BUFFER_USAGE_2_INDEX_BUFFER_BIT,
VK_BUFFER_USAGE_2_VERTEX_BUFFER_BIT). I have not tested other Source 2
games to see how much the requirement differs for the usage (if at all).
Up until now, we've disabled CCS for the Source 2 engine with the
anv_disable_xe2_ccs driconf option. However, this option is not great
for performance. So, replace this with a new option to allow the same
memory types we use for images on buffers - anv_enable_buffer_comp.
Compression of buffers is generally not good for performance. I
collected the result of unconditionally enabling the feature in the
performance CI on BMG. I used the default configuration to average the
result of two runs of each trace.
The CI reports that 4 game traces would regress between 0.44-1.01% FPS
with buffer compression. However, the CI actually shows it to be
beneficial in three of our game traces:
* Cyberpunk-trace-dx12-1080p-high 106.51%
* Hitman3-trace-dx12-1080p-med 101.59%
* Blackops3-trace-dx11-1080p-high 100.44%
So, enable the option for the two games we already have driconf entries
for, Cyberpunk and Hitman3.
Of course, also enable the option for Source 2 games. Casey Bowman
reports that on BMG, some frame times drop from ~15ms to ~7ms in CS2.
This is in large part due to the removal of HiZ resolves, which is a
consequence of the game now using of HIZ_CCS_WT instead of plain HIZ.
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11520
Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32519>
The pass that lowers PS outputs has been rewritten since 45d8cd037a
("ac/nir: rewrite ac_nir_lower_ps epilog to fix dual src blending
with mono PS") to handle invalid uses of dual-source blending.
This drirc used to workaround game bugs on GFX11 only should no longer
be necessary.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32514>
