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>
In order to return correct offsets, strides and possibly other
parameters. This is relevant for formats like NV12 and P010 where
the second plane, when produced by the Intel VAAPI decoder, uses the
same FD like the first one, but with an offset.
Right now there are only two modifiers with well defined indices
of auxiliary planes for semi-planar formats according to the local
copy of drm_fourcc.h, `I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS` and
`I915_FORMAT_MOD_4_TILED_MTL_MC_CCS`, sharing the same layout.
Assume that future `MC_CCS` modifiers will get defined accordingly
for now.
Cc: mesa-stable
Tested-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9952
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25603>
Things have been working by accident for split display/render SoCs when
using the GBM platform.
The device fd given to the GBM platform may be associated with a
KMS-only device, so _eglFindDevice() should find nothing (because the
global EGLDevice list only has render-capable devices). The only thing
making it work is that we don't error out when we go through the
EGLDevice list and can't find the device we are looking for. We simply
return the last EGLDevice from the list.
This patch fixes that. Now we look for a compatible render-only device
for the KMS-only in the GBM platform.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
