- 02 Jul, 2022 9 commits
-
-
Karol Herbst authoredSigned-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
-
Karol Herbst authored
For OpenCL kernels we simply link together SPIR-V files, so the only case where we are left with linking shaders together is libclc and we handle that just fine. Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: -
Karol Herbst authored
Most call nir_shader_get_entrypoint already and in Rust we can't really use nir_shader_get_entrypoint directly unless we make it a proper function Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: -
Karol Herbst authored
Clang unconditionally adds those definitions if using a spirv LLVM target. That's not a problem on its own, but clang's internal OpenCL header enable a bunch of OpenCL extensions if those are set. Lucky for us, we can simply undefine them and spare us the trouble of finding an upstream solution to this problem :) This fixes the OpenCL CTS' compiler features_macro test. Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: -
Karol Herbst authored
Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: -
Karol Herbst authored
Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: -
Karol Herbst authored
Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: -
Karol Herbst authored
Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: -
Karol Herbst authored
Also make the code cleaner and simplier. Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Acked-by:
-
- 29 Jun, 2022 31 commits
-
-
It is not needed anymore. Signed-off-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by:
-
Fixes the following compiler warning: svga_pipe_query.c:1295:17: warning: 'result.u64' may be used uninitialized [-Werror=maybe-uninitialized] Signed-off-by:
-
Signed-off-by:
Gert Wollny <gert.wollny@collabora.com> Reviewed-by:
-
This is a cherry-pick from upstream - 4679637f ("Fix warning maybe-uninitialized"). Signed-off-by: -
Now that we have a common pipeline layout with reference counting, we don't need these driver hooks for reference counting anymore. Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Part-of: <!17286>
-
Reviewed-by:
-
Reviewed-by:
-
Reviewed-by:
-
Reviewed-by:
-
Reviewed-by:
Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <!17286> -
Reviewed-by:
Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <!17286> -
Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: -
There's some tricky stuff in here with properly handling Vulkan allocation scopes and reference counting. Probably best to do it once. Also, this means that common code can now take references to descriptor set layouts which seems useful. Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: -
Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: -
``` xmlconfig.c:570:7: warning: 'userData.name' may be used uninitialized [-Wmaybe-uninitialized] ``` Reviewed-by:
-
Boris Brezillon authored
Reviewed-by:
-
Boris Brezillon authored
We're lacking parens, as reported by clang. Reviewed-by:
-
Boris Brezillon authored
Reviewed-by:
-
Boris Brezillon authored
Reviewed-by:
-
Boris Brezillon authored
Reviewed-by:
-
Boris Brezillon authored
D3D12 wants Width, Height and Depth to be aligned on the block width, height and depth size. But Vulkan allows the width, height or depth to be unaligned at the image boundary if image.{width,height,depth} is not aligned. Let's explicitly align things in the copy paths. Reviewed-by: -
Boris Brezillon authored
D3D12_RESOURCE_STATE_DEPTH_READ only provides access for fixed-function depth/stencil test. If we want the shaders to be able to read the depth/stencil attachment, we need to combine D3D12_RESOURCE_STATE_DEPTH_READ and D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE. Reviewed-by:
-
Boris Brezillon authored
Sometimes there's no obvious mappings between a VkImageLayout and a D3D12_RESOURCE_STATE, so let's just provide a helper that takes before/after resource states instead of old/new layouts, and use it to fix the resolve case. Fixes: 35356b11 ("dzn: Cache and pack transition barriers") Reviewed-by:
-
Boris Brezillon authored
We are about to introduce the same function taking D3D12_RESOURCE_STATES arguments instead of VkImageLayout ones. Let's rename the function accordingly. Reviewed-by:
-
Boris Brezillon authored
We want to pack ResourceBarriers() call as much as we can, so let's not dzn_cmd_buffer_queue_transition_barriers() when we could still queue new barriers. Reviewed-by:
-
Juan A. Suárez authored
This test works when executed alone, but fails when running the full GLES3 CTS. Signed-off-by:
Juan A. Suarez Romero <jasuarez@igalia.com> Part-of: <!17300>
-
Some Vulkan -> D3D12 API mismatches force us to do behind-the-scene transitions to get resources in the right state when executing non-native operations. In this case, caching the transition until the resource is actually used might save us unneeded transitions. The packing aspect is mostly useful to limit the ExecuteBarriers() call overhead. Right now we do per-resource packing, and any hole in the subresource range will trigger several ExecuteBarriers() calls. This can be improved by collecting barriers in a separate array, and flushing the collected transition barriers just before executing the operation using the subresources pointed by those barriers. While not impossible, it'd be more verbose than what we have right now, so I'm not entirely convinced it's worth it. Caching could be improved to avoid any unnecessary flush when we do blit or copy operations and transition the resources back to their original state, since the user might decide to transition the image to a new layout just after that. But doing that would require keeping track of all resources used by dispatch/draw operations, which in turn implies keeping info about which of the descriptor set resources are used by the graphics/compute pipelines. Not sure the it's worth the extra complexity given D3D12 enhanced barriers are just around the corner, and those map pretty nicely to the vulkan barrier+image-layout model. Reviewed-by:
-
Fixes: 4b5f0d98 ("tu: Overhaul LRZ, implement on-GPU dir tracking and LRZ fast-clear") Signed-off-by:
Hyunjun Ko <zzoon@igalia.com>
Part-of: <!17289> -
v2: Keep VkPhysicalDeviceBufferDeviceAddressFeaturesEXT (Jason) Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: 
Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <!17272> -
24be0119 ("lima: wire up MSAA 4x support") switched to aligning all the buffers to tile size and it resulted in allocating 16x more memory for index, vertex and constant buffers. We only want to align textures and render targets to tile size, not other buffers, so restore old logic, but relax it. Fixes: 24be0119 ("lima: wire up MSAA 4x support") Acked-By:
Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by:
Erico Nunes <nunes.erico@gmail.com> Part-of: <!17283>
-
They aren't supported and lead to GPU hangs. Reported-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Part-of: <!17256>
-
