Recent content by nAo

Damn, I wish I was down in CA! Enjoy GTC :-)

Both TensorRT and TensorRT-LLM are open source: https://github.com/NVIDIA/TensorRT https://github.com/NVIDIA/TensorRT-LLM

How big is MI300?

The idea of opening up the BVH formats is appealing on paper, especially for very simple HW implementations, but there is huge hidden cost in doing so. Once it's out, like with an ISA, you have to support it forever, on all past, present and future HW. This makes even less sense for something...

How would exposing a ray-triangle intersection instruction help accelerating Nanite? It would affect a fraction of some code that already is a relatively small fraction of the total frame time. Doesn't sound like much big of a deal. Moreover, would it really accelerate anything when it would...

DMMs are not based on this paper.

The fact it can achieve very high clocks on irregular workloads (blender?) where the CUs might be stalling a lot (i.e. not consuming as much power..) could suggest that it is using more power than expected. OTOH on gaming workloads clocks are lower because it's much better utilized and it's more...

It takes significant architectural effort to add 30% more cores and get 30% more performance. It ain't easy :)

Are there any numbers out there for the power overhead due to going with 6 chiplets for I/O?

The SER API is public, you can download the SER SDK and use it right away: https://developer.nvidia.com/blog/improve-shader-performance-and-in-game-frame-rates-with-shader-execution-reordering/ SER in-depth whitepaper...

Not all implementations are the same :)

I wouldn't call a 16 entry stack a short stack. There a few papers out there showing you can get great perf with fewer than 7-8 entries, for instance: https://www.embree.org/papers/2019-HPG-ShortStack.pdf

You don't go very far with pure brute force RT as the computational and bandwidth costs would be insanely high :)

No they don't. Whether upscaling is used or not the tensor cores also predict how to best fuse together the output of the optical flow generator with the optical flow/motion vectors coming from the application. It's well described here...

I am not sure I follow you here, but intersecting a triangle or an AABB should not be any worse, latency wise, than issuing a texture sampler instruction. AFAIR RDNA2 sends the ray and AABB/triangle data to the HW intersectors, so it's not like the latter have to fetch anything from memory...