A procurement slide says the compute layer is “hardware-agnostic” — it runs on AMD, Intel, and NVIDIA. That claim is usually true and almost always incomplete. The word agnostic gets sold as free portability: write once, run on any GPU. The naive reading treats agnosticism as a checkbox — pick OpenCL or SYCL, and assume the code moves cleanly across vendors because it compiles cleanly across vendors. It does not work that way. API-level portability does not guarantee performance portability. A kernel that compiles on all three vendors’ runtimes can still run at a fraction of peak achievable throughput on two of them, because the memory-access patterns and tuning decisions baked into it were shaped by one architecture. The divergence point — the moment where a vendor-neutral strategy quietly becomes a liability — is when a team confuses “it runs on all vendors” with “it runs well on all vendors.” A genuinely hardware-agnostic GPU compute solution is engineered for portable performance, not just portable compilation. That distinction is the whole subject of this article, and it is the difference between a strategy you can audit and one you are taking on faith. What does hardware-agnostic GPU compute actually mean in practice? Strip away the marketing and there are two independent properties hiding under one word. The first is API portability: the same source code compiles and executes correctly on multiple vendors’ hardware. OpenCL, SYCL, and Vulkan compute all deliver this. You write a kernel once, the runtime targets the device present, and the numerical result is correct everywhere. This is real, and it is genuinely useful — it removes the need to maintain three separate codebases. The second is performance portability: the same code runs at an acceptable fraction of each target’s achievable throughput without per-target rewrites. This is the property people assume they are buying and rarely the one they get. Achieving it means the kernel’s work-group sizing, memory-coalescing pattern, local-memory usage, and vectorization width all land in a reasonable spot on hardware they were not tuned for — and those parameters are architecture-specific by nature. In our experience, teams discover the gap between these two properties late, usually after a “portable” prototype is greenlit and someone finally profiles it on the second vendor. The code ran. The throughput was half of what the same silicon delivered on a vendor-tuned path. Nothing was broken; nothing was fast. That is the agnosticism trap in one sentence. API portability versus performance portability The cleanest way to hold this distinction is a side-by-side. Both are legitimate goals; they are not the same goal, and a solution can satisfy one while failing the other. Property API portability Performance portability Question it answers Does the code compile and run correctly here? Does the code run well here? What delivers it OpenCL / SYCL / Vulkan compute runtime present on target Architecture-aware tuning of the same kernel per target Failure symptom Build error, missing runtime, wrong result Correct result, throughput far below the target’s achievable peak How you detect it It won’t compile / won’t run Only by profiling against a vendor-tuned baseline Cost to close the gap Install the runtime, fix the build Per-target kernel tuning and validation The trap lives in the bottom-right cell. A build that succeeds gives a loud, visible signal; a kernel running at 40% of what the hardware can do gives no signal at all unless you measure it against a reference. This is exactly the pattern that shows up when porting between GPU APIs — the mechanics of which we cover in CUDA vs OpenCL and what each means when porting AI workloads. The compile step is the easy 80%; the tuning step is the expensive 20% that determines whether agnosticism was worth it. There is a useful precedent outside the GPU world. CPU SIMD portability has wrestled with the same problem for two decades: code written for one vector-instruction width does not automatically exploit a wider one. We drew that parallel in what CPU SIMD portability teaches about performance-portable code, and the lesson transfers directly — portable and performant are orthogonal until you deliberately engineer them together. How much performance do you trade to stay vendor-neutral? This is the question that matters for the decision, and the honest answer is: it depends on the workload, and you should measure it rather than assume it. What a well-scoped agnostic solution gives you is not a fixed number but a documented delta per hardware class — the throughput you achieve on each target expressed as a fraction of what a vendor-tuned path would achieve on the same silicon. The size of that delta is dominated by how memory-bound the kernel is. A compute-heavy kernel that spends most of its time in the arithmetic units tends to port with a small penalty, because the arithmetic looks similar across vendors. A memory-bound kernel — one whose speed is set by how well it coalesces global-memory accesses and uses local memory — is where the divergence concentrates, because those patterns are tightly coupled to each architecture’s cache hierarchy and memory subsystem. Consider a worked example, framed illustratively. Suppose a fused attention-style kernel achieves 90% of achievable throughput on the vendor it was tuned against. Ported unchanged through a portable API, it might land at 55–70% on a second vendor and lower on a third — not because the API failed, but because its tiling and local-memory layout were shaped by the first architecture’s characteristics. Per-target tuning can often recover most of that gap, but “can recover” is engineering work, not a property of the abstraction layer. The number you should insist on seeing is the post-tuning delta on each target, not the pre-tuning one. That delta is the currency of the decision. It lets you weigh a concrete portability cost against the concrete cost of single-vendor lock-in — the migration you would otherwise have to fund if that vendor’s pricing, supply, or roadmap turned against you. When the delta is documented per hardware class, the decision is auditable rather than assumed. This is the same traceability discipline we bring to the broader GPU engineering and performance work — a claim you can measure beats a claim you have to trust. Which technologies actually deliver agnosticism — and where do they leak? Three portable compute stacks come up in almost every vendor-neutral conversation. Each delivers real API portability. Each also leaks vendor-specific assumptions in predictable places, and knowing where the leaks are is what separates a scoped strategy from wishful thinking. OpenCL is the broadest common denominator: it runs across AMD, Intel, and NVIDIA GPUs, FPGAs, and CPUs. The leak is that optimal work-group sizes, preferred vector widths, and local-memory budgets differ per device, so a kernel tuned for one vendor’s occupancy model underperforms elsewhere unless it queries device parameters at runtime and adapts. SYCL (via implementations such as Intel’s oneAPI DPC++ and AdaptiveCpp) raises the abstraction to single-source C++ and is strong on developer ergonomics. The leak is the same underlying one — the C++ hides the kernel-launch details, but the launch parameters still map onto architecture-specific execution resources, so performance portability is not free just because the source is unified. Vulkan compute offers the most explicit low-level control and the widest device reach, including mobile GPUs. The leak is that the explicitness pushes tuning decisions — descriptor layouts, workgroup dimensions, memory barriers — onto the developer, so the same shader can be well-tuned on one target and pessimal on another. The pattern across all three is consistent: the API guarantees the code runs everywhere and quietly leaves the runs well problem to the engineer. That is not a defect of these stacks — it is a structural property of hardware abstraction. Vendors’ memory subsystems, cache hierarchies, and scheduling models genuinely differ; no abstraction can erase a difference the silicon insists on. The honest framing is that these technologies deliver portable correctness by design and portable performance only when you invest in per-target tuning on top. How do you validate that an agnostic solution performs — not just compiles? Validation is the part teams skip, and it is the part that turns a claim into evidence. The discipline is straightforward to state and easy to under-fund: you measure each target against a reference, not against itself. Use this as a diagnostic rubric before accepting any vendor-neutral compute claim: Establish a per-target achievable baseline. For each GPU in the target set, know what a vendor-tuned path achieves on the dominant kernels. Without this, a percentage of peak means nothing — you are comparing against an abstraction, not the hardware. Profile the portable path on every target, not just the reference one. A build succeeding on target B tells you nothing about its throughput on target B. Run the profiler on each device with a representative workload and realistic input sizes. Report the delta per hardware class, post-tuning. Document the achieved fraction of baseline on each target after any tuning has been applied. This is the number the decision hangs on. Separate compile-time from run-time portability. Confirm the code compiles everywhere and record where runtime queries adapt kernel parameters. A path that hard-codes work-group sizes is portable only until the next architecture. Re-validate on hardware refresh. A delta measured on last generation’s silicon does not carry forward. New architectures shift the memory and occupancy characteristics that the tuning depended on. This is precisely the scope of a GPU performance audit: quantifying whether a claimed agnostic solution delivers portable performance across the target hardware set, or only portable compilation. The audit exists because the failure mode — correct output at poor throughput — is invisible without measurement, and invisible failures are the expensive kind. If you are moving a workload between architectures at all, the mechanics of that move are worth understanding first; we walk through them in what software porting actually means when moving a workload to new hardware. FAQ What should you know about a hardware-agnostic GPU compute solution in practice? It uses a portable compute API — OpenCL, SYCL, or Vulkan compute — so one source codebase compiles and runs correctly across AMD, Intel, and NVIDIA hardware. In practice, “agnostic” reliably means the code runs everywhere; it does not automatically mean the code runs well everywhere, because kernel tuning is architecture-specific. What is the difference between API portability and performance portability? API portability means the same code compiles and produces correct results on multiple vendors’ hardware. Performance portability means it runs at an acceptable fraction of each target’s achievable throughput without per-target rewrites. A solution can fully satisfy the first while failing the second, and that failure is invisible unless you profile against a vendor-tuned baseline. How much performance do I typically trade to keep a GPU workload vendor-neutral across AMD, Intel, and NVIDIA? There is no fixed number — it depends on how memory-bound the kernel is and how much per-target tuning you invest. Compute-bound kernels port with small penalties; memory-bound kernels diverge more because their access patterns are coupled to each architecture’s cache hierarchy. The figure to insist on is the documented, post-tuning throughput delta per hardware class rather than an assumed constant. Which technologies actually deliver agnosticism, and where do they leak vendor-specific assumptions? OpenCL, SYCL, and Vulkan compute all deliver genuine API portability across vendors. Each leaks in the same place — work-group sizing, vector widths, local-memory budgets, and launch parameters map onto architecture-specific execution resources, so a kernel tuned for one vendor’s occupancy model underperforms elsewhere unless it queries device parameters and adapts at runtime. How do I validate that an agnostic solution performs acceptably on each target GPU rather than just compiling on it? Establish a per-target achievable baseline from a vendor-tuned path, profile the portable path on every target with a representative workload, and report the post-tuning throughput delta per hardware class. A successful build on a target says nothing about its throughput there; only measurement against a reference reveals the gap. Re-validate on every hardware refresh. When is a genuinely agnostic solution worth the tuning overhead versus a single-vendor path like CUDA? It is worth it when the documented portability cost is smaller than the migration cost you would face if a single vendor’s pricing, supply, or roadmap turned against you. If your workload is memory-bound, the tuning overhead is real and should be scoped explicitly; if it is compute-bound and the delta is small, agnosticism buys cheap insurance against lock-in. The decision is sound only when both the delta and the avoided migration cost are measured, not assumed. The question worth asking your compute vendor The next time a compute layer is described as hardware-agnostic, the useful follow-up is not “does it run on AMD, Intel, and NVIDIA?” — it almost certainly does. The follow-up is “what fraction of each target’s achievable throughput does it deliver, after tuning, and can you show me the per-hardware-class delta?” A vendor who has done the work can answer that in a table. A vendor who has only shipped portable compilation will answer with the compile matrix and hope you do not notice the difference. That gap — between a delta you can audit and a portability you are taking on faith — is where a GPU performance audit earns its keep.
