Post

Replies

Boosts

Views

Activity

Crash in Metal Framework macOS 14.4 beta
Hello, I have a crash in the Metal framework under Sonoma 14.4 public beta on a Mac Mini M1 2020: Thread 1 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x17c2770b7ca20001 x9: 0x17c2770b7ca20001 x10: 0x0000000000000025 x11: 0x0000000000000001 x12: 0x000000016bb555b2 x13: 0x0000000000000000 x14: 0x0000000104acc7e9 x15: 0x0000000207c5c5b0 x16: 0xfffffffffffffff4 x17: 0x0000000211f42c48 x18: 0x0000000000000000 x19: 0x000000016bb55898 x20: 0x0000600002901180 x21: 0x0000600003cd0e20 x22: 0x0000000000000003 x23: 0x0000000277b7e040 x24: 0x00000000000002ec x25: 0x0000000000000001 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000207c96b50 fp: 0x000000016bb55880 lr: 0x2d648001a439d394 sp: 0x000000016bb557b0 pc: 0x00000001a439d394 cpsr: 0x60001000 far: 0x0000000000000000 esr: 0xf2000001 (Breakpoint) brk 1 Binary Images: 0x139c00000 - 0x139c6bfff com.apple.AppleMetalOpenGLRenderer (1.0) <8b69c871-19c2-3d46-b8de-8dbc62e532cd> /System/Library/Extensions/AppleMetalOpenGLRenderer.bundle/Contents/MacOS/AppleMetalOpenGLRenderer 0x109b74000 - 0x109baffff libjogl_mobile.dylib () <9c3ef505-8828-36ab-a776-5ffdb9d4cd79> /Applications/scilab-2024.0.0.app/Contents/lib/thirdparty/libjogl_mobile.dylib 0x13b494000 - 0x13b50ffff libjogl_desktop.dylib () <543b42ae-90a4-325c-8850-84951b1fa6ee> /Applications/scilab-2024.0.0.app/Contents/lib/thirdparty/libjogl_desktop.dylib 0x108588000 - 0x10858ffff libnativewindow_macosx.dylib (*) <2c256988-735b-38b7-9712-0bfc58c3ff90> /Applications/scilab-2024.0.0.app/Contents/lib/thirdparty/libnativewindow_macosx.dylib How can I get rid of ot ? S.
2
0
587
Feb ’24
Accelerate framework uses only one core on Mac M1
The following C program (dgesv_ex.c) #include stdlib.h #include stdio.h /* DGESV prototype */ extern void dgesv( int* n, int* nrhs, double* a, int* lda, int* ipiv, double* b, int* ldb, int* info ); /* Main program */ int main() { /* Locals */ int n = 10000, info; /* Local arrays */ /* Initialization */ double *a = malloc(n*n*sizeof(double)); double *b = malloc(n*n*sizeof(double)); int *ipiv = malloc(n*sizeof(int)); for (int i = 0; i n*n; i++ ) { a[i] = ((double) rand()) / ((double) RAND_MAX) - 0.5; } for(int i=0;in*n;i++) { b[i] = ((double) rand()) / ((double) RAND_MAX) - 0.5; } /* Solve the equations A*X = B */ dgesv( &amp;n, &amp;n, a, &amp;n, ipiv, b, &amp;n, &amp;info ); free(a); free(b); free(ipiv); exit( 0 ); } /* End of DGESV Example */ compiled on a Mac mini M1 with the command clang -o dgesv_ex dgesv_ex.c -framework accelerate uses only one core of the processor (as also shown by the activity monitor) me@macmini-M1 ~ % time ./dgesv_ex ./dgesv_ex 35,54s user 0,27s system 100% cpu 35,758 total I checked that the binary is of the right type: me@macmini-M1 ~ % lipo -info dgesv Non-fat file: dgesv is architecture: arm64 As a comparaison, on my Intel MacBook Pro I get the following output : me@macbook-intel ˜ % time ./dgesv_ex ./dgesv_ex 142.69s user 0,51s system 718% cpu 19.925 total Is it a known problem ? Maybe a compilation flag or else ?
2
1
2.3k
May ’21
Notarization server down ?
Hi, I just made two successfull notarizations this morning, in less than 10 minutes : 0d8a6b87-5dcc-43c8-8a1a-58d4a94d2283 d731b45e-9108-4c19-8056-06ba4e7dd16e Suddendly the two latests ones are pending, the worst one is pending for almost an hour: fe89d78a-21e8-4f03-96b7-19a7cc3bd9a0 What is the problem ? S.
1
0
548
Jul ’21