Live data from Hacker News

Conformant OpenGL 4.6 on the M1

rosenzweig.io

51–60 of 118 posts

Re: Conformant OpenGL 4.6 on the M1

#51

"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.

[deleted]

Re: Conformant OpenGL 4.6 on the M1

#52

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.

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.

Re: Conformant OpenGL 4.6 on the M1

#53

> 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", b…

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.

Re: Conformant OpenGL 4.6 on the M1

#55
post #22

Earlier quoted context omitted.

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.

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 c…

> a viable direct target for modern games

Aside from PlayStation exclusives, nearly every AAA game in the past 20+ years has targeted Direct3D and HLSL first. Any other backend is a port.

Re: Conformant OpenGL 4.6 on the M1

#56
One 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.

Re: Conformant OpenGL 4.6 on the M1

#57

Earlier quoted context omitted.

Strange the article doesn't use the word "Apple" once, and instead awkwardly uses "the vendor" to refer to Apple.

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.

Didn't CentOS use "the vendor" instead of RHEL like this too?

Re: Conformant OpenGL 4.6 on the M1

#58
post #56

One 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 a…

> 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.gettin...) an opengl triangle rendering example code (~200 LOC)

[here's](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

Re: Conformant OpenGL 4.6 on the M1

#59
post #58
post #56

One 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 a…

> 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.gettin... ) an opengl triangle rendering example code (~200 LOC) [here's]( 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

This 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.

Re: Conformant OpenGL 4.6 on the M1

#60
post #58

Earlier quoted context omitted.

> 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.gettin... ) an opengl triangle rendering example code (~200 LOC) [here's]( 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

This 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 sensib…

And often those LOC examples use GLFW or some other library to load OpenGL. Loading a Vulkan instance is a walk in the park compared to initializing an OpenGL context, especially on Windows. It's incredibly misleading. If you allowed utility libraries for Vulkan to compare LOC-to-triangle Vulkan would be much closer to OpenGL.
Post reply on HN