8 ms·
Imagination GPUs now support OpenGL 4.6
- mschuetz 3y agoGlad 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]
- shmerl 3y agoGood to see Zink now provides OpenGL over Vulkan for smaller GPU makers. I wonder if big ones will also eventually use it for it.
- snvzz 3y agoI suspect that, by now, the only reason the other mesa3d opengl drivers exist is historical. If these vendors came up with different enough hardware to need a new driver from scratch, they'd just focus on Vulkan and use Zink for opengl. After all, opengl is a relatively high level API. It is sensible to implement it in a hardware-independent manner on top of Vulkan.
- anthk 3y agoNo, not even close. On Intel in some chipset(s) Vulkan is not as performant as OpenGL 4.6. Gallium3D with Iris it's the future against the old pipeline, tho. For instance, I get OpenGL 2.1 in my netbook with the new drivers, 1.4 with the old ones instead.
- clhodapp 3y agoThe big players will probably switch once we get to the point that nothing still running on OpenGL needs optimally efficient usage of the GPU (either because it's old or because it was never performance-critical to start with, such as a student project).
- bangonkeyboard 3y agoI had to double check that OpenGL 4.6 (released in 2017) really still is the latest version.
- andrewstuart 3y agoWhat is this? This company makes GPUs?
- snvzz 3y ago>This company makes GPUs? Yes, and they've been around for a while. If you're old enough, you might remember the name "PowerVR". Today, they mostly license GPU designs to SoC vendors. You'll find their designs in e.g. Android phones. Notably, JH7110 (RISC-V SoC used in VisionFive2 and Star64) uses one of their recent GPUs.
- vitaminka 3y agodoes this mean you can run, say, modern openCL code on smth like a VisionFive2?
- snvzz 3y agoOomph-wise, they claim a good 4x over what the Raspberry Pi 4/400 have. Note that rPi's is known to be anemic due to serious memory bandwidth bottlenecks, barely able to keep up with filling a 1080p screen. Currently they do not support the specific variant used in JH7110, but they seem to both be variants of the same architecture. JH7110 has the BXE-4-32MC1[0], whereas the driver currently supports the BXS-4-64-MC1[1]. No idea about compute, and AIUI openCL suport in mesa3d is still a disaster for all drivers. 0. https://www.imaginationtech.com/product/img-bxe-4-32-mc1/ https://www.imaginationtech.com/product/img-bxe-4-32-mc1/ 1. https://www.imaginationtech.com/product/img-bxs-4-64-mc1/ https://www.imaginationtech.com/product/img-bxs-4-64-mc1/
- FullyFunctional 3y agoI'm curious how you can tell that it was BXS-4-64-MC1 that was supported. I looked and couldn't find that. Besides the JH7110 there's TH1520 and it's using the BXM-4-64-MC1, also not supported, but 2X the speed of BXE-4-64-MC1 if I understand it correctly.
- 3y ago
- loufe 3y agoI don't mean to detract from the technical merits of this at all, but for those not aware you might be interested to know that ImaginationTech is a Chinese-owned firm.
- speed_spread 3y agoIt's nice to see Chinese tech embrace existing standards. There are a lot of chips that are very poorly documented and supported by abysmal proprietary SDK. The software part of hardware is so often an afterthought yet it is also what makes or breaks the product.
- monocasa 3y agoThey're a British tech company, simply owned by a Chinese private equity fund. And they're sort of known for historically being very anti open source and their SDK difficult to continuously integrate into a larger product.
- vitaminka 3y agoreally no better than a us tech firm, unless you for some reason have a preference for nationality characteristics of your hardware backdoors lol
- localplume 3y ago[dead]
- snvzz 3y agoI am hopeful this will help mesa3d support with RISC-V SoCs such as JH7110 (and thus VisionFive2 and Star64) be excellent.
- rjsw 3y agoThere are links from the blog post to the Mesa sources and to a Linux tree containing their DRM kernel driver.
- snvzz 3y agoI am aware. Currently they do not support the specific variant used in JH7110, but they seem to both be variants of the same architecture. JH7110 has the BXE-4-32MC1[0], whereas the driver currently supports the BXS-4-64-MC1[1]. 0. https://www.imaginationtech.com/product/img-bxe-4-32-mc1/ https://www.imaginationtech.com/product/img-bxe-4-32-mc1/ 1. https://www.imaginationtech.com/product/img-bxs-4-64-mc1/ https://www.imaginationtech.com/product/img-bxs-4-64-mc1/
- andrewstuart 3y agoI didn't know any other companies made GPUs. You'd think some hardware player would buy them to get a foot in the GPU/AI game. Are these GPUs fully open source?
- londons_explore 3y agoThey're closed source. Just parts of the driver are opensource. Note that these GPU's are widely used in (mostly low end) phones, and I think power the UI in some other household items with screens. They provided iPhone GPU's till 2017 (and there is debate if Apples new GPU might contain some imagination tech)
- andrewstuart 3y agoClosed source. That’s just crazy. If there’s anything a minor GPU player needs its community support.
- zokier 3y agoCrazy is that they were aggressively anti-foss even with their drivers not too long ago. Intel graphics usually has good Linux support, except for GMA500 which was based on Imagination tech. N900 was the Linux darling phone, and the graphics drivers where god-awful buggy blob from Imagination. And so on..
- nsteel 3y agoFor a company who historically has mostly made GPUs for phones and set-top boxes, I don't think that's true. People don't usually program these devices at this level. Especially in the case of all the hardware they did for Apple, no requirements to be open there. Maybe these days that's changing but it's a big change for a company like this to embrace.
- scq 3y agoNo, they're not open source at all. Their business model is to license the GPU IP block to other companies to integrate into their own chips. It's worth noting that Imagination designed the GPUs used in iPhones up until the iPhone 8 when Apple switched to their own design.
- SilverBirch 3y agoIs ImgTec back as a real going concern? Last I heard (back in 2016 or so) they'd basically lost the Apple GPU work (Apple opened up an office one town across, poached a load of engineers and bought the design work in house), and since then have been desperately trying to pivot to vision or VR of AI, but I've not heard of them having much traction.