Devsh Graphics Programming

Want to learn 𝗖++ 𝗳𝗼𝗿𝘄𝗮𝗿𝗱 𝗽𝗿𝗼𝗴𝗿𝗲𝘀𝘀 𝗴𝘂𝗮𝗿𝗮𝗻𝘁𝗲𝗲𝘀? tempted to ask AI for an easy explanation? we tried "Gemini Pro" and "Claude Fable", not only they weren't able to teach it properly. their explanations were completely wrong and hallucinated. I'm ashamed to even post them here. Instead of going on circles promoting. watch this 1:30h masterclass by an expert "human" Olivier Giroux: https://lnkd.in/d_tpuRHv Please Please, before asking AI for anything. spent at least a minimum of 5 minutes thinking about it yourself. There is NO learning without failure and struggle! Go in the c++ spec. fail to understand the syntax, ask your mentors point of view. search for other humans perspective and writings.

What's the best way to 𝘀𝘁𝗿𝗲𝗮𝗺 𝘆𝗼𝘂𝗿 𝗶𝗺𝗮𝗴𝗲𝘀 𝘁𝗼 𝘁𝗵𝗲 𝗚𝗣𝗨 using modern graphics APIs? We benchmarked streaming thousands of 128x128 tiles for our Virtual Texturing system with different methods:  • Regular copyBufferToImage   • Using compute shaders to do the copy  • Using the new host_image_copy extension in Vulkan (promoted in 1.4 version)  • Using staging memory in different memory spaces (VRAM ReBAR, VRAM Staging, RAM, UNCACHED RAM) 𝗖𝗼𝗻𝗰𝗹𝘂𝘀𝗶𝗼𝗻? • Even though vulkan specification mentions host_image_copy could be potentially faster than staging method, we saw 2-3x slowdown on most of the hardware we tested on. Even with the MEMCPY_BIT  • Using a compute shader vs copy command of graphics queue didn't seem to make any meaningful difference. (Only use compute if you want to decode + copy in one go)  • 𝗙𝗶𝗻𝗮𝗹 𝗩𝗲𝗿𝗱𝗶𝗰𝘁: Just use an staging buffer, and the best place for your staging area seems to be in device accessible RAM. (make sure it's write-combined memory) Thanks to Abbas Garousi for writing the benchmark.

Our CAD renderer can draw 𝟭𝟬𝟬𝗚𝗕 𝗼𝗳 𝗱𝗮𝘁𝗮 on a GPU with only 1GB of VRAM without crashing! Yes, our system can handle 10-100GB of draw data through only 1GB of VRAM. But if we have to access all of that in a single frame, we constantly thrash the GPU cache and move data from the CPU to the GPU (because no data can stay consistent across frames). People tend to overestimate PCIe upload speeds. Normal PCIe speed for large contiguous transfers sits around 10-30GB/s depending on the hardware. That means pushing 10GB takes 𝟬.𝟯 𝘁𝗼 𝟭 𝘀𝗲𝗰𝗼𝗻𝗱 𝘁𝗼 𝗳𝘂𝗹𝗹𝘆 𝘁𝗿𝗮𝗻𝘀𝗳𝗲𝗿. In a CAD application, that completely destroys the interactivity engineers rely on. 𝗪𝗵𝗮𝘁 𝗰𝗮𝗻 𝘆𝗼𝘂 𝗱𝗼 𝗮𝗯𝗼𝘂𝘁 𝗶𝘁? If your app can spare the time to preprocess data, The standard solution is spatial acceleration structures paired with coarse-grained cpu culling to stream only relevant blocks into VRAM. And to handle extreme zoom-outs where the entire model is visible at once, you pair this with a Level of Detail (LOD) system. 𝗕𝘂𝘁 𝘄𝗵𝗮𝘁 𝗶𝗳 𝗮 𝘀𝗶𝗻𝗴𝗹𝗲 𝗳𝗿𝗮𝗺𝗲 𝘀𝘁𝗶𝗹𝗹 𝗲𝘅𝗰𝗲𝗲𝗱𝘀 𝘆𝗼𝘂𝗿 𝗩𝗥𝗔𝗠 𝗮𝗹𝗹𝗼𝗰𝗮𝘁𝗶𝗼𝗻? We recently found ourselves in a situation where we had to push a 1.3GB non-preprocessed frame through a strict 1GB (minimum requirement) VRAM allocation.  𝗧𝗵𝗲 𝗴𝗼𝗼𝗱 𝗻𝗲𝘄𝘀? Our auto-submit mechanism handled the overflow beautifully, automatically splitting the draw into two submits, making sure all relevant data is versioned and cached in VRAM 𝗧𝗵𝗲 𝗯𝗮𝗱 𝗻𝗲𝘄𝘀? it still meant we were pushing data across the bus every single frame: The PCIe transfer took ~100ms, while actually rendering the data took only 8ms! To fix this bottleneck, we have started aggressively packing our data using bitfields and introducing new instancing mechanisms into our renderer. If my calculations are correct, by the end of next week we’ll be down to ~600MB of data representing the exact same view. This allows the dataset to reside persistently in VRAM, avoiding constant copies and keeping the viewport interactive. Final Note: Remember that the foundation of any out-of-core rendering system relies on CPU being aware of what the GPU has in it's VRAM cache and making decisions about what to evict/free, and most importantly ensuring correct synchronization to avoid unwanted GPU crashes (will post about this in more detail soon, so stay tuned) This writing mostly applies to non-UMA devices with discrete GPUs.

𝗜𝗻 𝗖𝗔𝗗 𝗿𝗲𝗻𝗱𝗲𝗿𝗶𝗻𝗴, 𝗳𝗶𝗹𝗲 𝘀𝗶𝘇𝗲 𝗱𝗼𝗲𝘀𝗻'𝘁 𝘁𝗲𝗹𝗹 𝘁𝗵𝗲 𝘄𝗵𝗼𝗹𝗲 𝘀𝘁𝗼𝗿𝘆. A 1GB land survey DTM model on your disk doesn't sound scary. But when you decompress it for drawing, it can easily balloon into 𝟭𝟬𝗚𝗕 of system RAM. How do you render that when the user’s GPU only has 𝟮𝗚𝗕 𝗼𝗳 𝗩𝗥𝗔𝗠? We've spent the last 4 years developing a GPU-driven renderer for #n4ce; Rendering in CAD means you don't control the data; you can't spend time optimizing assets like Game Developers do. Engineers are constantly modifying the dataset and innovating. They don't want to wait for long loading bars; They want to start working on their designs and view their surveys instantly. So, what happens when a georeferenced dataset physically exceeds your VRAM budget by 5x and you can't render your model all at once? 𝗧𝗵𝗲 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻: We implemented a mechanism to chop up massive scenes into multiple drawing submits. But that's not as easy as it sounds! There are complex data-dependencies and different memory life-spans for different types of data (e.g., Image Cache vs Raw Geometry Data). Building a GPU-driven renderer capable of this scale meant completely rethinking the pipeline. In the next post, I’ll break down exactly how we moved our curve rendering logic to the GPU, achieving a 𝗺𝗮𝘀𝘀𝗶𝘃𝗲 𝟮𝟱-𝟭𝟬𝟬𝘅 𝗿𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗶𝗻 𝗺𝗲𝗺𝗼𝗿𝘆 𝘀𝗶𝘇𝗲 while getting infinite zoom polylines in the process. Stay Tuned! We’ve already presented the architecture behind some of our solutions. You can find our presentations and learn more about our work on our website: https://www.devsh.eu/ #CAD #Vulkan #GraphicsProgramming #ComputationalGeometry