Closed maleadt closed 4 months ago
The problem is with the Float16 ABI; onemklHgemm
is a uint16_t function yet we ccall with Float16
, which used to work fine, but in 1.11 we now correctly use the platform Float16 ABI. Problem is that due to switching ABIs, we cannot build a single artifact (using the half ABI) and use that across versions, so I guess we'll have to reinterpret to UInt16 manually on the Julia side.
I think the easiest way forward is to pass scalars (e.g. alpha/beta inputs) as references instead of values, avoiding any ABI confusion as seen here. This is also what cuBLAS does, and will help us when targeting BFloat16s in the future. I've updated the manual headers and generated wrappers, but I'm not familiar with the generate_interfaces.jl
script. @amontoison Could you update it so that all scalars (Ts
types in oneMKL) are passed as pointers instead?
On the Julia side, we shouldn't have to do anything; that's the beauty of the Ref
type.
I think the easiest way forward is to pass scalars (e.g. alpha/beta inputs) as references instead of values, avoiding any ABI confusion as seen here. This is also what cuBLAS does, and will help us when targeting BFloat16s in the future. I've updated the manual headers and generated wrappers, but I'm not familiar with the
generate_interfaces.jl
script. @amontoison Could you update it so that all scalars (Ts
types in oneMKL) are passed as pointers instead?On the Julia side, we shouldn't have to do anything; that's the beauty of the
Ref
type.
I can do that @maleadt.
I will also document generate_interfaces.jl
after #403.
Thanks. Feel free to push directly to this PR.
@maleadt We can't pass scalars by reference instead of by value for all oneMKL routines.
This approach works for all BLAS routines except for sdsdot
.
I propose not to update LAPACK and SPARSE routines yet, as they currently support only the four main precisions.
@maleadt We can't pass scalars by reference instead of by value for all oneMKL routines.
Why not? We're talking about the Julia<->Support library interface, these references don't have to be passed to MKL itself.
Ok, so you want the following thing for all routines, right?
int onemklDgemm(syclQueue_t device_queue, onemklTranspose transa, onemklTranspose transb, int64_t
m, int64_t n, int64_t k, double *alpha, double *a, int64_t lda, double *b, int64_t ldb,
double *beta, double *c, int64_t ldc);
extern "C" int onemklDgemm(syclQueue_t device_queue, onemklTranspose transa, onemklTranspose transb,
int64_t m, int64_t n, int64_t k, double *alpha, double *a, int64_t lda, double *b,
int64_t ldb, double *beta, double *c, int64_t ldc) {
auto status = oneapi::mkl::blas::column_major::gemm(device_queue->val, convert(transa), convert(transb),
m, n, k, *alpha, a, lda, b, ldb, *beta, c, ldc, {});
__FORCE_MKL_FLUSH__(status);
return 0;
}
Yes. Otherwise, we rely on the platform/type-dependent argument passing ABIs, which are ill-defined and changing for types like Float16 and BFloat16.
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 79.62%. Comparing base (
5cce2db
) to head (8e35b4e
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@maleadt All tests passed :tada:
Awesome, thanks!
I don't see the updated generate_interfaces.jl
though; did you forget to commit that?
I modified generate_interfaces.jl
in the PR #403.
I don't want to push it here because it requires the new format of the headers (with template) that they introduced in oneAPI 2024.1
.
Encountered this locally; let's see if it happens on CI too: