Apple doesn't sell any products with NVidia RTX hardware.
Yet still they feel the need to re-invent the wheel and write an API for it. I guess they really want to maintain that competitive moat.
Yet still they feel the need to re-invent the wheel and write an API for it. I guess they really want to maintain that competitive moat.
Is not realtime. You could find an article on raytracing and code something in a weekend. Granted, POV-Ray is vastly more complex than a toy raytracer, but it is not realtime. It takes minutes to hours to render a single frame.
"Computers have been around for years, punch-card mainframes have been great at universities for decades even."
NVidia are, currently, the only vendor who have dedicated silicon for it (AMD have demonstrated DXRT working with existing silicon).
They do a actually have a secret sauce.
Nobody is, DXRT is a specification that any vendor is free to choose how they implement. NVidia are the only vendor who currently implement it.
Metal is Apple's realtime API, and seeing as DirectX doesn't run on Macs, they'll need an API for raytracing in order to take advantage of ray tracing hardware, just as Vulkan did.
Probably first in the thinnest of Macbooks as a way to test the waters and buy some more time.
The same way GPUs had dedicated logic for rasterisation to make that super fast (hierarchical z-buffering, interpolation and blending), now they have some for ray tracing.
Raytracing is a not a problem that is well suited to GPUs since there are lots of data dependencies, which means parallelism is severely limited.
Nobody in this thread or anywhere else said there was.
> Raytracing is a not a problem that is well suited to GPUs since there are lots of data dependencies, which means parallelism is severely limited.
...no it's the classic example of an embarrassingly parallel problem - that's literally the term people use because it's so easy to parallelise. Each pixel is completely independent with no data or control dependency between them and they can be rendered in parallel.
However, each machine will be executing entirely different instructions after a very short period - there's not much "coherency" between adjacent rays, because all it takes is to clip the corner of an object and suddenly you're bouncing around a completely different part of the scene. This is a difficulty for GPUs, which are not true parallel clusters. What they do well is running the same set of calculations on different data, at the same time - in other words, not raytracing. I believe this is what the parent meant by "data dependency" - there are a lot of divergent branches, and the calculations that you do depend entirely on scene data.
Intel's Larrabee architecture would have made GPUs behave like genuine clusters. I think it's a bit sad we don't have general-purpose clusters in our machines, just the hobbled GPUs.
Even in path tracers that aren't using the GPU, one of the relatively recent huge improvements was "ray sorting", which tries to collect rays into bundles that use the same shader and roughly the same area of textures to improve on cache behavior. It brought huge speed increases.
One of the big limitations of NVIDIA's RTX right now is that it does not support ray sorting.
https://www.anandtech.com/show/7870/imagination-announces-po...
But there wasn't enough interest in GPU path tracing yet.
And raytracing is a problem that is well-suited to GPU acceleration...ray calculations can be easily run in parallel and distributed.
This is a joke right? I mean ray tracing is the most common example pointed at as being highly amenable to parallel computation. all ray computations are independent (i.e cores), all scene and BDRF data are shared - this matches GPU architecture perfectly, the only reason it's more of a recent trend is because even with parallel compute it's still demanding for real time performance.
If you don't believe me you can go to shadertoy right now and see endless demos doing raycasting and pathtracing in a quad.
Which makes it ill-suited to GPUs since they want sibling threads to take the same execution path on cache coherent data. Better than a quad core CPU sure but a very small fraction of the performance they're otherwise capable of.
You can see this with the DXR performance on Pascal vs. Turing.
Pathtracing software has been available for production use on GPUs for years before RTX was available.
Even in games, raytracing has been in use for a long time in various forms.
Yes RTX enables extra optimizations and provides nice APIs for it to boot, but it doesn't enable the technology as a whole. It's very much existed in realtime for a long time and on GPUs for a long time as well.
The real coup if anything is denoising. Advances in denoising are actually what really push realtime pathtracing forward as you no longer need to fire as many rays to converge on a useable image.