JDK-8261549 : Adjust memory size in MTLTexurePool.m
  • Type: Task
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 17
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2021-02-11
  • Updated: 2021-06-11
  • Resolved: 2021-06-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17
17 b26Fixed
Related Reports
Relates :  
JDK-8260931 - Implement JEP 382: New macOS Rendering Pipeline
Description
There is a question asked on PR - https://github.com/openjdk/jdk/pull/2403
for file -  src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m 

This means that a 4k display with a narrower aspect ratio wouldn't fit (assuming there ever were to be such a thing). What would happen if you encountered a screen that was, say, 4k * 2.5K?

Please address it on PR https://github.com/openjdk/jdk/pull/2403
If no code change is needed, you can close this bug.
Comments
Changeset: 7e55569e Author: Alexey Ushakov <avu@openjdk.org> Date: 2021-06-07 17:36:52 +0000 URL: https://git.openjdk.java.net/jdk/commit/7e55569edee84dcae63fbdf1f89fefa554360736
07-06-2021
Used MTLDevice recommendedMaxWorkingSetSize property (divided by 2) for optimal size of the texture pool According to my experiments, this property was: 4GB on Radeon Pro 560X 4GB (MBP 2019) 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
07-06-2021
This parameter manages our caching strategy for the temporary texture pool. Huge texture allocations 4K/2 size will cause texture pool drain. We need some more profiling to just these parameters. And I think we need to use Metal API (https://developer.apple.com/documentation/metal/mtldevice/2369280-recommendedmaxworkingsetsize?language=objc) in the future to adjust the amount of memory that we should use.
11-02-2021