8 ms·
Conformant OpenGL 4.6 on the M1
- ics 3y agoAnother upvote, another article I wish I had the knowledge and patience to understand better in context. Still, Alyssa's writeups are a fun read.
- randgoog 3y agoSame, I wish I knew more about graphics programming. It seems like such a steep learning curve though so I get discouraged.
- politician 3y agoThis is for Fedora on the M1. It would be amazing to get this for macOS. What's involved in pulling something like that off?
- fayalalebrun 3y agoPerhaps already possible via MoltenVK -> Vulkan -> Zink?
- Guzba 3y agoProbably needs one or two more layers just to be sure.
- jamesfmilne 3y agoUltimately they build command buffers and send them to the GPU. You'd need a way to do that from macOS. The original Mesa drivers for the M1 GPU were bootstrapped by doing just that, sending command buffers to the AGX driver in macOS using IOKit. https://rosenzweig.io/blog/asahi-gpu-part-2.html https://rosenzweig.io/blog/asahi-gpu-part-2.html https://github.com/AsahiLinux/gpu/blob/main/demo/iokit.c https://github.com/AsahiLinux/gpu/blob/main/demo/iokit.c So you'd need a bit more glue in Mesa to get the surfaces from the GPU into something you can composite onto the screen in macOS.
- shmerl 3y agoI think Apple bans third party kernel drivers? To write a proper Vulkan or OpenGL implementation you need a kernel counterpart for handling the GPU if I understand correctly. That's probably the reason no one bothers implementing native Vulkan for macOS. But if it's doable with Apple's driver - then not sure.
- skykooler 3y agoAccording to the devs, it isn't really possible due to Apple not having a stable public kernel API: https://social.treehouse.systems/@AsahiLinux/111930744188229065 https://social.treehouse.systems/@AsahiLinux/111930744188229...
- ribit 3y agoYou can implement an OpenGL driver on top of Metal. But why bother dedicating so many resources for the sake of a suboptimal legacy API?
- smoldesu 3y agoBecause it's a cross-platform framework that thousands of programs (including Mac exclusives) rely on? There's so much OpenGL-only software that it should be Apple's moral imperative to support it anyways. I don't think anyone can honestly say that the graphics situation on Mac has improved in the absence of cross-platform APIs. Even Apple admits it with the Game Porting Toolkit.
- ribit 3y agoAnd any of those Mac programs need anything more recent than 4.1? GL is legacy tech and Apple does offer legacy support. I just don’t see any reason to invest more work into this area. We should encourage people to stop using GL, not use it more. It’s bad technology.
- smoldesu 3y agoIdeally we encourage people to port to Vulkan instead of Metal and DirectX, so porting is easier and more people can run common software. Unfortunately, certain vendors have a reputation against third party Open standards.
- mort96 3y agoLegacy or not, OpenGL is the best cross platform graphics API we have that's actually practical for people to write directly. Metal is reasonable to write directly but not cross platform, Vulkan is cross platform but you need thousands of LoC to put a triangle on the screen.
- ryandvm 3y agoKind of crazy to think that the only reason OpenGL was ever a thing for 3D gaming was because of John Carmack's obsession with using it for Quake II back in the 90s.
- cmovq 3y agoI don’t know that it was the only reason, but Carmack’s push for OpenGL certainly helped. A lot of things related to 3D games are thanks to doom and Quake.
- pengaru 3y ago> A lot of things related to 3D games are thanks to doom and Quake. Quake sure, but Doom? IIRC Doom is far more like Wolf3D's 2.5D/raycasting than the "true 3D" of Quake, it cpu rendered to a frame buffer with zero hardware acceleration. I find it hard to believe it made any lasting impact on any subsequent 3D rendering APIs.
- Narishma 3y agoQuake didn't use hardware acceleration either. It was only the later VQuake and GLQuake releases that did.
- JohnBooty 3y agoI think for the purposes of this discussion "Quake" is acceptable shorthand for GLQuake, Quake 2, Quake 3, all the games that used those engines, etc.
- babypuncher 3y agoQuake got official 3D accelerated versions like GLQuake and VQuake. The improved visuals and better performance these versions offered drove a lot of early 3D accelerator sales in the consumer space.
- badsectoracula 3y agoIt also helped that the API was actually user friendly compared to the earlier versions of Direct3D.
- ConanRus 3y ago[dead]
- marcodiego 3y ago"Unlike the vendor’s non-conformant 4.1 drivers, our open source Linux drivers are conformant to the latest OpenGL versions, finally promising broad compatibility with modern OpenGL workloads, like Blender, Ryujinx, and Citra." Looks like apple silicon are currently the best hardware for running linux and linux is the best OS for apple silicon machines.
- Aurornis 3y ago> Looks like apple silicon are currently the best hardware for running linux and linux is the best OS for apple silicon machines Blender has Metal support for Apple Silicon macs. The Metal API is better architected (largely due to being more modern and being developed with benefit of hindsight) so all things equal I'd pick the Metal version on Mac. In case you missed it in the article, the M1 GPU does not natively support OpenGL 4.6. They had to emulate certain features. The blog post goes into some of the performance compromises that were necessary to make the full OpenGL emulation work properly. Absolutely a good compromise if you're on Linux and need to run a modern OpenGL app, but if your only goal is to run Blender as well as possible then you'd want to stick to macOS. Ryujinx is a Nintendo Switch emulator. They added support for Apple Silicon Macs a couple years ago and have been improving since then: https://blog.ryujinx.org/the-impossible-port-macos/ https://blog.ryujinx.org/the-impossible-port-macos/ Linux on Apple hardware has come a long way due to some incredible feats of engineering, but it's far from perfect. Calling it the "best OS for Apple Silicon" is a huuuuge reach. It's great if you need to run Linux for day to day operations, though.
- galad87 3y agoRight, Blender Cycles for example can run on Metal, but neither on OpenGL or Vulkan. So while it's nice to have a working OpenGL, it depends if your workflow requires OpenGL apps.
- vetinari 3y agoI would be very surprised, if Blender Cycles ever ran on top of OpenGL or Vulkan other than using OpenGL or Vulkan as a loader for compute shaders. That's why it is running as CUDA/OptiX/HIP/oneAPI on Windows and Linux.
- jauntywundrkind 3y ago> How do we break the 4.1 barrier? Without hardware support, new features need new tricks. Geometry shaders, tessellation, and transform feedback become compute shaders. Cull distance becomes a transformed interpolated value. Clip control becomes a vertex shader epilogue. The list goes on. I wonder how much of this work is in m1 gpu code, versus how much feature-implemented-on-another-festure work could be reused by others. This feels very similar to what Zink does (runs complex opengl capabilities via a more primitive Vulkan), except there is no Vulkan backend to target for m1. Yet.
- zozbot234 3y agoMore generally, you could execute complex OpenGL or Vulkan on some more-or-less arbitrary combination of CPU soft-rendering and hardware-specific native acceleration support. It would just be a matter of doing the work, and it could be reused across a wide variety of hardware - including perhaps older hardware that may be quite well understood but not usable on its own for modern workloads.
- breather 3y agoThis is obviously very exciting, but—why not target Vulkan first? It seems like the more salient target these days and one on top of which we already have an OpenGL implementation.
- wtallis 3y agoThey started with targeting older OpenGL to get a basic feature set working first. I guess from there, getting up to a more recent OpenGL was less work than doing a complete Vulkan implementation, and they probably learned a lot about what they'll need to do for Vulkan.
- breather 3y agoOk, this makes a lot of sense—OpenGL sort of forms a pathway of incremental support.
- simcop2387 3y agoAlong with that, it's more immediately useful as it's used for desktops and compositers still, so getting a useful environment necessitates it.
- shmerl 3y agoI thought something similar, but from their comments, to support OpenGL over Vulkan you need higher versions of Vulkan anyway and it's still a big effort. So they decided to go with (lower versions of) OpenGL first to get something functional sooner.
- mort96 3y agoOpenGL-on-Vulkan compat layers aren't magic. For them to support a given OpenGL feature, an equivalent feature must be supported by the Vulkan driver (often as an extension). That means you can't just implement a baseline Vulkan driver and get OGL 4.6 support for free, you must put in the work to implement all the OGL 4.6 features in your Vulkan driver if you want MESA to translate OGL 4.6 to Vulkan for you. Plus, this isn't Alyssa's first reverse engineering + OpenGL driver project. I don't know the details but I'd imagine it's much easier and quicker to implement a driver for an API you're used to making drivers for, than to implement a driver for an API you aren't.
- noiv 3y agoThis endeavour proofs to me skills beat talkativeness every single day. Just reading the blogs sets my brain on fire. There is so much to unpack. The punch line is not the last but the second sentence, nevertheless you're forced to follow the path into the rabbit hole until you enjoy reading one bit manipulation after the other. If there ever are benchmarks with eureka effects per paragraph Alyssa will lead them all. Just thanks!
- Wowfunhappy 3y ago> Regrettably, the M1 doesn’t map well to any graphics standard newer than OpenGL ES 3.1. While Vulkan makes some of these features optional, the missing features are required to layer DirectX and OpenGL on top. No existing solution on M1 gets past the OpenGL 4.1 feature set. I'm very curious to know the performance impact of this, particularly compared to using Metal on macOS. (I'm sure the answer is "it depends", but still.) It's possible the article answers this question, but I didn't understand most of it. :(
- gilgoomesh 3y agoThere isn't necessarily much difference between implementing features in driver compute code versus GPU hardware support. Even the "hardware support" is usually implemented in GPU microcode. It often goes through the same silicon. Any feature could hit a performance bottleneck and it's hard to know which feature will bottleneck until you try.
- ribit 3y agoAlyssa chooses some very odd language here, it seems to me. Yes, Apple GPUs do not support geometry shaders natively because geometry shaders are a bad design and do not map well to GPU hardware (geometry shaders are known to be slow even on hardware that allegedly supports it — there is a reason why Nvidia went ahead to design mesh shading). Transform feedback (ability to write transformed vertex data back to memory) is another feature that is often brought up in these discussions, but Apple GPUs can write to arbitrary memory locations from any shader stage, which makes transform feedback entirely superfluous. The core of the issue is that Apple chose to implement a streamlined compute architecture, and they have cut a lot of legacy cruft and things that were known not to work well in the process. I don't think that the rhetorics of "M1 getting stuck at OpenGL 4.1" is appropriate. I stopped following OpenGL many years ago, so I don't know specifically which features past 4.1 she might refer to. What I can say is that I'd be very surprised if there is something that OpenGL offers that cannot be done in Metal, but there are plenty of things possible in Metal that cannot be done at all in OpenGL (starting with a fact that Metal shading language has fully featured pointers).
- zdimension 3y agoAlyssa Rosenzweig is a gift to the community that keeps on giving. Every one of her blog posts is a guarantee to learn something you didn't know about the internals of modern graphics hardware.
- jokoon 3y agoOne day, Apple will deprecate opengl 3.3 core, and I guess everybody might end up deprecating it. I've read that generally opengl is just easier to use than vulkan, I don't know if that's true, but if something is too complicated, it becomes just too hard for less experienced devs to exploit those GPU, and it becomes a barrier to entry, which might discourage some indie game developers. Although everyone uses unity and unreal now, baking things from scratch or using other engines is just weird now, for some reason. It's really annoying, and it's fun to see gamedev wake up after unity tried to lock things more. Open source in gaming has always been stretched thin. Godot is there, but I doubt it's able to seriously compete with unity and unreal even if I want it to, so even if godot is capable, indie gamedevs are more experienced with unity and unreal and will stick to those. The state of open source in game dev feels really hopeless sometimes, the rise of next gen graphics API are not making things easy.
- taminka 3y ago> I've read that generally opengl is just easier to use than vulkan [here's](https://learnopengl.com/code_viewer_gh.php?code=src/1.getting_started/2.2.hello_triangle_indexed/hello_triangle_indexed.cpp https://learnopengl.com/code_viewer_gh.php?code=src/1.gettin...) an opengl triangle rendering example code (~200 LOC) [here's](https://vulkan-tutorial.com/code/17_swap_chain_recreation.cpp https://vulkan-tutorial.com/code/17_swap_chain_recreation.cp...) a vulkan triangle rendering example code (~1000 LOC) ye it's fair to say opengl is a bit easier to use ijbol
- zozbot234 3y agoThis is a bit misleading. Much of the extra code that you'd have to write in Vulkan to get to first-triangle is just that, a one-time cost. And you can use a third-party library, framework or engine to take care of it. Vulkan merely splits out the hardware-native low level from the library support layer, that were conflated in OpenGL, and lets the latter evolve freely via a third party ecosystem. That's just a sensible choice.
- MindSpunk 3y ago
- saagarjha 3y agoI find it very amusing that transitioning out of bounds accesses from traps to returning some random data is called “robustness”. Graphics programming certainly is weird.
- wtallis 3y agoIt makes sense from the perspective of writing graphics drivers, and aligns with Postel's law (also called the robustness principle). GPU drivers are all about making broken applications run, or run faster. Making your GPU drivers strict by default won't fix the systemic problems with the video game industry shipping broken code, it'll just drive away all of your users. And on hardware where branches are generally painfully expensive, it sounds really useful to have a flag to tell the system to quietly handle edge cases in whatever way is most efficient. I suspect there are a lot of valid use cases for such a mode where the programmer can be reasonably sure that those edge cases will have little or no impact on what the user ends up seeing in the final rendered frame.
- monocasa 3y agoThe out of bounds accesses don't necessarily trap without the robustness checks, so the robustness is about delivering known results under those goofy cases. So it makes sense when you combine that with the fact that GPUs are pretty against traps in general. Carmack remarked once that it's was a pain to get manufacturers to be into the idea of virtual memory when he was designing megatexture.
- pjmlp 3y agoThis is one of the reasons why C and C++ have a rosy life ahead of themselves on graphics, HPC, HEP, HFT domains. In domains where "performance trumps safety" culture reigns, talking about other programing languages is like talking to a wall.
- miga 3y agoGreat for conformance! What about performance?
- mort96 3y agoLiterally the entire post is about finding ways to get conformance wrt. the robustness tests without sacrificing performance, what more do you want?
- deleted 3y ago[deleted]