Post

Replies

Boosts

Views

Activity

Reply to Writing to depth buffer
Hello, Is it still impossible for the Metal fragment shader to write to the depth buffer for the current version of Metal on the M1 CPUs? The image below shows the use case for my MRIcroGL software (with these images showing the correct behavior of OpenGL on my M1). MRIcroGL is a volume raycaster. The vertex shader simply determines the location of the front faces of the cube (left panel). The fragment shader subsequently samples each pixel from the front face of the cube to the back face, accumulating color/opacity from all the voxels it traverses. In OpenGL, I can simply write 'gl_FragDepth' for a ray when it first hits a non-transparent voxel. This has two benefits: first the depth test fro the subsequent crosshairs correctly shows the ntersection with the brain, not the cube. Second, we can read the depth buffer allowing depth picking, where clicking on the brain moves the crosshair to that location (allowing the user to work out the location of features seen on the rendering for 2D orthogonal slices). In every other respect, my software works identically when compiled for OpenGL and Metal. However, the inability to write to a depth buffer seems like a deal breaker for this usage scenario.
Sep ’21
Reply to How to compile a universal version of Python 3.8 (for both Mac M1 and Intel)
Python is a complex project. I would suggest you get a pre-compiled version for your platform. A good place to start would be the miniforge distribution which includes a version compiled for arm64 (Apple Silicon) - https://github.com/conda-forge/miniforge#download. However, you may find that many modules do yet support this architecture (e.g. Pandas), some that do support it are built using experimental compilers (gcc/gFortran) that may have issues or poor performance. Even core modules like numpy exhibit some bugs - https://github.com/numpy/numpy/issues/17964 on the M1, and some native functions perform a magnitude slower than the same function run as translated code - https://github.com/numpy/numpy/issues/17989 (which suggest low hanging fruit for optimization). It seems like these issues are getting rapidly resolved, but in the short term I would suggest sticking with the translated Python unless you are explicitly trying to resolve these limitations.
Dec ’20
Reply to Distributing a command-line binary executable (2020 edition)?
@Etresoft thanks for your solution. This works! There is a tiny typo: "--root ./tmp/usr/local" should read "--root usr/local". I still think Apple could help out the community a lot by providing a graphical tool to help the many cross platform projects that do not use Xcode. There are a lot of moving parts, and the feedback is opaque. It seems like details change between OS releases, so search the web for answers causes issues with solutions that used to work.
Dec ’20
Reply to Problem with xcrun altool - CFURLRequestSetHTTPCookieStorageAcceptPolicy_block_invoke
I get this error on M1 using Big Sur: no quotes. As suggested, I did this without -p and entering the correct password is accepted, but I still get this error.... xcrun altool --notarize-app -t osx --file mydmg.dmg --primary-bundle-id com.mydomain.mySoftware -u myemail@myu.edu myemail@myu.edu's password: 2020-11-26 07:56:05.092 altool[31245:301096] CFURLRequestSetHTTPCookieStorageAcceptPolicy_block_invoke: no longer implemented and should not be called No errors uploading 'mydmg.dmg'. RequestUUID = d5c46e28-cbbd-44f5-802a-12112c3d81***
Nov ’20