3 ms·
This is an interesting aside: > GPU rendering: This should be a big one, PBRT-v4 obviously does this as some of the mentioned renderers above. It should be ver
by brundolf 6y ago
This is an interesting aside:
> GPU rendering: This should be a big one, PBRT-v4 obviously does this as some of the mentioned renderers above. It should be very well possible to follow them and use Optix to render on a graphics card but I would much prefer a solution not involving closed source. Which would mean that you have to implement your own Optix. :\ But looking at how CPUs and GPUs are evolving it might be possible in a distant future to use the same (Swift) code on both of them; you can have instances with 448 CPUs in the cloud and the latest GPUs have a few thousand micro-cpus, they look more and more the same.
I'd be really excited for this future. One of the main reasons I haven't delved into GPU programming for fun is that I don't really like the available language(s). It seems petty, but the language I'm using makes a huge difference in the fun-factor for me.
- dahart 6y agoTry glsl, like on shadertoy.com, for a high fun-factor intro to GPU programming. I enjoy coding in Python and JavaScript more than I enjoy coding in C++ or CUDA, if I'm looking only at the language itself, but I have to admit that it's also very fun to make something run 100 or 1000 times faster than it did before. That kind of fun helps me overlook language differences. To me the quote sounds pretty funny, because a cloud of 500 CPUs running Swift, right now, is way more expensive and way less efficient than a single GPU. The current generation of GPU have over 10k single-thread cores...
- jb1991 6y ago> To me the quote sounds pretty funny, because a cloud of 500 CPUs running Swift, right now, is way more expensive and way less efficient than a single GPU. The current generation of GPU have over 10k single-thread cores... The number of threads in a GPU cannot be compared to the number of CPU threads or CPUs, especially in 3D rendering. CPU threads are vastly more independent and powerful than those on a GPU. GPU thread divergence places significant burden and limitations on the design of GPU kernels. Memory bandwidth is very costly as well. This is a very active and open research area for 3D rendering, and this Disney scene is designed to test those limitations (among other things). There is a reason why most of the 3D animated movies you see were rendered on CPUs.
- dahart 6y agoThose are good points, however 3d rendering is one domain where it does makes some sense to compare CPU & GPU threads, especially 3d game rendering. You certainly can compare threads between CPUs and GPUs for fp32 performance, if you have a pure compute workload without divergence. I work on OptiX, BTW, so I’m biased there, but there is also a reason why most commercial renderers are steadily moving toward the GPU. I predict it won’t be long before your statement flips and most CG movies are rendered on GPUs.
- adamnemecek 6y agoYou mean the shading language? You should check out Metal the language is nice. The WebGPU shading language is close to it.
- pjmlp 6y agoNot really, that was the initial proposal from Apple. WebGSL doesn't share anything with the C++14 based Metal Shading Language. https://gpuweb.github.io/gpuweb/wgsl.html https://gpuweb.github.io/gpuweb/wgsl.html Actually it even seems to have a Rust flavour to it.
- adamnemecek 6y agoWhere do you see the Rust influence?
- pjmlp 6y agoRight on the first example, fn main() -> void { gl_FragColor = vec4<f32>(0.4, 0.4, 0.8, 1.0); } There are more thorough the documentation.