Re: [Mesa-dev] NIR + softfp64 problem
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
Re: [Mesa-dev] NIR + softfp64 problem
On Wed, Jan 16, 2019 at 3:53 AM Gert Wollny wrote: > > Hello, > > I'm trying to get soft-fp64 working with my experimental r600-nir > backend, and thanks to Dave's contribution it is already tied in, > some instructions are not yet supported by the backend, but when > running the piglits I have already 24 tests passing. However, there are > also 1099 test crashing, and skimming over the results this is mostly > because of validation erros in nir_lower_doubles called with > nir_lower_fp64_full_software. For instance, in fs-fract-dvec4 I get > something like > > decl_var INTERP_MODE_NONE dvec4 p > ... > vec1 32 ssa_0 = deref_var (function dvec4) > ... > call __fadd64 ssa_77, ssa_78, ssa_79 > vec1 64 ssa_80 = intrinsic load_deref (ssa_77) (0) /* access=0 > */intrinsic store_deref (ssa_0, ssa_80) (15, 0) /* wrmask=xyzw */ /* > access=0 */ > error: src->ssa->num_components == num_components > (../../../mesa/src/compiler/nir/nir_validate.c:206) > ... > > with (src->ssa->num_components == 1) and (num_components == 4). > > i.e. a function returns a single value, but the target where to store > it is a vector with four elements. > > I have no idea whether this is something triggered by the compile > options I defined for nir, or whether this is independed from this, so > 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. 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. Or, we could try to figure out how to add vectorized versions of the soft-fp64 routines that R600 could use directly. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] NIR + softfp64 problem
Hello, I'm trying to get soft-fp64 working with my experimental r600-nir backend, and thanks to Dave's contribution it is already tied in, some instructions are not yet supported by the backend, but when running the piglits I have already 24 tests passing. However, there are also 1099 test crashing, and skimming over the results this is mostly because of validation erros in nir_lower_doubles called with nir_lower_fp64_full_software. For instance, in fs-fract-dvec4 I get something like decl_var INTERP_MODE_NONE dvec4 p ... vec1 32 ssa_0 = deref_var (function dvec4) ... call __fadd64 ssa_77, ssa_78, ssa_79 vec1 64 ssa_80 = intrinsic load_deref (ssa_77) (0) /* access=0 */intrinsic store_deref (ssa_0, ssa_80) (15, 0) /* wrmask=xyzw */ /* access=0 */ error: src->ssa->num_components == num_components (../../../mesa/src/compiler/nir/nir_validate.c:206) ... with (src->ssa->num_components == 1) and (num_components == 4). i.e. a function returns a single value, but the target where to store it is a vector with four elements. I have no idea whether this is something triggered by the compile options I defined for nir, or whether this is independed from this, so any idea how to quell this would be very welcome. Many thanks, Gert ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
