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/CAHk3tqjEA1VvX1J835hMgbnYz57f0Bkcx9iv0jv8YC0%3DBdhugg%40mail.gmail.com.

Reply via email to