On Mon, 7 Jun 2021 10:39:26 GMT, Alexey Ushakov <a...@openjdk.org> wrote:
>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m
>> line 328:
>>
>>> 326: if (_maxPoolMemory < MAX_POOL_MEMORY) {
>>> 327: _maxPoolMemory = MAX_POOL_MEMORY;
>>> 328: }
>>
>> The Apple 5K retina is 5120‑by‑2880 pixels
>>
>> So we start off with a number that is too small
>> #define SCREEN_MEMORY_SIZE_4K (4096*2160*4) //~33,7 mb
>> and then divide it by 2
>> #define MAX_POOL_MEMORY SCREEN_MEMORY_SIZE_4K/2
>>
>> and I have no idea what a typical size is for
>> self.device.recommendedMaxWorkingSetSize
>> which we are also dividing by 2.
>>
>> So I have no idea what the logic is behind all these numbers.
>
>> The Apple 5K retina is 5120‑by‑2880 pixels
>>
>> So we start off with a number that is too small
>> #define SCREEN_MEMORY_SIZE_4K (4096_2160_4) //~33,7 mb
>> and then divide it by 2
>> #define MAX_POOL_MEMORY SCREEN_MEMORY_SIZE_4K/2
>
> I didn't touch this number here, they worked well within our EA testing
> cycles. So, I decided to use it as a fallback. We can extend it to 5K though.
>
>> and I have no idea what a typical size is for
>> self.device.recommendedMaxWorkingSetSize
>> which we are also dividing by 2.
>
> This size typically much much bigger than SCREEN_MEMORY_SIZE_4K
> - 4GB on Radeon Pro 560X 4GB
> - 1.5GB Intel UHD Graphics 630 1536 MB (MBP 2019)
> Looks like it corresponds to the amount of VRAM however the doc says that OS
> may set another value
>
>> An approximation of how much memory, in bytes, this device can use with good
>> performance.
>
> I don't think that it's a good idea to take all the recommended VRAM, so
> decided to divide it by 2.
>
>>
>> So I have no idea what the logic is behind all these numbers.
OK. Can you add some of this info to the bug report.
Notabkly the typical size for self.device.recommendedMaxWorkingSetSize
-------------
PR: https://git.openjdk.java.net/jdk/pull/4279
