Case-Study: V-Nova - GPU Porting from OpenCL to Metal
Dec 15, 2023
Case study on moving a GPU application from OpenCL to Metal for our client V-Nova.
Read moreA model that runs in a notebook is not the same artefact as one that runs on the device, the browser, the on-prem cluster, or the constrained edge box your customers actually use. The gap between those two artefacts is where AI projects stall: runtime mismatches, language ceilings, missing toolchains, lock-in to a particular cloud or accelerator. We treat that gap as an engineering problem with a defined target.
The Engagement Shape
Two gated phases. Feasibility (2–4 weeks, fixed-scope) produces a feasibility memo, a porting plan, a go / no-go recommendation, and a representative micro-benchmark on the target. Porting of 1 Workload (4–10 weeks, target-dependent) lands a working workload on the named target, a reproducible benchmark, a deployment runbook, and a risk-and-limit register. Pricing is fixed on Feasibility and milestone or fixed-price on the porting phase, against the working workload, the benchmark, and the runbook, not engineer-weeks against a porting backlog.
Four Target Surfaces
All four share the same engagement pattern (Feasibility, then Porting of 1 Workload) and the same outcome shape: a working workload, a benchmark, and a runbook. Target-specific constraints drive timeline and risk.
Novel Silicon
Accelerators
AI workload onto a new accelerator, SoC, or single-board computer: SDK, runtime, and driver gap closure, kernel work, benchmark instrumentation.
Edge & Embedded
Constrained
Constrained-target bring-up where memory, power, OS, or thermal envelopes drive the risk: runtime selection and benchmark against the operational envelope.
Browser & Edge-Client
Client-side
Client-side AI via WASM, WebGL, and WebGPU: porting to a browser-compatible runtime and profiling against the target browser and device matrix.
Python-to-Native
Rewrites
Python to C++ or Rust where the language ceiling, runtime cost, or distribution model makes Python untenable, with numerical parity validated against the baseline.
What the Runbook Is
The runbook is the deliverable that turns "we ported it" into something your team can defend and replay. Your team replays the benchmark on the target using the runbook and the numbers reproduce within an agreed tolerance, or we are not done. It travels with the workload, the same steps re-run on the next board revision or the next driver bump, alongside a risk-and-limit register that states what does and does not work in the operational envelope.
Not Sure This Is the Right Pack?
If the workload already runs on the target and the question is making it cheaper or faster, that is the Inference Cost-Cut Pack. If it runs but gives wrong answers or has no release gate, that is the Production AI Monitoring Harness. Porting proves runnable, the harness proves correct under load. If a committee needs LLM-comparison evidence, that is the LLM Selection Pack; if the question is readiness against a published rubric, the AI Readiness Scorecard.
Cross-API porting, Metal bring-up, and edge-target inference work. These engagements pre-date the packaged pack and stand as bridged proof.
Dec 15, 2023
Case study on moving a GPU application from OpenCL to Metal for our client V-Nova.
Read more
Dec 15, 2022
TechnoLynx improved V-Nova’s video decoder with GPU-based pixel processing, Metal shaders, and efficient image handling for high-quality colour images…
Read moreWhat portability across targets really takes: cross-platform GPU performance, WASM inference, and the inference-engine layer.
Jun 12, 2026
Portable GPU APIs translate code, not performance. What it actually takes to run fast on NVIDIA, AMD, and Intel from the same codebase.
Read more
Jun 12, 2026
WASM Python runs CPython compiled to WebAssembly. Understand the interpreter overhead, sandbox limits, and where it fits for inference before porting.
Read more
Jun 12, 2026
An inference engine is the layer that turns a trained model plus inputs into predictions.
Read moreTechnoLynx delivered the project on time and provided quality outputs that met the client's expectations. The team was proactive in providing ideas and suggestions, and they were careful at properly planning the tasks. The client also praised the team's expertise in GPU programming and AI.
TechnoLynx's skill in low-level software development was impressive. TechnoLynx was able to create four prototypes with common components and an interface for easy maintenance. The client was extremely happy with the solution's speed. Moreover, their communication was seamless and straightforward.
TechnoLynx's unique aspect is that they're able to transform complex theories into practicable and applicable results. TechnoLynx provides research reports and architecture planning documents. The team is able to transform complex theories into practicable and applicable results. TechnoLynx's project management is strong and delivers work on time without hardware issues, being responsive through virtual meetings.
I’m delighted with our collaboration with their team. Thanks to TechnoLynx's work, the client has been able to co-author two patents. They lead responsive project management to solve problems quickly. The team also praises their skilled and knowledgeable team.
We had high-efficiency meetings. TechnoLynx’s work resulted in a successful breakthrough, and their input improved the client’s app. Their flexible and organised project management cultivated a healthy collaboration experience. Ultimately, their professionalism and commitment were impressive.
When the AI path does not exist on the target yet, or runs only as a research prototype. If the workload already runs on the target and the question is making it cheaper or faster, that is the Inference Cost-Cut Pack. Porting exists precisely for the case where the path does not exist yet.
Four canonical surfaces: novel silicon and new accelerators or single-board computers; constrained edge and embedded targets; the browser and edge clients (WASM, WebGL, WebGPU); and Python-to-native (C++ / Rust) rewrites where the language ceiling or distribution model makes Python untenable.
Whether porting should proceed. In 2–4 weeks it produces a feasibility memo, a porting plan, a go / no-go recommendation, and a representative micro-benchmark on the target, so the larger porting commitment is made against evidence, not a hope.
Yes. The deliverable is a working workload on the named target, a reproducible benchmark, a deployment runbook, and a risk-and-limit register. Your team replays the benchmark using the runbook and the numbers reproduce within an agreed tolerance, or we are not done.
No. Porting proves the workload is runnable on the target. Proving it is correct under load (regression coverage, release gates, drift checks) is the Production AI Monitoring Harness, and the two often follow one another.
Start a Conversation
The AI-infrastructure / SaaS crosswalk routes porting-and-deployment work through this pack. Porting establishes runnability on the target; it does not certify or sign anything off against compliance standards.
If you have a named target (a silicon part, a board, a browser surface, a runtime), a representative workload, and someone who owns the question "can we ship this AI feature on this hardware?", contact us and tell us the target, the workload shape, and the deployment constraint you need to clear.