pub(super) fn execution_providers(
cache_dir: &Path,
ep: EpSelection,
device_id: u32,
trt_max_workspace_bytes: Option<usize>,
gpu_mem_limit_bytes: Option<usize>,
) -> Vec<ExecutionProviderDispatch>Expand description
Returns the execution providers to use for this platform and EP selection.
On macOS: always uses the CoreML EP with MLProgram format and
FastPrediction specialisation strategy (overridable via
BGE_M3_COREML_STRATEGY=default), regardless of ep.
On Linux with the tensorrt feature: selects TensorRT when
ep == EpSelection::TensorRt, with engine caching, FP16, and the
specified device_id enabled. When trt_max_workspace_bytes is Some,
the workspace cap is forwarded to the TRT EP via with_max_workspace_size;
otherwise ORT’s built-in default is used.
On Linux with the cuda feature: selects CUDA when
ep == EpSelection::Cuda, pinned to device_id. When
gpu_mem_limit_bytes is Some, the device memory limit is forwarded via
with_memory_limit; otherwise the EP uses all available device memory.
CPU fallback: returns an empty list so ORT falls back to MLAS.
device_id is computed by EmbedPool::spawn as
worker_index % gpu_count and is ignored on CPU EP and macOS.
Emits a single INFO log line tagged "ORT execution providers configured"
describing the configured EP, the EP that was actually built (the “active”
EP), and any cache paths handed to it. This is the source of truth in
CloudWatch for “is TensorRT really active or did we silently fall back?”.