On Wed, 2 Jul 2025 07:53:24 GMT, Ambarish Rapte <ara...@openjdk.org> wrote:
>> ### Description
>> This is the implementation of new graphics rendering pipeline for JavaFX
>> using Metal APIs on MacOS.
>> We released two Early Access (EA) builds and have reached a stage where it
>> is ready to be integrated.
>> Default rendering pipeline on macOS has not been changed by this PR. OpenGL
>> still stays as the default rendering pipeline and Metal rendering pipeline
>> is optional to choose (by providing `-Dprism.order=mtl`)
>> The `-Dprism.verbose=true` option can be used to verify the rendering
>> pipeline in use.
>>
>> ### Details about the changes
>>
>> **Shader changes**
>> - MSLBackend class: This is the primary class that parses (Prism and Decora)
>> jsl shaders into Metal shaders(msl)
>> - There are a few additional Metal shader files added under directory :
>> modules/javafx.graphics/src/main/native-prism-mtl/msl
>>
>> **Build changes** - There are new tasks added to build.gradle for
>> - Generation/ Compilation/ linking of Metal shaders
>> - Compilation of Prism Java and Objective C files
>>
>> **Prism** - Prism is the rendering engine of JavaFX.
>> - Added Metal specific Java classes and respective native implementation
>> which use Metal APIs
>> - Java side changes:
>> - New Metal specific classes: Classes prefixed with MTL, are added here :
>> modules/javafx.graphics/src/main/java/com/sun/prism/mtl
>> - Modification to Prism common classes: A few limited changes were
>> required in Prism common classes to support Metal classes.
>> - Native side changes:
>> - New Metal specific Objective C implementation is added here:
>> modules/javafx.graphics/src/main/native-prism-mtl
>>
>> **Glass** - Glass is the windowing toolkit of JavaFX
>> - Existing Glass classes are refactored to support both OpenGL and Metal
>> pipelines
>> - Added Metal specific Glass implementation.
>>
>> ### Testing
>> - Testing performed on different hardware and macOS versions.
>> - HW - macBooks with Intel, Intel with discrete graphics card, Apple
>> Silicon (M1, M2 and M4)
>> - macOS versions - macOS 13, macOS 14 and macOS 15
>> - Functional Testing:
>> - All headful tests pass with Metal pipeline.
>> - Verified samples applications: Ensemble and toys
>> - Performance Testing:
>> - Tested with RenderPerfTest: Almost all tests match/exceed es2
>> performance except a few that fall a little short on different hardwares.
>> These will be addressed separately (there are open bugs already filed)
>>
>> ### Note to reviewers :
>> - Providing `-Dprism.order=mtl` option is a must for testing the Metal
>> pipeline
>> - It woul...
>
> Ambarish Rapte has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add @Override
Good work!
Reviewed the Metal-native-side of this commit (`native-prism-mtl` folder) and
left some comments to talk through, nothing extremely major though. I'll verify
the code on my side once we get closer to review completion.
modules/javafx.graphics/src/main/native-prism-mtl/MetalContext.m line 1437:
> 1435: [pCtx endCurrentRenderEncoder];
> 1436:
> 1437: id<MTLCommandBuffer> commandBuffer = [pCtx getCurrentCommandBuffer];
I think most of this function should become a `MetalContext` method that would
be called here. That way we separate the Metal-related implementation from JNI
entry points and it follows the pattern of other JNI entry points in this file.
modules/javafx.graphics/src/main/native-prism-mtl/MetalShader.m line 167:
> 165: pipeState = [[context getPipelineManager]
> getPipeStateWithFragFunc:fragmentFunction
> 166:
> compositeMode:compositeMode];
> 167: [psDict setObject:pipeState forKey:keyCompMode];
I am not 100% sure why there is a need to duplicate PipelineState dictionaries
here and to create a Shader-specific cache of States. If you need to get a
PipelineState, why not always directly call on `MetalPipelineManager`?
modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 235:
> 233: id<MTLCommandBuffer> commandBuffer = [context
> getCurrentCommandBuffer];
> 234: @autoreleasepool {
> 235: id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer
> blitCommandEncoder];
Similarly to `MetalContext` comment, I think we should separate JNI entry point
code and argument parsing/converting from actual Metal-reaching implementation.
I would also move this to a `MetalTexture` method.
modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 300:
> 298:
> 299: @autoreleasepool {
> 300: id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer
> blitCommandEncoder];
As above
modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 364:
> 362:
> 363: @autoreleasepool {
> 364: id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer
> blitCommandEncoder];
As above
modules/javafx.graphics/src/main/native-prism-mtl/MetalTexture.m line 407:
> 405:
> 406: @autoreleasepool {
> 407: id<MTLDevice> device = [context getDevice];
As above
-------------
PR Review: https://git.openjdk.org/jfx/pull/1824#pullrequestreview-2961851748
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192155071
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192281270
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192317134
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192305858
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192306212
PR Review Comment: https://git.openjdk.org/jfx/pull/1824#discussion_r2192307217
