TraverseResearchWork with us
Menu

Traverse Research

SDK development for hardware vendors

The library a developer actually meets: C++ or Rust SDKs, bindings and small standalone samples that show what your hardware does well, built by a team that has been on the integrating end of a great many of them.

Evolve, our GPU and AI benchmark, is where much of this practice was learned.
Evolve, our GPU and AI benchmark, is where much of this practice was learned.

The SDK is where your hardware is judged

A feature in silicon reaches a player through a developer who had to adopt it, and what that developer meets is not the architecture but the library. If the header is awkward, the sample does not build, or the integration path is undocumented, the capability may as well not be there. The gap between what hardware can do and what ships using it is usually made of exactly this.

We build that layer for hardware vendors: the C++ or Rust SDK, the bindings around it, and the documentation that says how it is meant to be used. We are not the team that designed the hardware, which is the point - we meet the same friction your customers will, because we do not already know how it works.

Small samples that build on their own

The most useful sample is a small standalone one. A single program, a couple of files, no engine to install and nothing to configure, that shows one capability clearly and compiles the first time. A developer evaluating your hardware will spend an afternoon on it, and that afternoon decides a lot.

That is deliberately harder than it sounds. Keeping a sample small means being opinionated about what it leaves out, and keeping it building means owning it past the release it was written for. We write them to be read as well as run, because the code is the documentation most people actually use.

Best practice, learned by integrating

What belongs in the guidance is not a list of API calls but the shape of the work: how to feed the thing, where the costs sit, what to do when the hardware is not there, and which of the obvious approaches is the slow one.

We know that because integrating is most of what we do. Evolve, our GPU and AI benchmark, is a production codebase running across PC and Android hardware; our Breda framework is where techniques get implemented and compared; and our partner work puts vendor SDKs into real renderers, which is where an SDK's assumptions show. We also maintain public Rust bindings to four vendors' neural and upscaling interfaces, so the integrator's view of this is not theoretical.

Start a conversation · Benchmarking and GPU workloads · The Arm integration account · Evolve.

A few useful answers.

C++ or Rust?

Either, and often both. A C API with a thin C++ layer is still what most engines expect; Rust bindings on top of it reach a growing part of the ecosystem, and we maintain several such crates publicly.

Do you work on an SDK that already exists?

Yes, and that is the more common request. An existing SDK usually needs samples, bindings or an integration path more than it needs rewriting.

Why not have your own driver team write the samples?

They can, and they should be involved. What an outside team adds is the integrator's perspective: we hit the same friction your customers will, because we are not the people who already know how it works.

Can you work before the hardware ships?

Yes. Our hardware practice began with a pre-silicon benchmark suite for Imagination Technologies, and SDK work has the same shape: the library and its samples want to exist before the silicon is public.

Does this stay confidential?

Yes. Publication boundaries are agreed with the partner, and plenty of this work never carries our name.

Traverse Research + Traverse Games

Let’s turn a good question into working software.

Start a conversation