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/CAHk3tqjP-ZTA6zMztTKu2dZENi%2B3B737Ox8ZyVkGSKdG6s8cSA%40mail.gmail.com.

Reply via email to