On Mon, Aug 3, 2015 at 6:12 PM, Eric Anholt <e...@anholt.net> wrote: > Jason Ekstrand <ja...@jlekstrand.net> writes: > >> I'm not 100% sure that this is the right patch. Instead of baking 256 into >> the allocator, we could allow the user to pass in an initial constant. >> Since the maximum is statically known, we could also make said constant a >> hard limit and allocate everything up-front in a single array and save all >> the allocations. > > This sucks if we don't have enormous reg sets.
It does, hence the suggestion that we make the initial size tunable or just have the user pass in a hard maximum. Based on my experiments with i965, either of those would work well. I'm not sure what this looks like for vc4. > But we don't use the > conflict_list if you're precomputing the q_values, right? Maybe flag > that we don't need conflict lists at all at reg_set creation time? We can't. We use the conflict list two places: We use it at the end for computing q-values and we use it during setup in add_transitive_conflict. It's this last use that we can't get away from as easily as we'd like. --Jason _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
