Commits on Source (53)
-
Closes: #6348 cc: mesa-stable Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <!19534>
-
...to rra_validation_fail since it is used quite often. Shortening the name should improve readability. Part-of: <!19544>
-
Part-of: <!19544>
-
Node types can only be invalid for certain acceleration structure types. Part-of: <!19544>
-
Marek Olšák authored
si_determine_wave_size always returned 32 because shader->info was uninitialized. Do it after it's initialized. Reviewed-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!19477>
-
Marek Olšák authored
Reviewed-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!19477>
-
Marek Olšák authored
Fixes: ba02ed91 - ac/gfx11: fix the scratch buffer Reviewed-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!19477>
-
Marek Olšák authored
Reviewed-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!19477>
-
Marek Olšák authored
RGBX only loads and resolves 3 components, etc. v2: buf fixes to make AMD_TEST=computeblit pass Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> (v1) Part-of: <!19477>
-
Marek Olšák authored
Reviewed-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!19477>
-
Marek Olšák authored
Reviewed-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!19477>
-
Marek Olšák authored
Reviewed-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!19477>
-
Marek Olšák authored
This might start timing out in the CI. Reviewed-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!19477>
-
Marek Olšák authored
Reviewed-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <!19477>
-
Tomeu Vizoso authored
During the weekend they started to show network problems so often that they are unable to take on jobs. Part-of: <!19566>
-
Currently float16 to int64 conversions don't work correctly, because the "div" variable has an infinite value, since 2^32 isn't representable as a 16-bit float, which causes the result of of rem(x, div) to be NaN for all inputs, leading to an incorrect result. Since no values of magnitude greater than 2^32 are representable as a float16 we don't actually need to do the fdiv/frem operations, the conversion is equivalent to f2u32 with the result padded to 64 bits. Rework: * Jordan: Handle f16 in if/else rather than conditional Fixes: 936c58c8 ("nir: Extend nir_lower_int64() to support i2f/f2i lowering") Reviewed-by:
Jordan Justen <jordan.l.justen@intel.com> Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <!19391>
-
In some cases nir_lower_int64 will emit fp64 operations which aren't natively supported on any Intel hardware (e.g. ftrunc, frem). An extra pass of nir_opt_algebraic (for frem) and nir_lower_doubles is required in order to take care of them. This fixes several int64 test-cases on MTL hardware. Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Mykhailo Skorokhodov <mykhailo.skorokhodov@globallogic.com> Part-of: <!19390>
-
I got yet another new failure in VanGogh, and rather than playing the game of wack a mole, let's be a little less picky and just use these wildcards: - dEQP-VK.query_pool.statistics_query.geometry_shader_primitives.* - dEQP-VK.query_pool.statistics_query.host_query_reset.geometry_shader_primitives.* Signed-off-by:
Martin Roukala (né Peres) <martin.roukala@mupuf.org> Part-of: <!19541>
-
Add spec@egl 1.4@egl-ext_egl_image_storage,Fail to the list of RADV expectations. Fixes: 70ce1dca ("ci: Update piglit with s3 support") Signed-off-by:
Martin Roukala (né Peres) <martin.roukala@mupuf.org> Part-of: <!19555>
-
This new section didn't use the correct RST syntax, and ended up with a broken section in the rendered docs. Fix the syntax, and clean things up a bit to avoid overly long lines. Fixes: be235edf ("zink: add profile documentation") Part-of: <mesa/mesa!19481>
-
Anonymous links has some benefits in that it reduces the chance of warnings when similar identifiers are used. So let's use them instead when we can. Reviewed-by:
David Heidelberg <david.heidelberg@collabora.com> Part-of: <!19492>
-
We're in 2022 now, and HTTPS is available in a lot more places in the past. Let's upgrade some links, to protect the privacy of our readers. The links that are left either don't support HTTPS, or are simply dead and needs to be updated anyway. That's besides the scope of this merge-request, so I'm leaving that for someone else. Reviewed-by:
David Heidelberg <david.heidelberg@collabora.com> Part-of: <mesa/mesa!19492>
-
Samuel Pitoiset authored
The Vulkan spec says: "When a command buffer is allocated, it is in the initial state. Some commands are able to reset a command buffer (or a set of command buffers) back to this state from any of the executable, recording or invalid state. Command buffers in the initial state can only be moved to the recording state, or freed." Because the status wasn't initialized, it was implicitly set to RADV_CMD_BUFFER_STATUS_INVALID and that triggered a reset for newly allocated command buffers. Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Jason Ekstrand <jason.ekstrand@collabora.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <!19506>
-
These are only used for storage-compatible compressed surfaces on Broadwell and earlier and Stencil on Gfx7 where there isn't proper stencil sampling support. Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <!18402>
-
While the GC880 is HALTI0, it still uses the old set of state registers for PE pipe configuration. This is another specialty of the GC880, readd the missing handling for this GPU otherwise e.g. Qt5 cube example suffers from rendering corruption with both eglfs and wayland backends. Fixes: 7c46a488 ("etnaviv: use new PE pipe address states on >= HALTI0") Reviewed-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Marek Vasut <marex@denx.de> Part-of: <mesa/mesa!19562>
-
Meta operations change dynamic states like viewports and previously, the guardband state was also always re-emitted because it relied on dynamic viewport/scissor changes. Closes: mesa/mesa#7577 Fixes: 40d8df72 ("radv: emit the guardband state separately from the scissor state") Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <mesa/mesa!19521>
-
Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <!19164>
-
Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <!19164>
-
The hardware can detect binning transitions apparently, so it can be hardcoded. This matches RadeonSI and PAL. Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <!19164>
-
With dynamic color write mask and rasterization samples, the binning state will have to be re-computed dynamically. This shouldn't hurt anything right now because it's only done at pipeline bind time. Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <!19164>
-
XFB queries need to be enabled with NGG streamout and VS/TES. Previously, the NGG lowering code relied on has_prim_query for XFB. This fixes failures with RADV_PERFTEST=ngg_streamout on GFX10.3 with the vkd3d-proton testsuite. Vulkan CTS is missing TES tests with XFB queries apparently. Cc: 22.3 mesa-stable Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <mesa/mesa!19493>
-
Add dEQP-VK.memory.pipeline_barrier.host_read_host_write.1048576 to the list of flakes of navi21. Found after 80 runs. Signed-off-by:
Martin Roukala (né Peres) <martin.roukala@mupuf.org> Part-of: <!19569>
-
Forked off from v3d's. This gets us a render node which is good enough for shader-db. Signed-off-by:
Alyssa Rosenzweig <alyssa@collabora.com> Part-of: <!19540>
-
Explain how to build drm-shim and how to use it for shader-db. Signed-off-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <!19540>
-
Again sharing the same function across all Intel drivers. Reviewed-by:
Tapani Pälli <tapani.palli@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Part-of: <!19425>
-
All 4 drivers were fetching the same information, better do it on one place. Reviewed-by:
Tapani Pälli <tapani.palli@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Part-of: <!19425>
-
Iris, hasvk and anv were fetching the same information, better do it on one place. Reviewed-by:
Tapani Pälli <tapani.palli@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Part-of: <!19425>
-
Iris, hasvk and anv were fetching the same information, better do it on one place. Reviewed-by:
Tapani Pälli <tapani.palli@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Part-of: <!19425>
-
Reviewed-by:
Tapani Pälli <tapani.palli@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Part-of: <!19425>
-
This patch filters-out '-std=gnu++14' from the cflags obtained from AOSP/KATI dummy target output to avoid the following building errors: FAILED: src/gallium/drivers/r600/45f68e3@@r600@sta/sfn_sfn_assembler.cpp.o ... clang++ ... -std=c++17 ... -std=gnu++14 ... In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.cpp:27: In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.h:32: In file included from ../src/gallium/drivers/r600/sfn/sfn_shader.h:31: ../src/gallium/drivers/r600/sfn/sfn_instr.h:369:56: error: no template named 'is_base_of_v' in namespace 'std'; did you mean 'is_base_of'? template <typename T, typename = std::enable_if_t<std::is_base_of_v<Instr, T>>> ~~~~~^~~~~~~~~~~~ is_base_of /home/utente/pie-x86_kernel/external/libcxx/include/type_traits:1412:29: note: 'is_base_of' declared here struct _LIBCPP_TEMPLATE_VIS is_base_of ^ In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.cpp:27: In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.h:32: In file included from ../src/gallium/drivers/r600/sfn/sfn_shader.h:31: ../src/gallium/drivers/r600/sfn/sfn_instr.h:369:51: error: template argument for non-type template parameter must be an expression template <typename T, typename = std::enable_if_t<std::is_base_of_v<Instr, T>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/utente/pie-x86_kernel/external/libcxx/include/type_traits:439:16: note: template parameter is declared here template <bool _Bp, class _Tp = void> using enable_if_t = typename enable_if<_Bp, _Tp>::type; ^ 2 errors generated. Cc: "22.2" "22.3" mesa-stable Reviewed-by:
Roman Stratiienko <r.stratiienko@gmail.com> Part-of: <mesa/mesa!19563>
-
Dylan Baker authored
Part-of: <!19585>
-
Dylan Baker authored
Part-of: <mesa/mesa!19585>
-
Dylan Baker authored
Part-of: <!19585>
-
Signed-off-by:
Gert Wollny <gert.wollny@collabora.com> Part-of: <!19532>
-
Note: (u)int32 is broken on this hardware. Signed-off-by:
Gert Wollny <gert.wollny@collabora.com> Part-of: <!19532>
-
Currently in wglCreateContextAttribsARB(), we get and save the pointers to OPENGL32.DLL's wglCreate/DeleteContext() functions. But these function pointers might be invalid after opengl32.dll is unloaded and reloaded again and possibly in a different address space. This patch, provided by Jose Fonseca, uses GetModuleHandle and gets the proc address of wglCreate/DeleteContext functions every time the function is called. Reviewed-by:
Jesse Natalie <jenatali@microsoft.com> Part-of: <!19478>
-
Don't copy propagate the constant in situations like mov(8) g8<1>D 0x7fffffffD mul(8) g16<1>D g8<8,8,1>D g15<16,8,2>W On platforms that only have a 32x16 multiplier, this will result in lowering the multiply to mul(8) g15<1>D g14<8,8,1>D 0xffffUW mul(8) g16<1>D g14<8,8,1>D 0x7fffUW add(8) g15.1<2>UW g15.1<16,8,2>UW g16<16,8,2>UW On Gfx8 and Gfx9, which have the full 32x32 multiplier, it results in mul(8) g16<1>D g15<16,8,2>W 0x7fffffffD Volume 2a of the Skylake PRM says: When multiplying a DW and any lower precision integer, the DW operand must on src0. See also mesa/crucible!104 . Previous to INTEL_shader_integer_functions2 (in Vulkan or OpenGL), I don't think it would be possible to create a situation where this could occur. I discovered this via some optimizations that can determine that the non-constant source must be able to fit in 16-bits. The case listed above came from piglit's "ext_transform_feedback-order arrays points" with those optimizations in place. No shader-db or fossil-db changes on any Intel platform. Fixes: de6c0f84 ("intel/fs: Implement support for NIR opcodes for INTEL_shader_integer_functions2") Reviewed-by:
Caio Oliveira <caio.oliveira@intel.com> Part-of: <mesa/mesa!17718>
-
The previous bounds checking would cause mul(8) g121<1>D g120<8,8,1>D 0xec4dD to be lowered to mul(8) g121<1>D g120<8,8,1>D 0xec4dUW mul(8) g41<1>D g120<8,8,1>D 0x0000UW add(8) g121.1<2>UW g121.1<16,8,2>UW g41<16,8,2>UW Instead of picking the bounds (and the new type) based on the old type, pick the new type based on the value only. This helps a few fossil-db shaders in Witcher 3 and Geekbench5. No changes on any other Intel platforms. Tiger Lake Instructions in all programs: 157581069 -> 157580768 (-0.0%) Instructions helped: 24 Cycles in all programs: 7566979620 -> 7566977172 (-0.0%) Cycles helped: 22 Cycles hurt: 4 Ice Lake Instructions in all programs: 141998965 -> 141998667 (-0.0%) Instructions helped: 26 Cycles in all programs: 9162568666 -> 9162565297 (-0.0%) Cycles helped: 24 Cycles hurt: 2 Skylake No changes. Reviewed-by:
Caio Oliveira <caio.oliveira@intel.com> Part-of: <!17718>
-
This enables copy propagation of mov(8) g5<1>UD 0x00000180UD mul(8) g10<1>D g2.3<0,1,0>D g5<16,8,2>W into mul(8) g10<1>D g2.3<0,1,0>D 180W This is necessary for any optimization passes that generate imul_32x16 instructions. No fossil-db or shader-db changes on any Intel platform. v2: Fix type size check to (src size != 2) || (dest size != 4). It was previously &&. :( This allowed copying constants into UB sources, and that is invalid. v3: Fix incorrect extraction of upper 16-bits of immediate value when subnr=2. Noticed by Caio. Reviewed-by:
Caio Oliveira <caio.oliveira@intel.com> Part-of: <!17718>
-
Gfx8 and Gfx9 platforms are helped for cycles because now many instructions like mul(8) g12<1>D g10<8,8,1>D 6D become mul(8) g12<1>D g10<8,8,1>D 6W It is the same number of instructions, but the 32x16 multiply is a little faster. v2: Fix transposed hi and lo in "(hi >= INT16_MIN && lo <= INT16_MAX)". Noticed by Caio. Use nir_src_is_const instead of open coding it. Suggested by Caio. Broadwell and Skylake had similar results. (Skylake shown) total cycles in shared programs: 845748380 -> 845145547 (-0.07%) cycles in affected programs: 446346348 -> 445743515 (-0.14%) helped: 6017 HURT: 0 helped stats (abs) min: 2 max: 7380 x̄: 100.19 x̃: 8 helped stats (rel) min: <.01% max: 3.72% x̄: 0.41% x̃: 0.39% 95% mean confidence interval for cycles value: -113.37 -87.00 95% mean confidence interval for cycles %-change: -0.42% -0.41% Cycles are helped. Skylake Cycles in all programs: 8844820715 -> 8828897462 (-0.2%) Cycles helped: 47914 Cycles hurt: 1 No shader-db or fossil-db changes on any other Intel platform. Reviewed-by:
Caio Oliveira <caio.oliveira@intel.com> Part-of: <!17718>
-
Only iabs and ineg are treated specially. Everything else just uses nir_unsigned_upper_bound. The special treatment of source modifiers is because they cause problems for nir_unsigned_upper_bound. Once those are peeled off, nir_unsigned_upper_bound can generally produce a tighter bound. Future commits will add more opcodes. This mostly introduces the basic framework. v2: Add a bunch of comments to signed_integer_range_analysis. Re-arrange the code a little to reduce duplication. Both suggested by Caio. Rearrange some logic to simplify things. Suggested by Marcin. Tiger Lake, Ice Lake, Haswell, and Ivy Bridge had similar results. (Ice Lake shown) total instructions in shared programs: 19912894 -> 19912558 (<.01%) instructions in affected programs: 109275 -> 108939 (-0.31%) helped: 74 / HURT: 0 total cycles in shared programs: 856422769 -> 856413218 (<.01%) cycles in affected programs: 15268102 -> 15258551 (-0.06%) helped: 65 / HURT: 4 total fills in shared programs: 8218 -> 8217 (-0.01%) fills in affected programs: 1171 -> 1170 (-0.09%) helped: 1 / HURT: 0 Skylake and Broadwell had similar results. (Skylake shown) total cycles in shared programs: 845145547 -> 845142263 (<.01%) cycles in affected programs: 15261465 -> 15258181 (-0.02%) helped: 65 / HURT: 0 Tiger Lake Tiger Lake Instructions in all programs: 157580768 -> 157579730 (-0.0%) Instructions helped: 312 Instructions hurt: 28 Cycles in all programs: 7566977172 -> 7566967746 (-0.0%) Cycles helped: 288 Cycles hurt: 53 Spills in all programs: 19701 -> 19700 (-0.0%) Spills helped: 2 Spills hurt: 4 Fills in all programs: 33311 -> 33335 (+0.1%) Fills helped: 5 Fills hurt: 4 Ice Lake Instructions in all programs: 141998667 -> 141997227 (-0.0%) Instructions helped: 420 Instructions hurt: 3 Cycles in all programs: 9162565297 -> 9162524757 (-0.0%) Cycles helped: 389 Cycles hurt: 29 Spills in all programs: 19918 -> 19916 (-0.0%) Spills helped: 2 Spills hurt: 3 Fills in all programs: 32795 -> 32814 (+0.1%) Fills helped: 6 Fills hurt: 3 Skylake Instructions in all programs: 132567691 -> 132567745 (+0.0%) Instructions hurt: 24 Cycles in all programs: 8828897462 -> 8828889517 (-0.0%) Cycles helped: 405 Cycles hurt: 6 Reviewed-by:
Caio Oliveira <caio.oliveira@intel.com> Part-of: <!17718>
-
This is especially helpful for a*isign(a) generated by idiv_by_const optimization. On many GPUs, isign(a) is lowered to imax(imin(a, 1), -1). There are no changes on fossil-db because ANV uses a different optimization path for idiv with a constant denominator. A future MR will change this. NOTE: This commit used to help a few hundred shader-db shaders, but now none are affected. I suspect this is due to some change in the idiv_by_const optimization. This could possibly be dropped. Reviewed-by:
Caio Oliveira <caio.oliveira@intel.com> Part-of: <!17718>
-
Many Intel platforms can only perform 32x16 bit multiplication. The straightforward way to implement 32x32 bit multiplications is by splitting one of the operands into high and low parts called H and L, repsectively. The full multiplication can be implemented as: ((A * H) << 16) + (A * L) On Intel platforms, special register accesses can be used to eliminate the shift operation. This results in three instructions and a temporary register for most values. If H or L is 1, then one (or both) of the multiplications will later be eliminated. On some platforms it may be possible to eliminate the multiplication when H is 256. If L is zero (note that H cannot be zero), one of the multiplications will also be eliminated. Instead of splitting the operand into high and low parts, it may possible to factor the operand into two 16-bit factors X and Y. The original multiplication can be replaced with (A * (X * Y)) = ((A * X) * Y). This requires two instructions without a temporary register. I may have gone a bit overboard with optimizing the factorization routine. It was a fun brainteaser, and I couldn't put it down. :) On my 1.3GHz Ice Lake, a standalone test could chug through 1,000,000 randomly selected values in about 5.7 seconds. This is about 9x the performance of the obvious, straightforward implementation that I started with. v2: Drop an unnecessary return. Rearrange logic slightly and rename variables in factor_uint32 to better match the names used in the large comment. Both suggested by Caio. Rearrange logic to avoid possibly using `a` uninitialized. Noticed by Marcin. v3: Use DIV_ROUND_UP instead of open coding it. Noticed by Caio. Tiger Lake, Ice Lake, Haswell, and Ivy Bridge had similar results. (Ice Lake shown) total instructions in shared programs: 19912558 -> 19912526 (<.01%) instructions in affected programs: 3432 -> 3400 (-0.93%) helped: 10 / HURT: 0 total cycles in shared programs: 856413218 -> 856412810 (<.01%) cycles in affected programs: 122032 -> 121624 (-0.33%) helped: 9 / HURT: 0 No shader-db changes on any other Intel platforms. Tiger Lake and Ice Lake had similar results. (Ice Lake shown) Instructions in all programs: 141997227 -> 141996923 (-0.0%) Instructions helped: 71 Cycles in all programs: 9162524757 -> 9162523886 (-0.0%) Cycles helped: 63 Cycles hurt: 5 No fossil-db changes on any other Intel platforms. Reviewed-by:
Caio Oliveira <caio.oliveira@intel.com> Part-of: <!17718>
Showing
- android/mesa3d_cross.mk 1 addition, 1 deletionandroid/mesa3d_cross.mk
- docs/amber.rst 1 addition, 1 deletiondocs/amber.rst
- docs/ci/LAVA.rst 1 addition, 1 deletiondocs/ci/LAVA.rst
- docs/ci/docker.rst 2 additions, 2 deletionsdocs/ci/docker.rst
- docs/ci/index.rst 2 additions, 2 deletionsdocs/ci/index.rst
- docs/ci/local-traces.rst 5 additions, 5 deletionsdocs/ci/local-traces.rst
- docs/ci/skqp.rst 2 additions, 2 deletionsdocs/ci/skqp.rst
- docs/codingstyle.rst 1 addition, 1 deletiondocs/codingstyle.rst
- docs/drivers/asahi.rst 21 additions, 0 deletionsdocs/drivers/asahi.rst
- docs/drivers/freedreno/ir3-notes.rst 1 addition, 1 deletiondocs/drivers/freedreno/ir3-notes.rst
- docs/drivers/lima.rst 1 addition, 1 deletiondocs/drivers/lima.rst
- docs/drivers/llvmpipe.rst 7 additions, 7 deletionsdocs/drivers/llvmpipe.rst
- docs/drivers/radv.rst 2 additions, 2 deletionsdocs/drivers/radv.rst
- docs/drivers/zink.rst 8 additions, 9 deletionsdocs/drivers/zink.rst
- docs/faq.rst 6 additions, 6 deletionsdocs/faq.rst
- docs/gallium-nine.rst 5 additions, 5 deletionsdocs/gallium-nine.rst
- docs/gallium/cso/rasterizer.rst 2 additions, 2 deletionsdocs/gallium/cso/rasterizer.rst
- docs/gallium/format.rst 1 addition, 1 deletiondocs/gallium/format.rst
- docs/gallium/tgsi.rst 1 addition, 1 deletiondocs/gallium/tgsi.rst
- docs/install.rst 2 additions, 2 deletionsdocs/install.rst