[HN Gopher] Conformant OpenGL 4.6 on the M1
___________________________________________________________________
Conformant OpenGL 4.6 on the M1
Author : patadune
Score : 258 points
Date : 2024-02-14 16:18 UTC (6 hours ago)
(HTM) web link (rosenzweig.io)
(TXT) w3m dump (rosenzweig.io)
| ics wrote:
| Another 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 wrote:
| Same, I wish I knew more about graphics programming. It seems
| like such a steep learning curve though so I get discouraged.
| politician wrote:
| This 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 wrote:
| Perhaps already possible via MoltenVK -> Vulkan -> Zink?
| Guzba wrote:
| Probably needs one or two more layers just to be sure.
| jamesfmilne wrote:
| Ultimately 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://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.
| ryandvm wrote:
| Kind 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 wrote:
| I 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 wrote:
| > 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 wrote:
| Quake didn't use hardware acceleration either. It was only
| the later VQuake and GLQuake releases that did.
| JohnBooty wrote:
| I 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 wrote:
| Quake 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 wrote:
| It also helped that the API was actually user friendly
| compared to the earlier versions of Direct3D.
| marcodiego wrote:
| Quake is just (a probably small (not wanting to dimish it, of
| course)) part of the history. SGI and the enormous effort to
| get compliant implementations on many different systems and
| architectures are what made OpenGL what it eventually became.
| JohnBooty wrote:
| I think both SGI and Quake were absolutely crucial.
|
| Without Quake, OpenGL would have remained an extremely niche
| thing for professional CAD and modeling software. And
| Microsoft would have _completely_ owned the 3D gaming API
| space.
|
| Quake (and Quake 2, and Quake 3, and the many games that
| licensed those engines) really opened the floodgates in terms
| of mass market users demanding OpenGL capabilities (or at
| least a subset of them) from their hardware and drivers.
|
| I'm not sure how to measure this in an objective way, but if
| the mass market of PC gamers didn't dwarf the professional
| CAD/modeling market by several orders of magnitude, I will
| print out my HN posting history and eat it.
| bitwize wrote:
| And yet it still got its ass kicked by Direct3D because
| Microsoft made better stuff. Better API, better tooling, better
| debuggability.
|
| Honestly, it would've been better to leave OpenGL to the legacy
| CAD vendors and standardize on Direct3D roundabout 1997 or so.
| breather wrote:
| Well, except for only working on xbox and windows, which
| pretty much destroys it as a viable direct target for modern
| games or apps.
|
| > Honestly, it would've been better to leave OpenGL to the
| legacy CAD vendors and standardize on Direct3D roundabout
| 1997 or so.
|
| If you remember what Microsoft was like in those days, the
| chances of D3D being standardized in a viable way on any
| platform but windows were about the same chances as an ice
| cube in hell stands.
| malermeister wrote:
| Technically, also Linux (and probably other Vulkan
| platforms) with dxvk.
| breather wrote:
| I had no idea this was a thing! Cheers.
| malermeister wrote:
| There's also VKD3D for dx12!
| Keyframe wrote:
| Ye good ol' Microsoft stiffled OpenGL on Windows, hence open
| letter https://www.chrishecker.com/OpenGL/Press_Release not
| to mention insidious thing they did on Fahrenheit (next gen
| OpenGL+Direct3D, one to rule them all) when they were
| supposed to be working on it together with SGI. Microsoft did
| a well job after with it, but they were and are a shit
| company that made sus maneuvers to make success; Not all of
| them technical.
| Keyframe wrote:
| For context https://www.chrishecker.com/OpenGL/Press_Release
| badsectoracula wrote:
| Fun fact: the earliest archived OpenGL site was a big "FAST
| GAMES GRAPHICS" banner with an animated Quake 1 graphic and a
| menu for other stuff :-P
|
| https://web.archive.org/web/19970707113513/http://www.opengl...
| marcodiego wrote:
| "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 wrote:
| > 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/
|
| 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 wrote:
| Right, 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 wrote:
| I 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.
| vrodic wrote:
| apparently a lot of hardware is still not properly supported,
| like speakers, microphones and energy saving
| acdha wrote:
| Here's the list of very detailed support status: speakers are
| generally supported but microphones are not. They have a
| driver for some energy savings but it has some rough edges.
|
| https://github.com/AsahiLinux/docs/wiki/Feature-Support
| sho_hn wrote:
| I would love for my employer to support that config at work. We
| have quite lovely Linux dev laptops, but the battery life of
| the M1/M2 machines in the IT shop is definitely enticing, and
| Asahi Linux gets closer to MacOS in that regard than you might
| think given the relative maturity and optimization.
| eek2121 wrote:
| It definitely isn't ready for use as a daily driver. There
| are lots of bits missing (see below for an example) and power
| management isn't great compared to macOS.
| seba_dos1 wrote:
| ...and you came to that conclusion because of OpenGL 4.6 -
| something that several other platforms enjoyed under GNU/Linux
| with FLOSS drivers for more than half a decade now?
| johnbatch wrote:
| Strange the article doesn't use the word "Apple" once, and
| instead awkwardly uses "the vendor" to refer to Apple.
| breather wrote:
| It's inline with how the linux/floss community refers to
| hardware vendors in general, even if Apple is a unique case
| in many circumstances.
| brucethemoose2 wrote:
| And Sodium! (For minecraft)
| specto wrote:
| Still waiting for some hardware support and hardware video
| decoding.
| stirlo wrote:
| Hardware video decoding is well on the way:
| https://github.com/eiln/avd
| tarruda wrote:
| > Looks like apple silicon are currently the best hardware for
| running linux
|
| I wonder if this effort to run Linux on apple silicon will
| continue if snapdragon X laptops become mainstream.
| Wowfunhappy wrote:
| Linux is the best OS for Apple Silicon machines for users who
| depend very specifically on modern OpenGL support. I'm not sure
| who this applies to, but it probably describes someone.
| jauntywundrkind wrote:
| > _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 wrote:
| More 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 wrote:
| This 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 wrote:
| They 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 wrote:
| Ok, this makes a lot of sense--OpenGL sort of forms a pathway
| of incremental support.
| simcop2387 wrote:
| Along with that, it's more immediately useful as it's used
| for desktops and compositers still, so getting a useful
| environment necessitates it.
| shmerl wrote:
| I 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 wrote:
| OpenGL-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 wrote:
| This 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 wrote:
| > 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 wrote:
| There 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.
___________________________________________________________________
(page generated 2024-02-14 23:00 UTC)