Image Credit: Model created by Martin Lubich
“Embree: A Kernal Framework for Efficient CPU Ray Tracing” was awarded a SIGGRAPH 2025 Test-of-Time Award, given to Technical Papers that have had a significant and lasting impact on the computer graphics and interactive techniques over the last decade. This paper introduces the Embree system and describes in detail what it takes to build a professional-grade modular ray tracing framework. It achieved state-of-the-art performance with a simple and elegant architecture and came with an open-source implementation that has been adopted by many since then. We connected with Ingo Wald and Sven Woop, two of the authors of the original paper, to learn more about how this work has carried a lasting impact.
SIGGRAPH: Congratulations on your Technical Papers Test-of-Time Award. Can you explain the core idea behind your research, and what problems you were trying to solve at the time?
Ingo Wald (IW): This question is actually much harder to answer than you think, because I am only the first author of that one specific paper, but Embree as a project is about much more than just that one paper.
Now before I say anything else, I want to clarify some terms, and this is important: Whenever I’m going to say “ray tracing,” I refer to only the part of a renderer that performs “traversal and intersection” (T&I), i.e., the part that traverses one or more ray(s) through an acceleration structure, intersects those rays with geometric primitives, and determines which primitive(s) each ray intersects. I am not talking about the “rendering” component that determines which rays to shoot, how to sample, shade, etc.
Now, back to the above question: To fully understand the impact that Embree has had, you need to look at what the world looked like before it existed and what else was going on at that time. On one hand, ray tracing as a core technology was already well established at that time — there were not only hundreds of papers on “ray tracing,” there were also dozens of (offline) ray tracing-based renderers, most of which had very sophisticated implementations of that T&I component.
However, generally speaking, at that time each renderer had it’s own ray tracing back end; this back end was typically tightly interwoven with the rest of that renderer, often with lots of “secret sauce” specific to that renderer; and in all of these cases, the ray tracing back end was only one of many pieces that the respective renderer had to care about. This setup limits not only how much manpower there was available to care for any one of these back ends, but also creates all kinds of constraints on what that specific back end could or couldn’t do.
On the other hand, in the early 2000s, there was a huge movement toward pursuing “real-time ray tracing” — specifically to develop even faster acceleration structure build, traversal, and intersection techniques by really leaning into low-level things like SIMD instructions, modern CPU pipelines, cache hierarchies, parallelism, etc. This resulted in some codebases that could trace truly impressive numbers of rays per second — but typically only for very specific types of rays with virtually non-existent shading, meaning these were largely irrelevant to the existing ray tracing-based renderers.
The original goal of Embree then — which was mostly driven by Manfred and Sven — was to try to find some middle ground, to determine which one of the insights and algorithms developed in the quest toward real-time could possibly be carried over toward the kind of rays that the existing, practically relevant renderers of the days might actually want to be shooting. Initially, the project was some sort of “reference renderer” that targeted both T&I and shading and sampling as well, similar to, say, PBRT.
However, this “reference implementation” could only go so far. Eventually we decided to focus on only the T&I part, package that behind an API, and turn it into an actual open source library that existing renderers could then integrate. Renderers then still had to deal with their own shading and sampling, but that was hard to accelerate, anyway, because in that respect every renderer was wildly different. But for the actual T&I component — if one was willing to blink just hard enough — one could at least imagine a world where many different renderers might all possibly agree on a single shared API for that T&I component. And if that was possible, then one would get economies of scale, where every feature, optimization, or bug-fix would suddenly be useful to many rather than just one; and where — through that API — the back end had a much clearer view of what it could actually do. This model of using ray tracing through existing APIs — Embree, or nowadays also Vulkan, OptiX, or DXR — today is obvious and well established. At the time, it wasn’t.
The tricky part then was, in fact, not the implementation of any specific build, traversal, or intersection method; but finding the right abstraction level and feature set for such a library, because it had to walk this narrow ledge between leaving enough flexibility for the users to actually write their renderer on one hand and grabbing enough of the problem for the developers to actually have an impact on the other. An even bigger issue was to get end users to actually adopt this. This may sound like a no-brainer today, but at the time it wasn’t. Every renderer already had some pretty sophisticated ray tracing back end, and discarding something that has taken so much work to build is hard. Adopting a new API also requires rewriting the remaining parts of the renderer, and finding new ways to do the secret sauce; all of which is a lot of work. So, in order to make all this effort worthwhile for the user, the eventual benefits had to be great indeed — and it took a huge amount to a) build the thing that had these benefits and b) convince users to trust us in adopting this.
Sven Woop (SW): Embree was created to provide highly optimized, open source, and state-of-the-art ray tracing algorithms, with the goal to speed up existing rendering applications. The library provides all functionality required for production rendering, such as multi-segment motion blur and different types of curve primitives. We also defined an easy-to-use ray tracing API to simplify adoption. At that time such a library did not yet exist, with every renderer having its own ray tracing core. Embree allowed renderers to easily replace that ray tracing core with the benefit of higher performance and less code to maintain. Finding the right feature set to serve most renderers and implementing all these features efficiently was a challenging task.
SIGGRAPH: Having won the Test-of-Time Award, why do you think your work withstood the test of time? Were there aspects of the work that you thought were risky or ahead of time?
IW: The risky bit was that it wasn’t clear at all that practically relevant users would really adopt this. There was a good chance that everybody would just grab something here and something there — it was all open source, after all — and then all these codebases would diverge, and the vision of a single back end wouldn’t happen.
But it did. And why? Partly this is because people like Sven and Carsten (and others, too) have been really good at implementing the highest performing ray tracing kernels that gave rendering applications that integrated Embree speedups of around 2x. Also, it’s partly because we had some other projects where we used Embree, which helped in keeping the API balanced between the needs of users and developers, because we had both of those in the same group. Most important, though, it is because this splitting off of the ray traversal and intersection into a separate library is the right thing to do. It gives the developers of such a library the freedom to do things they might not have had otherwise. It allows for amortizing work across many different users. It makes for more stable code, and it gives economies of scale — and this is also why that model still works today. And last but not least, I think it worked because we — from the beginning — did this under and open-source umbrella, with the most permissible license we could find. This gave users the confidence to try it — because they always knew that even if we ever brought the project into a direction they didn’t like, or if we simply disappeared off the face of the earth, or even if they needed to add something themselves that we were not willing to add, then they always could.
SW: Embree withstood the test of time as it is a groundbreaking technical innovation with a profound and lasting industry impact. With Embree, we redefined the level of performance possible with CPU-based ray tracing, by leveraging vectorization, low level optimizations, and parallel algorithms to extract the most performance out of modern CPUs. This allowed for a speedup of ray tracing of up to 6x and a speedup of the entire rendering including shading of about 2x for rendering applications that integrated Embree.
This performance benefit and the open source aspect of the project helped to drive its wide adoption in the industry, with most major rendering applications using Embree today. A partial list of products using Embree can be found on the Embree webpage: https://www.embree.org/.
Embree is actively developed and maintained by Intel for over a decade now, with new features such as Intel GPU support being added recently. As of today, Embree still remains the state-of-the-art for CPU ray tracing, and Intel is committed to develop the library further in the future.
SIGGRAPH: ‘Embree: A Kernel Framework for Efficient CPU Ray Tracing’ focuses on performance-critical systems. What have you learned about writing modular, performant, and future-proof software that could benefit each other?
IW: There are, in fact, multiple such learnings I realized over the years.
One is that you need to pick a big enough problem to start with. If you want to have a measurable impact on total runtime, you cannot target something that only takes a few percent of total runtime, or the realities of Amdahl’s law will bite you.
A second is that it’s important to realize that there is always a conflict between generality and flexibility on one hand and performance on the other. The more you can constrain a problem, the easier it is to accelerate it — but if you constrain it too much, the user may no longer want to (or be able to) use it. This conflict is real, it is important, and you have to think about it every day. In that respect, I have found it is often useful to be your own user of that software, too, because that helps you see both sides.
A third one is that APIs are super important, and, IMHO, more important than the actual implementation. It is the designing of that API — in particular, the discussion of what will and what will not go into that API — that forces you to understand what your software is really supposed to be about. The common pitfall is to make the API too generous and too flexible. You should never add an API function or capability just because it would be “nice to have” — every additional function or capability of the API should be fought tooth and nail and only added if there is no other way to do it. An API should also hide as much as possible, because only then can you later switch things under the hood if and when it becomes necessary to do so.
Finally, I am a huge proponent of open source and permissible licenses. For Embree specifically — but also for other libraries I’ve worked on and still work on — the ability to see the actual code (and in particular, to just fork off this code whenever it might be required) raises confidence like nothing else possibly could.
SW: An important aspect of getting high performance was to design the data structures and algorithms around the SIMD instruction set. To leverage SIMD instructions we use wide BVHs as acceleration structure where four or eight bounding boxes can efficiently get intersected in parallel. A second aspect is not to trust your compiler, but better inspect the assembly code of the inner most kernel. A stable Embree API was also an important aspect to make the library future proof, in particular once various applications adopted Embree.
SIGGRAPH: If you had access to today’s hardware, data, or community resources when you wrote the paper, what would you have done differently or explored further?
IW: Others in the team might see this differently, but I’d say we’d probably have targeted GPUs more and earlier. But mostly, I’d argue Embree is still a good system for the kind of things it covers. I still use it on an almost daily basis.
SW: If we would start the project today, we would add GPU support from the beginning.
SIGGRAPH: These papers have become foundational in computer graphics research. What advice would you give to today’s researchers who hope to make similarly lasting contributions?
IW: For research in general, that’s hard to answer; I’m not even going to try. For systems-oriented research like Embree was, it’s still hard to answer, but the one thing that stands out is this: At the end, it’s the users who decide whether it gets adopted. It doesn’t matter how good you think your system is, not even how good it may actually be. You have to convince users to use your code, and that’s the first, second, third, and last thing you always have to think about.
SW: I would recommend focusing on problems that are not just interesting but have real-world applications. Also making your research or project widely available to others as open source can increase the impact of your research.
Thank you to Ingo and Sven for a great conversation about Embree. Do you want to be a part of computer graphics history? It starts with submitting your paper to SIGGRAPH! SIGGRAPH 2026 Technical Papers submissions are now open! Submit your work for a chance to showcase it in Los Angeles at SIGGRAPH 2026.
Ingo Wald is a director of ray tracing at NVIDIA, and adjunct Assistant Professor at the University of Utah. He received his master’s degree from Kaiserslautern University and his PhD from Saarland University (both on ray tracing-related topics). He then served as a post-doctorate at the Max-Planck Institute Saarbruecken, as a research professor at the University of Utah, and as technical lead for Intel’s software-defined rendering activities. Ingo has played a lead role in multiple widely used software projects (such as Embree, OSPRay, or OWL), has co-authored more than a hundred papers, and has received multiple awards for his work, including a Technical Achievement Award of the Academy of Motion Pictures for Embree. His interests revolve around all aspects of efficient and high-performance ray tracing, from visualization to production rendering, from real-time to offline rendering, and from hard- to software.
Sven Woop is a Principal Software Engineer at Intel responsible for researching, designing, and implementing high performance visualization and rendering algorithms for CPUs and the Intel® Xe GPU Architecture. Sven did start the award-winning Intel® Embree project, which implements highest performance ray traversal algorithm to speed up photorealistic rendering.
Sven holds a master’s degree in Computer Science and received his PhD on a hardware architecture for real-time ray tracing, both from Saarland University in Germany. Sven holds 22 patents and published 17 graphics papers at various conferences, including Siggraph.
His interest and expertise include computer graphics, hardware design, and parallel programming.
