6 ms·
Glad to see more support for OpenGL, but I really hope we'll soon move to a compute-only way of handling graphics. The overhead of vulkan is absolutely insane (
by mschuetz 3y ago
Glad to see more support for OpenGL, but I really hope we'll soon move to a compute-only way of handling graphics. The overhead of vulkan is absolutely insane (and not warranted, in my opinion), and OpenGL is on its last legs.
Things like Nanite spark a little hope, since they've shown that software-rasterization via compute can be faster than the standard graphics pipeline with the hardware rasterizer for small, dense triangles. Seems like a matter of time until everything goes compute, even large triangles. Maybe the recent addition of work-graphs in DirectX is one step in that direction?
- kevingadd 3y agoIsn't nanite hardware rasterization with software shading? Like using the GPU to draw triangle/cluster ID #s into the FB and then shading those?
- Jasper_ 3y agoFor small triangles, they use a software rasterizer into the V-buffer. Obviously for 1px triangles since they don't want to waste quad overdraw, but I think they found it's faster up to 12px/tri or so on AMD.
- mschuetz 3y agoPart of Nanite is software rasterization by rendering triangles with 64 bit atomics. You can simply draw the closest fragment of a triangle to screen via atomicMin(framebuffer[pixelID], (depth << 32) | triangleData).
- zbendefy 3y agoIt uses the rasterization HW for large triangles and uses a software rasterizer in compute for small triangles. The HW rasterizer is not that efficient if the triangles are tiny, which is the case for nanite.
- baybal2 3y agoBut that is one generation of GPUs away when they will make some computational shortcut for small triangles, which to me seems to be rather trivial to implement.
- mschuetz 3y agoNot really trivial if you have to support any input set of triangles and don't know much about them. Software rasterizion exploits things like localized chunks of triangles, but the hardware rasterizer does not know about that in advance. Also, these kinds of software rasterization algorithms add limitations, which aren't much of an issue with your own rendering pipeline that specifically knows how to deal with these limitations and works with them.
- verall 3y ago> I really hope we'll soon move to a compute-only way of handling graphics Not happening anytime soon. The industry has lined up pretty solidly behind Khronos/Vulkan.
- mschuetz 3y agoI know it won't happen overnight, but since it's already possible to do software rasterization for small triangles faster than hardware, having a graphics API framework starts losing its purpose. After all, we want to have the detail of small triangles anyway. Just let us draw to the screen in CUDA without the need for OpenGL/Vulkan interop, and I believe we'll soon see a shift to serious compute-based real-time rendering. Basically, instead of graphics being a framework, I want graphics to be a straightforward library you include and use in your CUDA/HIP/SYCL/OpenCL code.
- vitaminka 3y ago> let us draw to the screen in CUDA without the need for OpenGL/Vulkan interop how would that work? like GPU frameworks would just be compute (like cuda) and some small component of it would just allow to write the end result to a buffer which would be displayed or smth?
- mschuetz 3y agoExactly. Things like that already work with a workaround: You can use Cuda-OpenGL interop to expose an OpenGL framebuffer in CUDA, then you can simply write into that framebuffer from your CUDA kernel, and afterwards you get back to OpenGL to display it on screen. Just directly integrate that functionality in CUDA by providing a CUDA native framebuffer and a present(buffer) or buffer swap functionality.
- pjmlp 3y agoThe industry targeting Android and GNU/Linux devices, that is.
- DeathArrow 3y ago
- littlestymaar 3y ago> The overhead of vulkan is absolutely insane (and not warranted, in my opinion) Would you mind expanding on this?
- mschuetz 3y agoI meant the development/learning overhead. With Vulkan you can do incredible low-level optimizations to squeeze every last bit of performance out of your 3D application, but because you are basically mandated to do it that way, you have a very harsh learning curve and need lots of code for the simplest tasks. I'd rather prefer approaches that make the common things that everyone wants to do easy (draw your first simple scenes), and then optionally gives you all the features to sqeeze out performance where you really need to. Because at least for me, I don't work with massive scenes with millions of instances of thousands of different objects. I do real-time graphics research, mostly with compute, and I'd just like to present the triangles I've created or the framebuffers I created via compute (like shadertoy). I'll readily admit, I'm neither smart nor patient enough for Vulkan so I quickly gave up and learned CUDA instead, because it was way easier to write a naive software-rasterizer for triangles in CUDA, than it was to combine a compute shader and a vertex+fragment shader in Vulkan. I'm just rendering a single buffer with ~100k compute-generated triangles, and learning Vulkan for that just wasn't worth it.
- DeathArrow 3y agoWell, then there's OpenGL and DirectX.
- mschuetz 3y agoYeah, 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.
- bogwog 3y ago> The overhead of vulkan is absolutely insane Overstatement of the year award candidate. Vulkan and OpenGL both already support mesh shaders, which is a compute-oriented alternative to the traditional rasterization pipeline.
- mschuetz 3y ago> Vulkan and OpenGL both already support mesh shaders, which is a compute-oriented alternative to the traditional rasterization pipeline. Mesh shaders are a step in the right direction, but they are still embedded in all that unnecessary Vulkan fluff. I would want these things in CUDA because it does the opposite approach of Vulkan - it makes the common things easy, and the hard/powerful things optional. Just let me draw things directly in CUDA, and maybe give access to the hardware rasterizer via a CUDA call.
- account42 3y ago> CUDA [...] makes the common things easy Only if the common thing does not include running on hardware of more than one vendor. Which is a pretty common requirement for any consumer software.
- mschuetz 3y agoYou're missing the point. CUDA is easy but also powerful, and it shows there is no reason that other APIs need to be hard and cumbersome.
- rsp1984 3y ago> Overstatement of the year award candidate. I think he meant development overhead, not performance overhead.
- mschuetz 3y agoYes, sorry for the confusion. I'd just rather have an API where the common things are easy, and the super powerful low-level optimizations are optional.
- ddingus 3y ago>but I really hope we'll soon move to a compute-only way of handling graphics. Would you have the time to expand on this thought a bit? I am curious. Thanks!!
- ori_b 3y agoSoftware rendering. In parallel on the GPU.
- NovaDudely 3y agoI mean, about 5 years ago there were many folks that were trying to do raytracing using GPU compute rather than the current methods, it was essentially treating the CPU as a giant parallel software rendered. The results were pretty good even then.
- zokier 3y agoRaytracing using GPU compute is pretty much the norm for offline rendering, for example Blenders Cycles renderer has support for all major GPUs: https://docs.blender.org/manual/en/latest/render/cycles/gpu_rendering.html https://docs.blender.org/manual/en/latest/render/cycles/gpu_... It is telling of the GPU compute landscape that there is separate implementation for each vendor
- adastra22 3y agoI don't get what that means. You mean configuring a shader to render pixels? How do you think OpenGL/Vulkan works under the hood? It's been a very long time since fixed function pipelines.
- deleted 3y ago[deleted]