12 ms·
Clip control on the Apple GPU
- rowanG077 4y agoAmazing that this works because of the herculean effort of just a handful of people.
- gjsman-1000 4y agoOptimistic that OpenGL 2.1 will be available by the end of the year on Asahi - well that is news. It's only 2.1, but that's enough (as stated) for a web browser, desktop acceleration, and old games. Also RIP all the countless pessimistic "engineers" here and elsewhere saying we'd be waiting for years more for any graphics acceleration. Edit: It is true though that AAA Gaming will wait: "Please temper your expectations: even with hardware documentation, an optimized Vulkan driver stack (with enough features to layer OpenGL 4.6 with Zink) requires over many years of full time work. At least for now, nobody is working on this driver full time. Reverse-engineering slows the process considerably. We won’t be playing AAA games any time soon." Still, even if that be the case, accelerated desktop is an accelerated desktop, much sooner than many expected.
- smoldesu 4y agoIt's pretty insane that OpenGL 2.1 is even functional on a GPU this strange, but remember; this is still an unfinished, hacky implementation (the author's own concession). Plus, you're going to be stuck on x11 until any serious GPU drivers get written, which in many people's opinion is just as bad as no hardware acceleration at all. No MacOS-like trackpad gestures either, you'll be waiting for Wayland support to get that too. It'll definitely be a boon for web browsing though, so I won't deny that. What I'm really curious about is older WINE titles with Box86, if you could get DOS titles like Diablo 2 running smoothly, it could probably replace my Switch as a portable emulation machine...
- kirbyfan64sos 4y agoI'm a bit confused as to why X11/wayland would be a huge issue here? The Mesa docs do say X11-only, but they're referring to running the driver on macOS (hence the XQuartz reference), where Wayland basically doesn't exist.
- smoldesu 4y agoAh, looks like I definitely missed that. In any case, I don't think Asahi/M1 has proper KWin or Mutter support yet. It's still going to take a while before you get a truly smooth desktop Linux experience on those devices, but some hardware acceleration is definitely better than none!
- gjsman-1000 4y ago> pretty insane that OpenGL 2.1 is even functional on a GPU this strange, Well... you were one of the most vocal critics saying it wouldn't happen anytime soon. > unfinished, hacky implementation (the author's own concession) Still more stable than Intel's official Arc drivers, so who defines "hacky"? ;) > Plus, you're going to be stuck on x11 until any serious GPU drivers get written Only because it is running on macOS, which supports X11 but not Wayland. On Linux, Wayland or X11 will both work, no problem. > No MacOS-like trackpad gestures either, you'll be waiting for Wayland support to get that too Again, Wayland will work on Day 1, it's just a limitation of running the driver on macOS until the kernel support is ready. When it is on Linux, Wayland will be a full-go.
- smoldesu 4y ago> Well... you were one of the most vocal critics saying it wouldn't happen anytime soon. Yep. Been beating that drum since 2020, looks history proved me right on this one. > Still more stable than Intel's official Arc drivers, so who defines "hacky"? ;) Apparently not me, I had no idea that the M1 supported Vulkan and DirectX 12.
- Miraste 4y agoWhy would you need Wayland for trackpad gestures?
- 3836293648 4y agoYou technicay don't, but the implementations on X are kinda terrible and can't do 1:1
- deleted 4y ago[deleted]
- rowanG077 4y agoI mean the signs were clear for basically one and a half years now. It was never a question of if. But a question of when. There were just so many voices that didn't know what they were talking about. Comparing it to nouveau for example.
- viraptor 4y ago> if you could get DOS titles like Diablo 2 Did you mean some other title? Even diablo 1 was a Windows game.
- sudosysgen 4y agoOpenGL 2.1 is not enough for browsers - Firefox requires OpenGL 3.2 for limited hardware acceleration support, and there will be limitations on Chrome as well. Desktop acceleration is a similar story, KWin will have a degraded experience for OpenGL less than 3. There is also the possibility of breakage due to missing extensions. Most old games won't work because most are going to require OpenGL>=3. For D3D games from Windows, translation efforts have long been focused on Vulkan, and even then, you are very likely to require extensions which aren't present or further versions of OpenGL. So that's to say that, it's not about AAA games, it's about Firefox, (full) KDE, and Minecraft. Which is going to take a few years, probably. There is no RIP, it's going about as well as those people were predicting - I'm expecting it's not going to be able to have full browser acceleration and play Minecraft until 2 more years at the very least.
- bla3 4y ago> Here’s a little secret: there are two graphics APIs called “Metal”. There’s the Metal you know, a limited API that Apple documents for App Store developers, an API that lacks useful features supported by OpenGL and Vulkan. > And there’s the Metal that Apple uses themselves, an internal API adding back features that Apple doesn’t want you using. Apple does stuff like this so much and gets so little flak for it. I use macOS since it seems like the least bad option of you want a Unix but also don't want to spend a lot of time on system management, but this is a real turn-off.
- gjsman-1000 4y ago> Apple does stuff like this so much and gets so little flak for it. To be fair, Windows has a ludicrous amount of undocumented APIs for internal affairs as well, and you can get deep into the weeds very quickly, just ask the WINE Developers who have to reverse-engineer the havoc. There is no OS without Private APIs, but Windows is arguably the worst with more Private or Undocumented APIs than Apple. This actually bears parallels to Metal. Until DirectX 12, Windows had no official way to get low-level. Vulkan and OpenGL are only 3rd-party supported, not Microsoft-supported, Microsoft officially only supports DirectX. If you want Vulkan/OpenGL, that's on your GPU vendor. If you wanted low-level until 12, you may have found yourself pulling some undocumented shenanigans. Apple hasn't gotten to their DirectX 12 yet, but they'll get there eventually. As for why they are Private, there could be many reasons, not least of which that (in this case) Apple has a very complicated Display Controller design and is frequently changing those internal methods, which would break compatibility if third-party applications used them. Just ask Asahi about how the DCP changed considerably from 11.x to 13.x.
- chongli 4y agoApple has a very complicated Display Controller design Can anyone in the know give more information here? Why would Apple want to do this? What could they be doing that's so complicated in the display controller?
- gjsman-1000 4y ago
- pornel 4y agoApple could help by documenting this stuff. I remember the good old days when every Mac OS X came with an extra CD with Xcode, and Apple was regularly publishing Technical Notes detailing implementation details. Today the same level of detail is treated as top secret, and it seems that Apple doesn't want developers to even think beyond the surface of the tiny App Store sandbox.
- dagmx 4y agoEven back in the day, those technical notes would not cover private APIs like this, because they’re subject to change or are for internal use only. These are the same in any closed source OS
- madeofpalk 4y agoApple Platform Security: May 2022. 242 pages. https://help.apple.com/pdf/security/en_GB/apple-platform-security-guide-b.pdf https://help.apple.com/pdf/security/en_GB/apple-platform-sec...
- alberth 4y agoI really wish Apple would do another "Snow Leopard" - go an entire year WITHOUT any new features and just fix bugs and documentation. This twitter thread is a perfect example of why it's needed https://twitter.com/nikitonsky/status/1557357661171204098 https://twitter.com/nikitonsky/status/1557357661171204098
- argsnd 4y agoI mean that thread is looking at pre-release software
- ianlevesque 4y agoThere is software that approaches barely functional after dozens of rounds of QA testing, and then there is software that is implemented on a solid foundation with care and happens to have a few bugs. Unfortunately that many bugs in a beta implies the former. I think the thread comes from a disappointment that Apple is moving from the second category to the first.
- naillo 4y agoThis person has an awesome set of blog posts. One of the few rss feeds I keep track of.
- viktorcode 4y agoCan someone explain to me why support OpenGL at all? Vulkan is easier to implement. Is there a need for OpenGL on Linux?
- dagmx 4y agoBecause Vulkan, despite the mystical reputation it has in gaming circles, actually has fairly low adoption vs OpenGL . Very few applications in the grand scheme of things use Vulkan, and a minority of games do. Therefore the ROI on supporting OpenGL is very high.
- 58028641 4y agoDoesn’t implementing Vulkan give you DirectX with DXVK and VKD3D and OpenGL with Zink for free?
- erichocean 4y agoYes, with appropriate (and reasonably-available) Vulkan extensions.
- Cu3PO42 4y agoOnly if you support all of the necessary Vulkan features and extensions. The article states that getting to that point would be a multi-year full time effort, whereas "only" OpenGL seems to be within grasp for this year. And arguably having a lower OpenGL standard soon is better than OpenGL 4.6 in a few years.
- gjsman-1000 4y agoOn a reverse-engineered GPU like this, because of Vulkan's low-level design, implementing (early) OpenGL might actually be significantly easier. Also, Vulkan isn't popular with game developers because availability sucks. Vulkan doesn't run on macOS. Or iOS. Or 40% of Android phones. Or Xbox. Or PlayStation. Or Nintendo Switch[1]. Unless you are targeting Windows (which has DirectX and OpenGL already), or those 60% of Android phones only, or Linux, why would you use Vulkan? On Windows, DirectX is a generally-superior alternative, and you get Xbox support basically free, and if you also support an older DirectX, much broader PC compatibility. On Android, just use OpenGL, and don't worry about separate implementations for the bifurcated Vulkan/OpenGL support. On Linux, just use Proton with an older DirectX. Whiz bang, no need for Vulkan whatsoever. Yes, some systems might perform better if you had a Vulkan over OpenGL, but is the cost worth it when you don't need it? [1] Technically, Vulkan does exist for Nintendo Switch, but it is so slow almost no production game uses it, and it is widely considered not an option. Nintendo Switch is slow enough without Vulkan making it slower. Much easier just to use the proprietary NVIDIA library.
- bob1029 4y agoClip space is the bane of my existence. I've been building a software rasterizer from scratch and implementing vertex/triangle clipping has turned into one of the hardest aspects. It took me about 50 hours of reading various references before I learned you cannot get away with doing this in screen space or any time after perspective divide. It still staggers me that there is not 1 coherent reference for how to do all of this. Virtually every reference about clipping winds up with something like "and then the GPU waves its magic wand and everything is properly clipped & interpolated :D". Every paper I read has some "your real answer is in another paper" meme going on. I've got printouts of Blinn & Newell, Sutherland & Hodgman, et. al. littered all over my house right now. About 4 decades worth of materials. Anyone who works on the internals of OGL or the GPU stack itself has the utmost respect from me. I cannot imagine working in that space full-time. About 3 hours of this per weekend is about all my brain can handle.
- skrrtww 4y agoDespite the progress here, for me it raises a question: Most of the old games she mentions are x86 32bit games. What's the story for how these programs are actually going to run in Asahi? Box86 [1] doesn't sound like it's projected to run on M1. Rosetta 2 on macOS allows 32-bit code to be run by a 64-bit process, which is the workaround CrossOver et. al. use (from what I understand), but that obviously won't be available? [1] https://box86.org https://box86.org
- mort96 4y agoSomeone would need to make an x86 -> ARM recompiler like Rosetta 2. That's not an easy task, but also not the task she's tackling with the GPU driver. It's not unprecedented in the open-source space though; the PCSX2 PlayStation 2 emulator for example contains a MIPS -> x86 recompiler, and the RPCS3 PlayStation 3 emulator contains a Cell -> x86 recompiler.
- deleted 4y ago[deleted]
- rowanG077 4y agoRosetta 2 runs on Linux. There's also FEX.
- amluto 4y agoDoes it? Or does Rosetta 2 run on Mac OS with a Linux shim to ask the host to kindly Rosetta-ify a given binary?
- wtallis 4y agoPretty much immediately after the first developer beta providing Rosetta for Linux shipped, people tried to get it to work on non-Apple hardware, and succeeded: https://news.ycombinator.com/item?id=31662978 https://news.ycombinator.com/item?id=31662978 There's no macOS host to interact with on AWS Graviton3 instances.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- andrewmcwatters 4y agoOpenGL on macOS is so frustrating, that I and many other developers have basically abandoned it, and not in favor of using Metal--the easier alternative is to just no longer support Macs. Yes, OpenGL on macOS is now implemented over Metal, but unfortunately a side effect of this is that implementation-level details that were critical to debugging and profiling OpenGL just no longer exist for tools to work with. Anything is possible? Maybe? I'm sure Apple Graphics engineers could make old tooling work with the new abstraction layer, but it's not happening. Tooling investment is all on Metal now. But so much existing NON-LEGACY software relied on OpenGL. So what do you do? You debug and perf test on Windows and Linux and hope that fixing issues there addresses concerns on macOS, and hopefully your problems aren't platform-specific. This is how some graphics engineers, including myself, continue to ship for macOS while never touching it. Edit: Also, Vulkan is a waste of time for anyone who isn't a large studio. No one wants to write this stuff. The most common argument is "You only write it once." No, you don't. You have to support this stuff. If it were that easy, bgfx would have been written in a month and it would have been considered "done" afterwards.
- gernb 4y ago> This is how some graphics engineers, including myself, continue to ship ... The snarky response would be "you're not a graphics engineer if you're still using OpenGL" (please laugh at the bad joke) But seriously, knowing how GPUs actually work, OpenGL is pretty horrible. Full OpenGL has 20 years of cruft hacked and glommed on to it. As someone who's job is to write OpenGL emulation it really needs to die and people need to stop using it. If you don't care but want cross platform OpenGL ES then use ANGLE, or if you want something more modern that ditches most of that 20years of cruft look into one of the native WebGPU implementations (dawn, wgpu, ...)
- boondaburrah 4y agofor me BGFX has become the API since I'm basically tired of wrassling how fragmented graphics programming seems to be. I just wish the shader language wasn't semi-custom GLSL-with-C-macros so I could use existing tooling for previewing/editing what I'm working on.
- kvark 4y ago
- fbanon 4y agoCouldn't you just pre-multiply the projection matrix to remap the Z range from [-1,1] to [0,1]?
- NobodyNada 4y agoWhat projection matrix? Remember that this translation needs to happen at the graphics driver level. For fixed-function OpenGL where the application actually passes the graphics driver a projection matrix this would be doable. But if your application is using a version of OpenGL newer than 2004, the projection matrix is a part of your vertex shader. The graphics driver can't tell what part of your shader deals with projection, and definitely can't tell what uniforms it would need to tweak to modify the projection matrix -- many shaders might not even have a projection matrix.
- fbanon 4y agoI know. But the second sentence of the article starts with: "Neverball uses legacy “fixed function” OpenGL." But also you could simply remap the Z coordinate of gl_Position at the end of the vertex stage, do the clipping in [0,1] range, then map it back to [-1,1] for gl_FragCoord at the start of the fragment stage.
- NobodyNada 4y ago> "Neverball uses legacy “fixed function” OpenGL." Sure, it'd work for Neverball, but the article is clear that they're looking for a general solution: something that'd work not just for Neverball, but for all OpenGL applications, and would ideally let them give applications control over the clip-control bit through OpenGL/Vulkan extensions. > But also you could simply remap the Z coordinate of gl_Position at the end of the vertex stage, do the clipping in [0,1] range, then map it back to [-1,1] for gl_FragCoord at the start of the fragment stage. Yes, that was the current state-of-the-art before this article was written: > As Metal uses the 0/1 clip space, implementing OpenGL on Metal requires emulating the -1/1 clip space by inserting extra instructions into the vertex shader to transform the Z coordinate. Although this emulation adds overhead, it works for ANGLE’s open source implementation of OpenGL ES on Metal. > Like ANGLE, Apple’s OpenGL driver internally translates to Metal. Because Metal uses the 0 to 1 clip space, it should require this emulation code. Curiously, when we disassemble shaders compiled with their OpenGL implementation, we don’t see any such emulation. That means Apple’s GPU must support -1/1 clip spaces in addition to Metal’s preferred 0/1. The problem is figuring out how to use this other clip space.
- hrydgard 4y agoThere is no good reason to flip the flag dynamically at runtime and apps just don't do that, so flushing the pipeline should be perfectly fine, even in an implementation of the clip control extension.
- skocznymroczny 4y agoI don't know why there's so much love for OpenGL in the communities still. Maybe it's the "open" part in the name, which was always confusing people, thinking it's an open source standard or something like that. The API is very antiquated, doesn't match modern GPU architectures at all and requires many workarounds in the driver to get the expected functionality, often coming at a performance cost. Vulkan is nice, but it goes into the other extreme. It's very low level and designed for advanced users. Even getting anything on the screen in Vulkan is intimidating because you have to write everything from scratch. To go beyond hello world, you even have to write your own memory allocator (or use an existing opensource one) because you can only do a limited amount of memory allocations and you're expected to allocate a huge block of memory and suballocate it as needed by your application. In comparison, DX12 is a bit easier to grasp. It has some nice abstractions such as commited resources, which take some of the pain away. Personally I like Metal as an API. It is lower level than OpenGL, getting rid of most nasty OpenGL things (state machine, lack of pipeline state objects), yet it is very approachable and easy to transition to from DX11/OpenGL. I was happy when I saw WebGPU was based on Metal at first. WebGPU is my go-to 3D API at the moment, especially with projects like wgpu-native which make it usable on native platforms too (don't let the Web in WebGPU confuse you).
- Teknoman117 4y ago> Vulkan is nice, but it goes into the other extreme. It's very low level and designed for advanced users. Even getting anything on the screen in Vulkan is intimidating because you have to write everything from scratch. I honestly believe that this is the major reason. Developing a hobby project with OpenGL is little more than using SDL or GLFW to get a window with a GLContext and then you can just start calling commands. Vulkan is much more complicated and unless you're really pushing performance limits, you're not getting much of a benefit for the extra headache.
- gary_0 4y agoOpenGL is what you use if you just want to render some triangles on the GPU with a minimum of hassle on the most platforms (which is quite a few if you include GLES, WebGL, and ANGLE). Most people aren't writing graphics engines for AAA games so OpenGL is all they need.
- moondev 4y agoCan you run a PCIE enclosure over thunderbolt on asahi Linux yet? Could this enable GPUs that already work on aarch64 Linux?
- hishnash 4y agoI would assume all linux GPU drivers would need to be adapted at least a little to support the larger page size (most linux AARCH64 kernel level code is writing assuming 4kb pages).
- kmeisthax 4y agoYes, but NOT for GPUs. Apple Silicon does not support non-Device mappings over Thunderbolt, so eGPUs will never work.
- 1letterunixname 4y agoThis brings back memories of a computer graphics course. It was (re)implementing part of the OpenGL 1.3 pipeline in C++98 as a 2D triangle-to-trapezoid engine using the painter's algorithm (and then W- or Z-buffering). Coincidentally, it happened to use GLUT+GLU and work on Windows 98, Solaris, and Linux... circa 2001. https://www.opengl.org/resources/libraries/glut/glut_downloads.php https://www.opengl.org/resources/libraries/glut/glut_downloa...