Work on soft fp64 support has uncovered some pessimal memory usage
inside NIR. Code that uses soft fp64 hits two problems: huge numbers of
basic blocks and huge numbers of values. Several places in the compiler
use straight forward, naive data structures that consume massive amounts
of memory in pessimal cases.
One of the worst examples is in nir_phi_builder. For each value in a
program, there is an array that stores a pointer for each basic block.
If you have 33,000 values and 17,000 basic blocks (as one test case
does), you're going to use many gigabytes of memory. Since most values
don't have a definition in most blocks, almost all of those gigabytes of
pointers are NULL.
This patch series fixes that problem. It replaces the per-value array
with a per-program hash that matches [value, block] tuples to a def.
The remaining patches in the series implement some smaller reductions.
To measure the changes in memory usage, I picked a handful of shaders
from shader-db that I know to be "big." Some have a tendency to spill a
lot, and some just have a lot of instructions. I also took the shader
from the pessimal test case (arb_gpu_shader_fp64-vs-getuniformdv) and
lowered it to soft fp64 by hand. I had to reduce the test case quite a
bit. Since the lowering happens before the compiler can do
anything... the test case goes from pessimal to 2^pessimal, and it fails
register allocation. This test is:
https://patchwork.freedesktop.org/patch/263081/
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
