You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The rocALUTION CPU-based backend builds and works on 32-bit architectures. However, there are some limitations reflected by failing tests. I suspect that the problem tests just want to use more memory than can be addressed. Is there a good way to set a memory limit and skip the tests that would use too much RAM?
[ RUN ] uaamg/parameterized_uaamg.uaamg_double/53
The default OS thread affinity configuration will be used
Cannot allocate memory
Size of the requested buffer = 214063204
Fatal error - the program will be terminated
File: ./src/utils/allocate_free.cpp; line: 89
[ RUN ] uaamg/parameterized_uaamg.uaamg_double/53
The default OS thread affinity configuration will be used
Cannot allocate memory
Size of the requested buffer = 428126408
Fatal error - the program will be terminated
File: ./src/utils/allocate_free.cpp; line: 89
The size of the requested buffer is reported as quite small, but given that this is a large test with double-precision, I definitely think this has something to do with the size. It's also interesting that arm and x86 fail slightly differently.
This is obviously not a high priority, but Debian tries to build all architectures by default and these two appear to almost work. This is something for the wishlist.
The text was updated successfully, but these errors were encountered:
samjwu
pushed a commit
to samjwu/rocALUTION
that referenced
this issue
Oct 2, 2024
The rocALUTION CPU-based backend builds and works on 32-bit architectures. However, there are some limitations reflected by failing tests. I suspect that the problem tests just want to use more memory than can be addressed. Is there a good way to set a memory limit and skip the tests that would use too much RAM?
On i386:
On armhf
The size of the requested buffer is reported as quite small, but given that this is a large test with double-precision, I definitely think this has something to do with the size. It's also interesting that arm and x86 fail slightly differently.
This is obviously not a high priority, but Debian tries to build all architectures by default and these two appear to almost work. This is something for the wishlist.
The text was updated successfully, but these errors were encountered: