Add experimental OpenVINO GFX plugin with Metal and OpenCL backends

[allnes]

PR Description

This PR introduces the experimental OpenVINO GFX device plugin under modules/gfx_plugin.

The plugin adds a standalone GPU backend module that compiles an ov::Model into a stage-based execution pipeline and executes it through backend-specific runtimes. The current implementation supports:

• Metal on macOS
• Vulkan on non-Apple builds when Vulkan is enabled at configure time

At a high level, the module contains:

• OpenVINO plugin integration for Plugin, CompiledModel, InferRequest, AsyncInferRequest, RemoteContext, and RemoteTensor
• shared graph transformation and support-probing logic
• MLIR-based lowering and codegen infrastructure
• backend-specific execution layers for Metal and Vulkan
• unit, integration, and backend-specific tests
• self-contained module documentation inside modules/gfx_plugin/

Architecture and Execution Model

Compilation is stage-based rather than a single monolithic backend object:

• OpenVINO graph transforms run in src/transforms/
• backend-aware support checks and lowering are driven from src/mlir/
• CompiledModel builds a pipeline of GpuStage objects
• infer requests bind host/remote tensors and execute the prepared pipeline through backend submission sessions

The runtime includes:

• stage optimization policy selection
• optional fusion through FusedSequenceStage
• absorbed input transforms for selected transpose patterns
• reusable infer pipeline preparation
• submission-window management for command-buffer recording and submission
• immutable const-buffer reuse and prepared kernel-binding reuse

Backend Notes

Metal and Vulkan share frontend and plugin logic but keep runtime and codegen isolated under src/backends/.

The Vulkan backend includes:

• device-capability-aware execution policy
• direct and chunked specialized paths for selected ops
• SPIR-V-oriented MLIR and codegen flow
• descriptor and binding reuse across compatible executions

The Metal backend includes:

• Objective-C++ runtime integration with Metal APIs
• backend-specific memory management and const-buffer caching
• MSL-oriented codegen and runtime execution

Behavioral Expectations

Important behavior in this PR:

• device name is GFX
• query_model() is backend-aware and follows the same support path as compilation
• unsupported models fail during compile_model(); there is no silent partial CPU fallback
• import_model() reloads and recompiles the OpenVINO model
• export_model() serializes model data, not a compiled GPU pipeline cache
• remote context and remote tensor support exist, with practical capabilities depending on the active backend implementation

Testing

The module includes:

• unit coverage for MLIR lowering, stage policy, infer submission, reusable pipeline setup, kernel and buffer reuse, and layout cleanup
• backend tests for Metal and Vulkan runtime behavior
• helper tooling such as ov_gfx_compare_runner for GFX vs reference comparisons

Documentation

Published module docs are self-contained inside modules/gfx_plugin/:

• README.md
• docs/ARCHITECTURE.md
• docs/DEVELOPMENT.md
• docs/TESTING.md
• docs/USAGE.md

[github-actions]

This pull request has been automatically marked as stale because it has not had any activity for the last 2 weeks. It will be closed in 7 days if no further activity occurs. Please push new commits or leave a comment to keep it open. Thank you for your contributions!

[github-actions]

This pull request has been automatically marked as stale because it has not had any activity for the last 2 weeks. It will be closed in 7 days if no further activity occurs. Please push new commits or leave a comment to keep it open. Thank you for your contributions!

[github-actions]

This pull request has been automatically marked as stale because it has not had any activity for the last 2 weeks. It will be closed in 7 days if no further activity occurs. Please push new commits or leave a comment to keep it open. Thank you for your contributions!

[github-actions]

This pull request has been automatically marked as stale because it has not had any activity for the last 2 weeks. It will be closed in 7 days if no further activity occurs. Please push new commits or leave a comment to keep it open. Thank you for your contributions!