debian-testing is the critical path: the shortest possible job to build
exactly what we need to execute on hardware, and nothing else.
debian-build-testing exists to give us better coverage at the expense of
running longer.
Since the only jobs using r300 and Nine, and the only jobs using NVK,
are in post-merge stages which are manually triggered, move these builds
to debian-build-testing. This makes the critical path to those a little
longer, but we do get to make it shorter for everyone else just running
regular Marge jobs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <None>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33287>
I stumbled on this limit - it turns out that large local_sizes apply an
additonal limit on gprs per thread. If we violate this limit, then dmesg
just gives us a rather unhelpful message that the channel is killed:
nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:64 type:13 scope:1 part:233
nouveau 0000:01:00.0: fifo:c00000:0008:0040:[hw_tests::test_[14761]] errored - disabling channel
Cc: mesa-stable
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32952>
"constant" is a special keyword in OpenCL C, and we'd like to #define it
suitably in host C23 to facilitate compatiblity between host/device headers.
That means we can't have any identifiers named "global" or "constant".
Fortunately, this is the only 'constant' in any file I'm hitting.
To avoid the clash, don't abbreviate "constant factor", use "constant_factor"
instead. For consistency, "slope factor" then becomes "slope_factor".
The new names are longer but match the Vulkan API exactly.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> [Intel]
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com> [NVK and panvk]
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com> [V3DV]
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com> [IMG]
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32505>
This is a prerequisite for enabling nir_opt_varyings for all gallium
drivers.
nir_lower_io_passes (called by the GLSL linker) only uses NIR options
to lower indirect IO access before lowering IO and calling
nir_opt_varyings.
Most drivers report full support for indirect IO and lower it themselves,
which prevents compaction of lowered indirectly accessed varyings because
nir_opt_varyings doesn't touch indirect varyings.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> (Rb for asahi)
Reviewed-by: Pavel Ondračka <pavel.ondracka@gmail.com> (for r300)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32423>
ANB implementation aims to rely as much as possible on 'ANB common' code in vulkan/runtime
and vk_common_* entry points automatically handled by mesa at build time.
(v1) Initial Vulkan HAL skeleton with vk_android_{init,destroy}_ugralloc() in nvk_open_hal()
Changelog:
nvk_android.{c,h}: skeleton nvk_open_hal()/nvk_close_hal() and meson.build changes
nvk_instance.h: nvk_*() functions declaration required by nvk_android.c
nvk_device.c: add ANB support
nvk_image.c: add ANB code paths
nvk_physical_device.c: enable ANB extension support
NOTE: Avoid including any AHB code/headers <vndk/hardware_buffer.h>
use only <vulkan/vk_android_native_buffer.h>
Achievements:
Vulkan HAL is detected by Android build, but no Vulkan application is rendering
Android libvulkan.so loader performs dlopen() of /vendor/lib64/hw/vulkan.nouveau.so
Sascha Willems vulkanCapsViewer App detects the Vulkan HAL in Android builds on RTX2060
Android CTS 11 dEQP-VK can be run and completed, but com.drawelements.deqp app shows black surface
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568738 161 568899
(v2) Further replication of other using 'ANB common' implementation
Changelog:
Move vk_android_{init,destroy}_ugralloc() from nvk_open_hal() to nvk_CreateInstance()
Remove nvk_GetPhysicalDeviceProperties2() and rely on vk_common_GetPhysicalDeviceProperties2()
Achievements:
Improvements in dEQP-VK test results, but many dEQP.wsi.android.* tests are still failing
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568783 115 568899
(v3) Get inspiration from lavapipe recent llvmpipe ANB implementation and cleanups
nvk_physical_device.c: brace nvk_init_wsi,nvk_finish_wsi with #ifdef NVK_USE_WSI_PLATFORM/#endif
nvk_image.c: if (!mem) return VK_SUCCESS in DETECT_OS_ANDROID path
nvk_android.h: remove nvk_ahb_format_for_vk_format() and add vk_format_from_android()
Achievements:
Improvement in dEQP.wsi.android.* test results, only dEQP.wsi.android.swapchain.simulae_oom.* are failing.
Most of Vulkan Apps generate these errors in logcat:
... E BufferQueueConsumer: [tech.incr.vulkanandroid/tech.incr.vulkanandroid.MinimalNativeActivity#0](id:85900000010,api:1,p:5060,c:2137) acquireBuffer: max acquired buffer count reached: 2 (max 1)
... E BufferLayerConsumer: [tech.incr.vulkanandroid/tech.incr.vulkanandroid.MinimalNativeActivity#0] updateTexImage: acquire failed: Function not implemented (-38)
while some other apps (vkCube and GearsVK) generate these errors:
... E RenderEngine: failed to wait on fence fd
... E Layer : [Surface(name=Task=136)/@0x832783c - animation-leash#0] No local sync point found
... E Layer : [Surface(name=Task=1)/@0xd82067 - animation-leash#0] No local sync point found
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568820 79 568899
(v4) Vulkan HAL implement nvk specific ANB gralloc and synchronization, inspired by llvmpipe ANB
Changelog:
nvk_android.c: nvk_GetSwapchainGrallocUsageANDROID, nvk_AcquireImageANDROID, nvk_QueueSignalReleaseImageANDROID
implemented as porting of llvmpipe commit 0dce939e with 's/lvp_/nvk_/g' for functions rename
NOTE: at this stage nvk_GetSwapchainGrallocUsageANDROID is only setting gralloc SW usage flags
nvk_image.h: NVK_MAX_PLANE_COUNT 1 - NOTE: I don' know how many max planes are supported by NVK
Achievements:
GearsVK working
dEQP-VK tests produce colored output on screen
3DMARK API Overhead, Slingshot Extreme: running but meshes are not rendered
Other Vulkan API enabled Android Apps (Sascha Willems vulkanTriangle) are showing black surface,
which is due to basic gralloc SW usage flags implemented in nvk_GetSwapchainGrallocUsageANDROID()
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568820 79 568899
The failed tests are in the following modules/test:
dEQP-VK.api.driver_properties#driver_id_match 1
dEQP-VK.pipeline.multisample.min_sample_shading_enabled.* 9
dEQP-VK.pipeline.multisample.min_sample_shading.* 56
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32i#256_256_6 1
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32ui#256_256_6 1
dEQP-VK.ssbo.layout.random.all_shared_buffer#5 1
dEQP-VK.wsi.android.swapchain.simulate_oom 10
(v5) use ANB common code for GetSwapchainGrallocUsage*ANDROID
Changelog:
Replace the "SW usage only" nvk_GetSwapchainGrallocUsage{,2}ANDROID
and rely on vk_common_GetSwapchainGrallocUsage{,2}ANDROID
Achievements:
Vulkan Apps are rendering on screen
Tested on Android 11 with Vulkan 1.1 API
Android apps working:
Khronos Vulkan-Samples
Sacha Willems Vulkan Examples
Vulkan Android Test
vkCube
GearsVK
PPSSPP
3DMARK API Overhead, Slingshot Extreme - Still with meshes issue
dEQP Test Results:
Module Passed Failed Total
dEQP-VK 568820 79 568899
The failed tests are in the following modules/test (same as per previous iteration):
dEQP-VK.api.driver_properties#driver_id_match 1
dEQP-VK.pipeline.multisample.min_sample_shading_enabled.* 9
dEQP-VK.pipeline.multisample.min_sample_shading.* 56
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32i#256_256_6 1
dEQP-VK.sparse_resources.image_sparse_binding.cube_array.rgba32ui#256_256_6 1
dEQP-VK.ssbo.layout.random.all_shared_buffer#5 1
dEQP-VK.wsi.android.swapchain.simulate_oom# 10
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30833>
Required to compile nvk for android
Fixes the following building error:
FAILED: src/nouveau/compiler/nak_bindings.rs
...
/usr/include/xf86drm.h:40:10: fatal error: 'drm.h' file not found
panicked at 'Unable to generate bindings: ClangDiagnostic("/usr/include/xf86drm.h:40:10:
fatal error: 'drm.h' file not found\n")', main.rs:52:36
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30833>
