freedreno/a6xx: bump varyings limit

• Reduced gl_MaxGeometryInputComponents to 64 (same as in Turnip and blob).
• Fixed assert in fd6_program.c

The test coverage of the limits isn't great. And almost always hitting a register allocation failure doesn't help.

I sent an MR to piglit with tests that don't trigger RA failure - piglit!430 (merged)

The only failing test there is tcs-tes-max-in-out-components which hangs.

Fixed hang in tcs-tes-max-in-out-components via ir3: Allow tesselation to use all 32 varying slots.

Now all tests are passing.

cool, lgtm.. r-b for the additional patches

In piglit!430 (merged) Marek Olšák noticed that I forgot some cases. So I found yet another hang - when passing varyings between vs -> tcs.

I found out that it happens when SP_HS_UNKNOWN_A831 becomes greater than 64. To my surprise, the value of A831 doesn't affect anything - I set it to zero and all my tests are passing.

Looking at blob's output did confuse me even more:

A831 value depending on varyings count (click me)

All traces (some register numbers could be borked due to the assert num < MAX_REG in regmask_set when decoding traces):

vs-tcs-blob-traces.tar.gz

I see that A650 has a considerable difference in how this value is calculated. @flto you fixed SP_HS_UNKNOWN_A831 for A650, maybe you could offer an advice or an educated guess? Thanks!

Added "freedreno/a6xx: Fix SP_HS_UNKNOWN_A831 value" which ports A831 calculation for A650 from turnip and uses the formula devised by @flto for others.

The difference between A650 and others is in the calculation of prims-per-wave:

max_a831 = 0x40
max_prims_per_wave = max_a831 * wavesize / (vs->output_size * patch_control_points)
prims_per_wave = MIN2(prims_per_wave, max_prims_per_wave);

I think it means that there is a limited storage of max_a831 * wavesize size per wave and if we are exceeding it - we are forced to reduce the count of prims processed per wave.