8 ms·

I wonder, will we ever see (or is there already) the equivalent of a game engine on a chip? Like a ray-tracing rendering pipeline, where the polygons of a scene

by jcfrei 8y ago

I wonder, will we ever see (or is there already) the equivalent of a game engine on a chip? Like a ray-tracing rendering pipeline, where the polygons of a scene (and the position of the observer) are directly sent via a low-level API to the GPU and then it returns an image.

w0utert 8y ago
There are a lot of moving parts involved in making a full-featured path tracer, and they can have wildly varying performance characteristics. Some parts such as finding ray intersections in parallel and integrating them map extremely well to a GPU-like architecture, while others such as building and traversing a bounding-volume hierarchy are better suited for a traditional CPU (even though within certain constraints you can also do it on a GPU). The full rendering pipeline is much more than just finding ray-triangle intersections. It also involves material BRDFs/BSDFS (reflection/scatter properties), volumetric effects (fog, liquids, etc), motion-effects such as blurring, etc. Depending on what you are rendering, the render pipeline be vastly different from application to application. I think most production path-tracers are still primarily CPU-based, which would be because of the required flexibility.
zamadatix 8y ago
Sounds a lot like DXR (DirectX RayTracing) though that's high level it offloads the "go raytrace it" part to the Nvidia RTX API. These, and any solution that generates an image, need a shit ton more information to generate an image than polygons and where the camera is.
thedaemon 8y ago
There is much more to a game engine than rendering graphics. Networking, input handling, ai, collision, all kinds of stuff.
kllrnohj 8y ago
ray-tracing / path-tracing as a category tends to be very branch-heavy with non-local data. GPUs are able to be so insanely parallel because their workloads don't branch much (or rather, every "thread" takes the same branch) and their data is tightly packed. Think of a GPU like a dozen really, really basic in-order, non-speculating CPUs, each one with a stupid huge wide SIMD unit. As long as the data is nicely packed, doing the same operations on each unit of data, boom - turbo mega ultra fast. That's rasterization. That's pixel shaders. That's modern GPU workloads. ray-tracing, though? Rays bounce around. They branch. They don't all do the same thing on nicely packed data. This would be where something like the Xeon Phi coprocessor would fit the bill in theory. Although it looks like maybe it didn't pan out all that well as Intel seems to have killed that product line?

by jcfrei 8y ago

w0utert 8y ago

There are a lot of moving parts involved in making a full-featured path tracer, and they can have wildly varying performance characteristics. Some parts such as finding ray intersections in parallel and integrating them map extremely well to a GPU-like architecture, while others such as building and traversing a bounding-volume hierarchy are better suited for a traditional CPU (even though within certain constraints you can also do it on a GPU). The full rendering pipeline is much more than just finding ray-triangle intersections. It also involves material BRDFs/BSDFS (reflection/scatter properties), volumetric effects (fog, liquids, etc), motion-effects such as blurring, etc. Depending on what you are rendering, the render pipeline be vastly different from application to application. I think most production path-tracers are still primarily CPU-based, which would be because of the required flexibility.

zamadatix 8y ago

Sounds a lot like DXR (DirectX RayTracing) though that's high level it offloads the "go raytrace it" part to the Nvidia RTX API. These, and any solution that generates an image, need a shit ton more information to generate an image than polygons and where the camera is.

thedaemon 8y ago

There is much more to a game engine than rendering graphics. Networking, input handling, ai, collision, all kinds of stuff.

kllrnohj 8y ago

ray-tracing / path-tracing as a category tends to be very branch-heavy with non-local data. GPUs are able to be so insanely parallel because their workloads don't branch much (or rather, every "thread" takes the same branch) and their data is tightly packed. Think of a GPU like a dozen really, really basic in-order, non-speculating CPUs, each one with a stupid huge wide SIMD unit. As long as the data is nicely packed, doing the same operations on each unit of data, boom - turbo mega ultra fast. That's rasterization. That's pixel shaders. That's modern GPU workloads. ray-tracing, though? Rays bounce around. They branch. They don't all do the same thing on nicely packed data. This would be where something like the Xeon Phi coprocessor would fit the bill in theory. Although it looks like maybe it didn't pan out all that well as Intel seems to have killed that product line?