Function vn_fix_graphics_pipeline_create_infos() had two interleaved
phases: discovery of needed fixes, and application of those fixes.
Move the discovery phase into new function
vn_find_graphics_pipeline_create_info_fixes(). The two-phase approach
will be simplify the implementation of VK_EXT_graphics_pipeline_library.
No intended change in behavior.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
Use a more consistent naming scheme for everything. Follow-up patches
will implement VK_EXT_graphics_pipeline_library, which will make the
code significantly more complex, in which better names will make the
code more readable.
Except for replacing `any_fix` with `erase.mask`, this patch does modify
any procedural code. It merely renames structs and fields.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
When writing vn_fix_graphics_pipeline_create_info() long ago, I defined
some always-true dummy vars that represented some
VkGraphicsPipelineLibraryFlagsEXT. In the conditions that decide which
state to fixup, I used the dummy vars.
My intent was that this would ease the implementation of
VK_EXT_graphics_pipeline_library, because some of the GPL fixup logic
would already be present. I was wrong. After I studied GPL more,
I discovered that the conditions were using the dummy vars incorrectly.
The incorrect usage produced no bugs, because the vars are always true.
Delete the dummy vars.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
> Use of a presentable image must: occur only after the image is returned by flink:vkAcquireNextImageKHR, and before it is released by flink:vkQueuePresentKHR.
> This includes transitioning the image layout and rendering commands.
fixes#10005
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25787>
The following instructions :
- 3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP
- 3DSTATE_VIEWPORT_STATE_POINTERS_CC
- 3DSTATE_SCISSOR_STATE_POINTERS
do not care about the content/format/count of the render targets, only
the size of the render area and count of viewport/scissor.
By tracking render targets & render area we can reduce the emission of
those instructions.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25778>
VK_ATTACHMENT_STORE_OP_NONE_EXT is already supported via VK_KHR_dynamic_rendering, logic dictates it shouldn't need much else for VK_ATTACHMENT_LOAD_OP_NONE_EXT.
CTS is passing with the following results on dEQP-VK.renderpass*.load_store_op_none.* tests
Test run totals:
Passed: 78/110 (70.9%)
Failed: 0/110 (0.0%)
Not supported: 32/110 (29.1%)
Warnings: 0/110 (0.0%)
Waived: 0/110 (0.0%)
Requires !24596 to achieve parity with proprietary driver
Closes#9638
Signed-off-by: Sid Pranjale <sidpranjale127@protonmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25771>
gcc is able to optimize away either the modulo or the logical and. This
makes no difference to gcc.
clang is only able to optimize away the logical and. This allows clang
to generate faster code for BITFIELD_MASK.
As for BITFIELD64_MASK, this also makes no difference to clang except it
fixes a compile error for BITFIELD64_MASK(64):
error: shift count >= width of type [-Werror,-Wshift-count-overflow]
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9989
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25757>
This is for GLSL versions where Infs are undefined.
It also helps piglit/glsl-fs-fogscale that breaks when we move the fragment
shader code into the vertex shader across interpolation.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Acked-by: Jesse Natalie on IRC
Acked-by: Erico Nunes on Gitlab
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25391>
Replaced by the new NIR pass.
i915g results:
total instructions in shared programs: 510678 -> 510714 (<.01%)
total temps in shared programs: 30429 -> 30426 (<.01%)
rv370 results:
total instructions in shared programs: 737649 -> 737656 (<.01%)
instructions in affected programs: 82 -> 89 (8.54%)
total temps in shared programs: 112093 -> 112094 (<.01%)
temps in affected programs: 6 -> 7 (16.67%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24763>
i915g and r300-r400 don't have if statements, and discards are all
nir_intrinsic_discard_if. We can flatten those discards here, saving a
separate GLSL pass to try to do so.
i915g:
GAINED: shaders/closed/xcom-enemy-unknown/413.shader_test FS
rv370:
GAINED: shaders/closed/xcom-enemy-unknown/12.shader_test FS
GAINED: shaders/closed/xcom-enemy-unknown/122.shader_test FS
GAINED: shaders/closed/xcom-enemy-unknown/132.shader_test FS
GAINED: shaders/closed/xcom-enemy-unknown/145.shader_test FS
GAINED: shaders/closed/xcom-enemy-unknown/146.shader_test FS
GAINED: shaders/closed/xcom-enemy-unknown/19.shader_test FS
GAINED: shaders/closed/xcom-enemy-unknown/413.shader_test FS
GAINED: shaders/closed/xcom-enemy-unknown/415.shader_test FS
Closes: #9918
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24763>
in cases where apps (stupidly) do swapbuffers->blitframebuffer, there's
no functional way to (legitimately) perform readback on the just-presented
vk image, which leads to the existing acquire+present loop dance
this adds a counter threshold which, when exceeded, begins copying the
scanout image for swapchains to provide local readback on images without
the massive perf penalty of roundtrips
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25754>
Mike Blumenkrantz