My suggestion is that GPU acceleration is taken out for mac arm64(apple silicon) machines. If kept, maybe use the fix and put in a text where it says "experimental" when arch 64 macs are in use.
On Wed, Sep 27, 2023 at 8:50 PM dudek53 <[email protected]> wrote: > I guess the proper way is to fetch apple M1 memory into this OpenGL code, > see below, so that it could be used similar to how memory is established > for nvidia,amd,ati cards(sorry, posting code snippet here again). However > this is only to be done with some Metal API calls. I guess this is the only > way to future proof other mac apple silicon cards. Question is also how > long will apple support OpengL, probably not for long. > I´ll see if I can find time to do this properly in the magical future. > > long long int GpuMemoryInBytes = 512 << 20; > // read memory size, not implemented on all graphic cards > { > // for nvidia cards > #define GL_GPU_MEM_INFO_TOTAL_AVAILABLE_MEM_NVX 0x9048 > GLint total_mem_kb = 0; > glGetIntegerv(GL_GPU_MEM_INFO_TOTAL_AVAILABLE_MEM_NVX, > &total_mem_kb); > if (glGetError() == GL_NO_ERROR) > { > GpuMemoryInBytes = total_mem_kb * 1024ll; > }; > }; > { > //for amd/ati cards > #define TEXTURE_FREE_MEMORY_ATI 0x87FC > GLint param[4]; > glGetIntegerv(TEXTURE_FREE_MEMORY_ATI, param); > if (glGetError() == GL_NO_ERROR) > { > GpuMemoryInBytes = param[0] * 1024ll; > }; > } > > On Wed, Sep 27, 2023 at 5:21 PM dudek53 <[email protected]> wrote: > >> I will try and seek an explanation. The factor 2 could probably find some >> refined limitation number other than 2. >> >> It is probably possible explaining the exact cause of the fix but I doubt >> I will be able to do it. Speaking in general terms the code right now >> causes memory leaks and forces sigkill on Mac. It is pretty nasty. I assume >> memory management is working slightly different than on intel. >> I know this answer isn't adequate for you :). >> >> The fix could be skipped as not many users tick this option it seems >> because that would mean a lot more moaning on here 😎. >> >> I see what I can find though. Don't hold your breath. >> >> >> >> Den ons 27 sep. 2023 17:02T. Modes <[email protected]> skrev: >> >>> [email protected] schrieb am Mittwoch, 27. September 2023 um 00:01:02 >>> UTC+2: >>> >>> Just want to put out this again but with a refined change. >>> In *ImageTransformsGPU.cpp *we have following >>> *:* >>> const int bytesPerDestPixel = 16 + 16 + 8 >>> + ((XGLMap[destGLTransferFormat] != >>> GL_RGBA32F_ARB) ? BytesPerPixel[destGLTransferFormat] : 0) >>> + ((destAlphaBuffer != NULL) ? 1 : 0); >>> const long long int maxDestPixels = gpuMemoryRemaining / >>> bytesPerDestPixel; >>> >>> >>> *Change to below for mac M1 ARM 64-bit:* >>> const int bytesPerDestPixel = 16 + 16 + 8 >>> + ((XGLMap[destGLTransferFormat] != >>> GL_RGBA32F_ARB) ? BytesPerPixel[destGLTransferFormat] : 0) >>> + ((destAlphaBuffer != NULL) ? 1 : 0); >>> #ifdef __aarch64__ // Check for ARM 64-bit architecture >>> * const long long int maxDestPixels = gpuMemoryRemaining / >>> bytesPerDestPixel / 2;* >>> #else >>> const long long int maxDestPixels = gpuMemoryRemaining / >>> bytesPerDestPixel; >>> #endif >>> >>> >>> I asked you already the last time to use a diff file and not to copy >>> this into the mail. The mail program does often mangle the format. And the >>> exact line in the code is unknown, I have to guess. (It may works in this >>> simple case, but for more complicated one this becomes more complicated.) >>> >>> >>> >>> By reducing bytesPerDestPixel by half I can process huge files on my M1. >>> Tested 20000 X 13333 pixel files and they come out just fine. My first fix >>> would segfault on these files. >>> Of course this could be tested more and maybe you want a version to try >>> mikko? You are actually the first person I hear about selecting the GPU >>> option working on M1. >>> >>> If tested around some maybe it would be a legit fix? What´s your opinion >>> T.Modes? >>> >>> >>> If you can explain why a factor of 2 is needed only for the Mac M1, yes. >>> And why 2 and not any other random number? >>> And it works for me is not enough. There are many more use case than >>> your limited testing with only 20000 pixel and only a limited format >>> variation. >>> >>> Thomas >>> >>> -- >>> A list of frequently asked questions is available at: >>> http://wiki.panotools.org/Hugin_FAQ >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "hugin and other free panoramic software" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/hugin-ptx/8c62eaf2-2b34-4af3-8242-14fdcee5bf5en%40googlegroups.com >>> <https://groups.google.com/d/msgid/hugin-ptx/8c62eaf2-2b34-4af3-8242-14fdcee5bf5en%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAHk3tqiPkNMWqVCLf8cEAjnSE4k9akq5PsSuux-WGcMBnJpY0Q%40mail.gmail.com.
