The Gemm NN GPU is missing declaration of datatype #138

[abouteiller]

…sue #138

[devreal]

Is there a way to handle this more gracefully in PaRSEC than a Segfault?

[abouteiller]

Is there a way to handle this more gracefully in PaRSEC than a Segfault?

Yes, the resultant symptom is that we have data.dst_type==NULL and data.dst_count==1 which is impossible, we could at the minimum assert.

[bosilca]

How has this ever worked without a proper datatype and arena ? The puzzling part if that no GEMM nor POTRF has a default tile type.

[abouteiller]

in PO and GEMM_SUMMA/GEMM we use the adt_all_loc to create and populate the arenas in a wrapped collection. We did not addapt GEMM_NN_GPU to use that same feature, so it must still rely on setting the arena_datatypes[DEFAULT_IDX]. We never select GEMM_NN_GPU except in memory constrained scenarios, which were broken due to separate problems that were masking this issue by crashing before we hit it (see ICLDisco/parsec#733).

Also has been reported by J John #67 but we didn't follow on it because we would not see it ourselves.

[bosilca]

The arenas in the data collection are not linked to the arenas in the taskpool, and that datatype is only used for send, once we have a valid data copy. When we receive a data and we create the local datacopy that is not attached to any data collection, we extract the arena and the datatype from the taskpool, and right now these are NULL. So how are we receiving anything ?

[abouteiller]

(from slack, for posterity) dplasmajdf_lapack_dtt.h:61, we don’t hit the arena_datatypes in the taskpool in this pathway. This interacts with how we set the type_remote in the JDF (ADT_DC), we read the types from a hashtable then.

[abouteiller]

We discussed on slack that it would be good to unify the ADTT_READ-hashtable and the arena_datatypes array mechanics, but I don't have time ATM for this so later.