iotamudelta
iotamudelta
This looks like an issue with MIOpen. Transferring over.
@daniellowell can reproduce issue. Logging shows it is this rocBLAS call: ``` # MIOPEN_ENABLE_LOGGING=1 MIOPEN_LOG_LEVEL=7 MIOPEN_ENABLE_LOGGING_CMD=1 ROCBLAS_LAYER=2 python3.6 breakme.py ./rocblas-bench -f gemm -r f32_r --transposeA N --transposeB N -m 1310720...
This would be better filed in ROCmSoftwarePlatform/pytorch. Can you comment how you built PyTorch exactly - indeed it is unsupported on gentoo and the PT build infrastructure is rather complex...
OK, that's a bit hard for me to map to the way we do things. So some general questions. You seem to supply `USE_ROCM=1` to the cmake parts - that's...
@jeffhammond should be ready for merge soon after WIP items done - and I'm happy to get any functional reviews already.
As you know Michael is working on a docker. Let's wait till that is there. In general, it is hard to come up w/ a single command out-of-order without compiling...
Same issue here as @stephgosling, same debug output repeating when started from terminal. Edit: sorry, my page hadn't refreshed so didn't see it is already fixed. Thanks! :+1:
@eohulse I fear this app is unmaintained at this point. :-( I have the same issues and people have reported this on openrepos.
If you are using the FLASH interface to libflame, you're probably better off using FLASH_LU_incpiv(). It provides a pivoted LU decomposition more suitable to an algorithms-by-blocks approach like SuperMatrix/FLASH. There's...
See starting here: https://github.com/flame/libflame/blob/d48aa5d42525b0b8d077336763e70e669365b727/src/lapack/dec/lu/incpiv/front/flamec/test/flash_sm/time_LU_incpiv.c#L37 in the test case quoted above. AFAIK the use of the helper functions for creation of hierarchical matrices is strongly advised.