- Jan 15, 2020
-
-
Erico Nunes authored
The existing liveness analysis in ppir still ultimately relies on a single continuous live_in and live_out range per register and was observed to be the bottleneck for register allocation on complicated examples with several control flow blocks. The use of live_in and live_out ranges was fine before ppir got control flow, but now it ends up creating unnecessary interferences as live_in and live_out ranges may span across entire blocks after blocks get placed sequentially. This new liveness analysis implementation generates a set of live variables at each program point; before and after each instruction and beginning and end of each block. This is a global analysis and propagates the sets of live registers across blocks independently of their sequence. The resulting sets optimally represent all variables that cannot share a register at each program point, so can be directly translated as interferences to the register allocator. Special care has to be taken with non-ssa registers. In order to properly define their live range, their alive components also need to be tracked. Therefore ppir can't use simple bitsets to keep track of live registers. The algorithm uses an auxiliary set data structure to keep track of the live registers. The initial implementation used only trivial arrays, however regalloc execution time was then prohibitive (>1minute on Cortex-A53) on extreme benchmarks with hundreds of instructions, hundreds of registers and several spilling iterations, mostly due to the n^2 complexity to generate the interferences from the live sets. Since the live registers set are only a very sparse subset of all registers at each instruction, iterating only over this subset allows it to run very fast again (a couple of seconds for the same benchmark). Signed-off-by:
Erico Nunes <nunes.erico@gmail.com> Reviewed-by:
Vasily Khoruzhick <anarsoul@gmail.com> Tested-by: Marge Bot <mesa/mesa!3358> Part-of: <mesa/mesa!3358>
-
Erico Nunes authored
There are some cases in shades using control flow where the varying load is cloned to every block, and then the original node is left orphan. This is not harmful for program execution, but it complicates analysis for register allocation as there is now a case of writing to a register that is never read. While ppir doesn't have a dead code elimination pass for its own optimizations and it is not hard to detect when we cloned the last load, let's remove it early. Signed-off-by:
-
Kristian Høgsberg authored
Signed-off-by:
Kristian H. Kristensen <hoegsberg@google.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> -
Kristian Høgsberg authored
Enables EGL_ANDROID_native_fence_sync. Reviewed-by:Kenneth Graunke <kenneth@whitecape.org> -
After flushing batches, iris_fence_flush() asks the kernel whether each batch's last_syncpt has already signalled or not. (The idea is that either the compute or render batch may not have actually had any work queued up, so last_syncpt there might have been signalled a long time ago.) If it's already completed, we don't bother to record it. A strange corner is the case of repeated flushes. For example, we might flush for some reason, and hit a glFlush(), and hit SwapBuffers. It's possible for all the batches to have been flushed previously, -and- for them to have actually completed. In this case, we'll see that there are no syncobj's to wait on, and record fence->count == 0. This works fine internally - fence_finish can see count == 0 and realize that it doesn't need to wait, for example. But when working with native FDs, we may be asked to export a fence with count == 0. So we need an actual synchronization primitive we can hand off. Because all of the relevant batches had been signalled when creating the fence, we want the new dummy fence to be signalled as well. So we just make a signalled syncobj and export it. Reviewed-by: -
Robert Foss authored
Signed-off-by:
Robert Foss <robert.foss@collabora.com> Reviewed-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
-
Robert Foss authored
Currently the schedule_program implementation being used is picked at compile time, which on the Android platform means that the bifrost compiler & scheduler is used for all targets, including midgard based hardware. This commit disambiguates between the two schedule_program functions. Signed-off-by:
-
Marek Olšák authored
Reviewed-by:
Timothy Arceri <tarceri@itsqueeze.com> Tested-by: Marge Bot <mesa/mesa!3399> Part-of: <mesa/mesa!3399>
-
Marek Olšák authored
Reviewed-by:
-
Marek Olšák authored
Reviewed-by:
-
Marek Olšák authored
Reviewed-by:
-
Marek Olšák authored
Reviewed-by:
-
Marek Olšák authored
Reviewed-by:
-
Marek Olšák authored
Reviewed-by:
-
Marek Olšák authored
Cc: 19.2 19.3 <mesa-stable@lists.freedesktop.org> Acked-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Tested-by: Marge Bot <mesa/mesa!3338> Part-of: <mesa/mesa!3338>
-
Marek Olšák authored
Fixes: 3b143369 "ac/nir, radv, radeonsi: Switch to using ac_shader_args" Acked-by:
-
Marek Olšák authored
Reviewed-by: -
Marek Olšák authored
Reviewed-by: -
Marek Olšák authored
Reviewed-by: -
Marek Olšák authored
Reviewed-by: -
Marek Olšák authored
It could be NULL. Reviewed-by: -
Marek Olšák authored
Reviewed-by: -
Kenneth Graunke authored
get_nir_image_intrinsic_image() was incorrectly mutating the value held by the register which holds the intrinsic's first source (image index). If this happened to be the register for an SSA def which is also used elsewhere in the program, this meant that we would clobber that value in subsequent uses. Note that this only affects i965, because neither anv nor iris use the binding table start sections, so nothing is ever added here. Fixes KHR-GL46.compute_shader.resources-max on i965 with Eric Anholt's MR !3240 applied. That MR reorders SSBOs and ABOs, so that test uses image 0 and SSBO 0, causing this code to brilliantly add binding table index 45 to both the image (correct) and the SSBO (bzzt, wrong!). Fixes: 09f1de97 ("anv,i965: Lower away image derefs in the driver") Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Tested-by: Marge Bot <mesa/mesa!3404> Part-of: <mesa/mesa!3404>
-
Rob Clark authored
My best guess is that this was broken by d62dd8b0 Signed-off-by:
Rob Clark <robdclark@chromium.org> Tested-by: Marge Bot <mesa/mesa!3413> Part-of: <mesa/mesa!3413>
-
Faith Ekstrand authored -
This bumps the Vulkan version to 1.2.128. Signed-off-by:
Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
-
Signed-off-by:
-
Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
Promoted to Vulkan 1.2 with the KHR suffix omitted. Signed-off-by:
-
