3 ms·
Yeah, but OpenGL doesn't get updates anymore. My timeline goes like: I needed pointers(and pointer casting) for my compute shaders so I checked the correspondin
by mschuetz 3y ago
Yeah, but OpenGL doesn't get updates anymore. My timeline goes like: I needed pointers(and pointer casting) for my compute shaders so I checked the corresponding GLSL extension, which was only available in Vulkan so I tried switching from OpenGL to Vulkan. After a week I gave up - the pointer/Buffer reference extension did not look promising anyway - and I tried out CUDA instead. That's when I found out that CUDA is the greatest shit ever. That's what I want graphics programming to be like. Since then I just render all the triangles and lines in CUDA, because it easily handles hundreds of thousands of them in real-time with a naive, unoptimized software-rasterizer, and that's all I need. In addition to the billion points you can also render in real-time in CUDA with atomics.
- cesarb 3y ago> That's when I found out that CUDA is the greatest shit ever. That's what I want graphics programming to be like. Something which requires you to buy new hardware from a specific brand, and load an out-of-tree binary-only module on your kernel? That's not what I want graphics programming to be like. The Vulkan API might be clunkier (I don't know, I haven't looked at the CUDA API, since I don't have the required hardware), but at least it can work everywhere.
- mschuetz 3y agoIt's the exact reason why I've avoided CUDA for years, but I hit a dead end with OpenGL and Vulkan, and CUDA happened to be a fantastic, easy and fast solution. Of course I don't want graphics programming to be NVIDIA-only, but I want it to be like CUDA, just for all platforms.
- pjmlp 3y agoExcept it doesn't work everywhere, far from it.
- adastra22 3y agoI'm confused by what you mean here by "software-rasterizer" when you are compiling it to run on the GPU. What do you think the graphics driver is doing when you program it with OpenGL? It's doing more or less the same thing under the hood. I guess you can technically call that software rasterization now that GPUs are very programmable. But it's not how the word is usually used.
- TazeTSchnitzel 3y agoGPUs have dedicated hardware for rasterisation. Using compute shaders to do it would be wasteful.
- adastra22 3y agoNot necessarily. I'm working on an application that does exactly that, as we are rendering spheres. It ends up being much more efficient to rasterize the sphere in a combination of vertex and fragment shaders than to instantiate triangles.
- mschuetz 3y agoNanite renders small triangles faster by avoiding the dedicated hardware and using compute, instead.
- TazeTSchnitzel 3y agoMicro-triangles are a special case and Nanite still uses the hardware for more reasonably sized triangles.
- mschuetz 3y ago"Turns out we can beat the hardware with triangles much bigger than expected, far past micropoly. We software rasterize any clusters whos triangles are less than 32 pixels long." - https://advances.realtimerendering.com/s2021/Karis_Nanite_SIGGRAPH_Advances_2021_final.pdf https://advances.realtimerendering.com/s2021/Karis_Nanite_SI... It's not just micro-triangles, it works for triangles that span multiple pixels. And that's not a special case, that's the standard nowadays, except for games targeting very low-end devices. The dedicated hardware is nice for general-purpose support for arbitrary triangle-soups. But if you structure triangles a certain way and have a certain amount of density (which you want for modern games), you can specifically optimize for that and beat the general-purpose hardware rasterizer.