CppCon 2017: Nicolas Guillemot “Design Patterns for Low-Level Real-Time Rendering”

[@scolic03]

10/10 talk, liked, shared on Facebook, subscribed, excitedly printed on A3 wallpaper, studied and revered! This kind of explanation only comes from a person knowing the subject matter intimately. A lot of hard work went into this talk and it shows. Thank you.

[@jankodedic3130]

This guy explains everything so well... Great talk!

[@broken_abi6973]

Janko Dedic as always!

[@OperationDarkside]

I would have needed these explanations far sooner. This was finally a version I understood. So many other tutorials and talks assume existing knowledge of graphics programming

[@satellite964]

This is the stuff I wanted to learn at Uni when I got my CS degree, instead I got put through OOP hell, I wasted time learning OOP stuff that I don't even use in real life. Also UML(overrated), a sprinkling of stuff like SCRUM and AGILE, all of which could've been picked up automatically from actually working in a firm. The math courses were worth it though.

[@k6l2t]

His proposal for the render graph abstraction layer was basically an OOP rabbit hole design though. There are no "free" abstractions.

[@sc0reBDO]

48:01 Stack allocator might be beneficial for this case. Basically it makes the memory allocated for T1 to be implicitly reused for OUT (due to nature of stack allocators). So sequence will be: [NEW T2] [NEW T1] [RUN A] [DEL T1] [NEW OUT] ...

[@PixelPulse168]

cppcon is awesome.

[@HuongNguyenXuan-r6t]

Amazing explanation methods!

[@jaredmistretta3018]

Great talk! Great ideas explained simply and concisely. Good job!

[@cgcode]

Thank you for your great talk!

[@CppCon]

Glad you enjoyed it!

[@greje656]

great talk!

[@Sychonut]

Interesting talk. Thanks for sharing!

[@TheLavaBlock]

Thanks for sharing. Great

[@infinitecmdz]

Since opengl context can be bound to one thread at a time, how does a fork, join thread of command list work?

[@guy1524]

OpenGL is high level

[@infinitecmdz]

dont understand, how is opengl high level here. The presenter said command list are opengl functions like glUseProgram, setting shader parameters etc. My question is since opengl context is only current for one thread at a time, how do you fork and join multiple threads?

[@nlguillemot]

It is possible to write OpenGL commands from multiple threads using multiple GL contexts, but you won't reap the benefits of multi-threaded command writing that exist in D3D12 and Vulkan. The closest thing in GL is NVIDIA's extension NV_command_list. Broadly, I think OpenGL has been designed to use multi-threading in a different way. Rather than using multi-threading to accelerate command list writing, you use multi-threading to accelerate operations on memory mapped buffers. This comes from the observation that even if you only have a GL context bound to one thread, the memory mapped pointers of its buffers can be freely passed to and accessed by other threads. So you can memory map a buffer, then spawn some tasks which each write a region of that buffer, and join them all when they finish their work. You can take this idea very far in the design of a very data-oriented rendering engine (see "Almost Zero Driver Overhead" GDC presentation). You can also do something similar to recording draw commands in this style, since you can write indirect draw commands to a memory mapped buffer from multiple threads (again, see AZDO talk for details.) Also, some OpenGL drivers internally use multi-threading to accelerate itself, so it's effectively trying to automatically do the things you would otherwise be doing manually in these lower level APIs. One benefit of these newer APIs is that you no longer depend so much on threads internal to the driver, although there still exist some things happening asynchronously beyond your control. For example, the system paging process manages operations for the GPU's page table asynchronously from your program, in an effort to transparently hide the latency of those operations.

[@infinitecmdz]

thanks for your detailed answer. The talk is amazing and i liked your explanation of ring buffers. Yes i have seen AZDO presentation and have used many if not all of the suggestions. have you had any experimentation on having data structures on the gpu that can simulate a scene graph and scene graph traversals?

[@nlguillemot]

I'm glad you liked the talk! With regards to your question, I'm wondering what your idea of a scene graph is, and what kind of operation you intend to do when traversing it. You can definitely use eg. a compute shader to traverse a data structure like that. If you want the GPU to feed itself with draw calls through that scene traversal, you can do that by writing to an indirect draw buffer from the aforementioned compute shader, and follow the compute shader by a call to eg. glDraw*Indirect. D3D12's indirect draw can let you take this one step further, since it also allows you to also switch shader parameters (like texture and buffer bindings and etc) through indirect commands. Some platforms also allow you to switch the currently bound pipeline state object itself through indirect draw commands. NVIDIA also has an interesting experimental Vulkan extension that gives you access to the command encoder from GPU code: developer.nvidia.com/driver-and-new-sample-vknvxdevicegeneratedcommands

[@raghul1208]

excellent

[@u28OO]

thx!

[@henrituhola]

Barely scratches the paint on the surface of the subject. I hoped to see some real code among it and not just those oversimplifications.

[@aleksijokinen9914]

There was a lot of ground to cover. Going any deeper would've needed multiple 1h talks. I think the talk was a really good high level overview.

[@N00byEdge]

Yeah another reason not to go into the code specifics is that each GPU API is very different. It is good to know how it works in general

[@MartinPreinfalk]

great talk!