- Jun 26, 2023
-
-
Hyunjun Ko authored
Fixes: 8d519eb5 ("anv: add initial video decode support for h265") Closes: mesa/mesa#9214 Signed-off-by:
Hyunjun Ko <zzoon@igalia.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Part-of: <mesa/mesa!23790>
-
Hyunjun Ko authored
Turned out to be unsigned here after some experiments. Signed-off-by:
Hyunjun Ko <zzoon@igalia.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Part-of: <mesa/mesa!23790>
-
Hyunjun Ko authored
Signed-off-by:
Hyunjun Ko <zzoon@igalia.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Part-of: <mesa/mesa!23790>
-
- Jun 25, 2023
-
-
Acked-by:
Ivan Briano <ivan.briano@intel.com> Part-of: <mesa/mesa!23837>
-
In the new Vulkan Headers, VK_KHR_cooperative_matrix gets added and the feature names are the same. Acked-by:
Ivan Briano <ivan.briano@intel.com> Part-of: <mesa/mesa!23837>
-
Karol Herbst authored
Applications can do their own caching, but are in any case required to properly "compiler" the binaries via clBuildProgram or clCompileProgram + clLinkPrograms. In any case, there is no point building something if we already have the result. Signed-off-by:
Karol Herbst <git@karolherbst.de> Reviewed-by:
Nora Allen <blackcatgames@protonmail.com> Part-of: <mesa/mesa!23847>
-
- Jun 24, 2023
-
-
Apparently on some ARM systems any older bindgen version crashes. Signed-off-by:
Karol Herbst <git@karolherbst.de> Reviewed-by:
Nora Allen <blackcatgames@protonmail.com> Part-of: <mesa/mesa!23840>
-
This function is added for create strong relationship between nir_function_impl and nir_function. So that nir_function->impl->function == nir_function is always true when (nir_function->impl != NULL && nir_function->impl != NIR_SERIALIZE_FUNC_HAS_IMPL) And indeed this invariant is already done in functions validate_function and validate_function_impl of nir_validate Signed-off-by:
Yonggang Luo <luoyonggang@gmail.com> Reviewed-by:
Alyssa Rosenzweig <alyssa@collabora.com> Part-of: <mesa/mesa!23820>
-
Signed-off-by:
Yonggang Luo <luoyonggang@gmail.com> Reviewed-by:
Alyssa Rosenzweig <alyssa@collabora.com> Part-of: <mesa/mesa!23820>
-
Yonggang Luo authored
Signed-off-by:
Yonggang Luo <luoyonggang@gmail.com> Reviewed-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <mesa/mesa!23845>
-
Yonggang Luo authored
This can not be done with tools, so do it manually Signed-off-by:
Yonggang Luo <luoyonggang@gmail.com> Reviewed-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <mesa/mesa!23845>
-
Yonggang Luo authored
These change can not be done with tools, so do it manually Signed-off-by:
Yonggang Luo <luoyonggang@gmail.com> Reviewed-by:
Erik Faye-Lund <erik.faye-lund@collabora.com> Part-of: <mesa/mesa!23845>
-
Without generating a proper timestamp for the disk cache, we pull old binaries out of the disk cache, potentially being buggy or simply outdated. Once meson 1.2 lands we can easily pull in LLVM functions. Signed-off-by:
Karol Herbst <kherbst@redhat.com> Reviewed-by:
Nora Allen <blackcatgames@protonmail.com> Part-of: <mesa/mesa!21612>
-
Signed-off-by:
Karol Herbst <git@karolherbst.de> Reviewed-by:
Nora Allen <blackcatgames@protonmail.com> Part-of: <mesa/mesa!21612>
-
Signed-off-by:
Karol Herbst <kherbst@redhat.com> Reviewed-by:
Nora Allen <blackcatgames@protonmail.com> Part-of: <mesa/mesa!21612>
-
It became quite a mess, I had enough
Signed-off-by:Karol Herbst <kherbst@redhat.com> Reviewed-by:
Nora Allen <blackcatgames@protonmail.com> Part-of: <mesa/mesa!21612>
-
There's no reason to use the gallium `p_compiler.h` types in vulkan code. Inspired by mesa/mesa!23577 , but using `size_t` for `ulist_data_size` because its two users are `blob_read_bytes()` and `memcpy()`, both of which expect a `size_t`. Signed-off-by:
Eric Engestrom <eric@igalia.com> Reviewed-by:
Yonggang Luo <luoyonggang@gmail.com> Reviewed-by:
Alejandro Piñeiro <apinheiro@igalia.com> Part-of: <mesa/mesa!23795>
-
Signed-off-by:
Eric Engestrom <eric@igalia.com> Reviewed-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <mesa/mesa!23722>
-
Signed-off-by:
Eric Engestrom <eric@igalia.com> Reviewed-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <mesa/mesa!23722>
-
Signed-off-by:
Eric Engestrom <eric@igalia.com> Reviewed-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <mesa/mesa!23722>
-
The problem is when we have DP2 or DP3 instruction that writes a w channel like here: DP3 temp[148].w, -temp[147].xyz_, temp[57].xyz_; will get pair-converted to src0.xyz = temp[147], src1.xyz = temp[57] DP3, -src0.xyz, src1.xyz DP3 temp[148].w, -src0._, src0._ where the alpha instruction is a basically just a replicate of the result from the RGB sub intruction. However the destination register index in the RBG slot is also 148. Now we pair-schedule and regalloc src0.xyz = temp[13], src1.xyz = temp[3] DP3, -src0.xyz, src1.xyz DP3 temp[3].w, -src0._, src0._ We properly regalloc the alpha channel, but we obviously skip the rgb, because the writemask is empty there. However when we emit the shader later, we actually check the number of used regs based on the maximum used register index and we don't consider the writemasks, so we would think we use 149 temps. AFAIK the shader would be still completelly OK. But we would think it hits the HW limits and used a dummy one instead. Fix this by checking for empty writemasks when marking the registers as used. GAINED: shaders/glmark/1-22.shader_test FS This is also needed to prevent another lost Trine shader from mesa/mesa!23089 Reviewed-by:
Filip Gawin <filip.gawin@collabora.com> Part-of: <mesa/mesa!23838>
-
This fixes dEQP-VK.api.info.format_properties.g8_b8r8_2plane_420_unorm in combination with the CTS fix from https://gerrit.khronos.org/c/vk-gl-cts/+/12191 Fixes: 93614817 ("anv: add video format features for the one supported video output format") Closes: mesa/mesa#8263 Part-of: <mesa/mesa!23776>
-
Part-of: <mesa/mesa!23776>
-
Even though the field is called `numBarriers` we set it to 1 just like we do with TGSI. It's unknown on what's the proper behavior here is. But without this set the GPU will complain to us loudly, so this silences at least that. Fixes: a2d7a4f9 ("nv50/ir: convert to scoped_barrier") Signed-off-by:
Karol Herbst <git@karolherbst.de> Reviewed-by:
M Henning <drawoc@darkrefraction.com> Part-of: <mesa/mesa!23749>
-
Signed-off-by:
Karol Herbst <git@karolherbst.de> Reviewed-by:
M Henning <drawoc@darkrefraction.com> Part-of: <mesa/mesa!23749>
-
This is useful for running applications known to pass in invalid SPIR-V. Signed-off-by:
Karol Herbst <git@karolherbst.de> Reviewed-by:
Nora Allen <blackcatgames@protonmail.com> Part-of: <mesa/mesa!23818>
-
Signed-off-by:
Karol Herbst <git@karolherbst.de> Reviewed-by:
Nora Allen <blackcatgames@protonmail.com> Part-of: <mesa/mesa!23818>
-
Signed-off-by:
Karol Herbst <git@karolherbst.de> Reviewed-by:
Nora Allen <blackcatgames@protonmail.com> Part-of: <mesa/mesa!23818>
-
On Alchemist, the FF_MODE2 documentation says that we must set the FF_MODE2 timer values for GS and HS to 224. The hardware performance tuning guide also recommends setting the TDS timer to 4. On Tigerlake, i915 applies workarounds to set the GS timer to 224 (failing to do so can cause HS/DS unit hangs), and the TDS timer to 4 (for performance). It doesn't currently apply a HS timer there, and I'm not sure if it's strictly necessary, but given that Alchemist needed it, and the other two settings matched, let's assume that it ought to match as well. Unfortunately, there has been a bug in the i915 workarounds infrastructure for non-masked context registers where writing one field of the register zeroes out all the others. So, I believe the Tigerlake TDS timer value of 4 isn't being applied correctly there, though the register is also not readable on that platform which makes it hard to verify. So, this may also speed up tessellation. Closes: mesa/mesa#9233 Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Cc: mesa-stable Part-of: <mesa/mesa!23839>
-
- Jun 23, 2023
-
-
This enables L3 partial write merging for a number of cases that seem to be getting accidentally disabled by the kernel, which was causing a serious performance bottleneck on DG2 and MTL platforms. The "Compressible Partial Write Merge Enable", "Coherent Partial Write Merge Enable" and "Cross-Tile Partial Write Merge Enable" bits in L3SQCREG5 were expected to be enabled by default (and confusingly, they even read off as enabled if you ran 'intel_reg read 0xb158' on an idle system), but they are getting clobbered during 3D context initialization by an i915 workaround. Enabling L3 partial write merging of compressible surfaces in particular seems to increase rendering fillrate by over 3x in some cases (e.g. the "VulkanFillRate/FillRateGPU/resolution:1[0-3]/format:*/blend:0" fillrate-bound microbenchmarks). Significant improvements can also be reproduced in most real-world workloads we've tested so far, e.g. Counter Strike GO improves by ~11%, Shadow Of the Tomb Raider improves by ~5.5%, and AztecRuins-VK improves by ~6.5% on DG2-512 -- Thanks a lot to Caleb Callaway for these figures. No regressions have been observed so far. Even though this patch might strike as surprisingly simple for such a large payoff, it's the result of Felix DeGrood and I trying to root-cause the rendering performance gap of DG2 on Linux vs Windows on and off during the last year, and some of the OA statistics captured by Felix early this month were greatly helpful for me to connect the last few dots, so Felix deserves a big chunk of the credit for this work. Cc: mesa-stable Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Part-of: <mesa/mesa!23783>
-
Faster download, one less step. Win-win. Signed-off-by:
David Heidelberg <david.heidelberg@collabora.com> Part-of: <mesa/mesa!23816>
-
Added some checks for NULL pointer dereferencing and loop bounds. v2: Use ARRAY_SIZE instead of magic numbers (@jenatali) Signed-off-by:
Thong Thai <thong.thai@amd.com> Reviewed-by:
Jesse Natalie <jenatali@microsoft.com> Part-of: <mesa/mesa!23598>
-
In both cases there's code right after the execution to check the result and give a proper message. This gets rid of meson warning ``` WARNING: You should add the boolean check kwarg to the run_command call. It currently defaults to false, but it will default to true in future releases of meson. See also: https://github.com/mesonbuild/meson/issues/9300 ``` Reviewed-by:
Eric Engestrom <eric@igalia.com> Reviewed-by:
Yonggang Luo <luoyonggang@gmail.com> Part-of: <mesa/mesa!23821>
-
Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com> Reviewed-by:
Eric Engestrom <eric@igalia.com> Closes: #9221 Part-of: <!23725>
-
The SSA killer feature is that, under an "optimal" allocator, the number of registers used (register demand) is *equal* to the number of registers required (register pressure, the maximum number of variables simultaneously live at any point in the program). I put "optimal" in scare quotes, because we don't need to use the exact minimum number of registers as long as we don't sacrifice thread count or introduce spilling, and using a few extra registers when possible can help coalesce moves. Details-shmetails. The problem is that, prior to this commit, our register allocator was not well-behaved in certain circumstances, and would require an arbitrarily large number of registers. In particular, since different variables have different sizes and require contiguous allocation, in large programs the register file may become fragmented, causing the RA to use arbitrarily many registers despite having lots of registers free. The solution is vector live range splitting. First, we calculate the register pressure (the minimum number of registers that it is theoretically possible to allocate successfully), and round up to the maximum number of registers we will actually use (to give some wiggle room to coalesce moves). Then, we will treat this maximum as a *bound*, requiring that we don't use more registers than chosen. In the event that register file fragmentation prevents us from finding a contiguous sequence of registers to allocate a variable, rather than giving up or using registers we don't have, we shuffle the register file around (defragmenting it) to make room for the new variable. That lets us use a few moves to avoid sacrificing thread count or introducing spilling, which is usually a great choice. Android GLES3.1 shader-db results are as expected: some noise / small regressions for instruction count, but a bunch of shaders with improved thread count. The massive increase in register demand may seem weird, but this is the RA doing exactly what it's supposed to: using more registers if and only if they would not hurt thread count. Notice that no programs whatsoever are hurt for thread count, which is the salient part. total instructions in shared programs: 1781473 -> 1781574 (<.01%) instructions in affected programs: 276268 -> 276369 (0.04%) helped: 1074 HURT: 463 Inconclusive result (value mean confidence interval includes 0). total bytes in shared programs: 12196640 -> 12201670 (0.04%) bytes in affected programs: 1987322 -> 1992352 (0.25%) helped: 1060 HURT: 513 Bytes are HURT. total halfregs in shared programs: 488755 -> 529651 (8.37%) halfregs in affected programs: 295651 -> 336547 (13.83%) helped: 358 HURT: 9737 Halfregs are HURT. total threads in shared programs: 18875008 -> 18885440 (0.06%) threads in affected programs: 64576 -> 75008 (16.15%) helped: 82 HURT: 0 Threads are helped. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <!23832>
-
To 32-bit. This way we don't get into bad situations where we need to eg swap unaligned 64-bit values or something funny like that. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <!23832>
-
Including the new loop header? flag. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <!23832>
-
This is useful for deciding whether we need to fix up phis in RA. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <!23832>
-
This is Timur's cheesy solution to split-hell.shader_test. Seems to work ok here. Before: 94 inst, 588 bytes, 165 halfregs, 1 threads, 0 loops, 0:0 spills:fills After: 63 inst, 454 bytes, 129 halfregs, 1 threads, 0 loops, 0:0 spills:fills On Android GLES3.1 shader-db, a few shaders are helped a lot: total instructions in shared programs: 1781706 -> 1781473 (-0.01%) instructions in affected programs: 4284 -> 4051 (-5.44%) helped: 16 HURT: 2 Instructions are helped. total bytes in shared programs: 12197854 -> 12196640 (<.01%) bytes in affected programs: 29526 -> 28312 (-4.11%) helped: 20 HURT: 2 Bytes are helped. total halfregs in shared programs: 489007 -> 488755 (-0.05%) halfregs in affected programs: 945 -> 693 (-26.67%) helped: 7 HURT: 0 Halfregs are helped. total threads in shared programs: 18873216 -> 18875008 (<.01%) threads in affected programs: 5376 -> 7168 (33.33%) helped: 7 HURT: 0 Threads are helped. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <!23832>
-
It will be used for image writes too, not just reads. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <!23832>
-