Hello Matt, Am Mittwoch, den 16.01.2019, 10:17 -0800 schrieb Matt Turner: > any idea how to quell this would be very welcome. > > It's required to scalarize fp64 operations before this lowering code > will work. It looks to me like it's trying to call __fadd64 with a > dvec4 argument, when the arguments are actually scalar. > > I think r600 is mostly vector-based? The soft-fp64 code probably > isn't ideally suited for that. I'd attempt to call > nir_lower_alu_to_scalar() before calling nir_lower_doubles(). That > should at minimum tell you whether my hypothesis is correct. Indeed, r600 I don't do nir_lower_alu_to_scalar() because it is more convenient for me, but with that the number of crashes goes down significantly, the remaining crashes seem to be in my own code. > > From there, maybe we could pass an options bitfield to > nir_lower_alu_to_scalar() to allow R600 to only lower fp64 operations > and not scalarize everything. I think this is the option I'll purse, I've touched that routine before before I disabled it completely.
> Or, we could try to figure out how to > add vectorized versions of the soft-fp64 routines that R600 could use > directly. Unless other drivers can take advantage of this I don't think that this woule make much sense. To get the r600 nir backend performant I'd have to write some scheduler for the backend anyway (and this is still a long way to go). thanks for the pointers, Gert _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
