May be Vulkan can be the first priority since OpenGL can be provided by Zink when it's in good shape.

Vulkan is a lot more work to get to, with far fewer applications using it. It would be a worse ROI, and take significantly longer to make an OS that can be a daily driver for most people.

Not sure if OpenGL 4.0-4.6 is less work in general. I'd argue implementing Vulkan gives the best ROI, since it gives all OpenGL after that without extra effort.

And I don't think that few applications use it. Anything modern tries to. The rest are planning to move to it.

What common or high profile applications do you think actively target Vulkan? Outside of games very few do in my experience but I’d love to see some examples outside what I know of.

As shmerl pointed out in their first comment, once Vulkan support is there, you get OpenGL support for free through Mesa's Zinc driver.

I'm not trying to say that they "should" have focused on Vulkan first, by the way. There may be good reasons to focus on OpenGL first. Maybe it's what Rosenzweig has the most experience with, or maybe getting a Vulkan implementation to the point where it can be used to usefully emulate OpenGL is more work than getting an OpenGL implementation to the point where it can do 2D and basic 3D acceleration, maybe Zinc has some serious performance issues or isn't solid yet, I don't know.

OpenGL is a much shorter path to stand up. The difference would be that they are already passing big chunks of GL conformance tests , but would take a long time to stand up Vulkan support.

This is about trying to get something daily drivable for most people in the most efficient way possible, and sometimes efficiency does mean implementing part of the tech stack twice if the first time unblocks you on other things.

Wayland compositors are going to switch to it, with some already doing it (like Sway). Video players like mpv use it. Blender has some plan for it.

Basically, it's the way forward, not OpenGL.

Sure, but that’s in the future and they aren’t not going to add Vulkan. But it makes sense to prioritize GL for now, especially because a lot of the GL work comes much easier thanks to their prior MESA work.

Even amongst your list, I don’t see mass adoption of the applications today that don’t also have a GL backend.

Blender alone will be a gargantuan uplift to get to Vulkan because so much of the ecosystem is coded agains GL directly.

This kind of experimental project above looks pretty well aligned with where things are heading, so I think focus on Vulkan would be still fitting.

Meaning by the time it will be more usable, Vulkan will be more used as well.

And as above, if you implement Vulkan - you get OpenGL through Zink. If you implement OpenGL - you still have to implement Vulkan. So with limited resources, the first option looks way more effective.

You’re looking at it from a number of implementations perspective.

They’re looking at it as a time to viable product perspective and a ROI.

These are often at odds within engineering , and it makes sense for them to pick their way because they already have a lot of the GL stuff done and it’s a faster route to a viable product.

Again, going for vulkan would mean they’d have to spend significantly more time up front.

You seem to be maximizing for not trying to do work (e.g implementing both Vulkan and OpenGL), but in many cases it’s better to get something stable and workable out.

Basically, don’t let perfect be the enemy of good.

I don't see OpenGL only option as something worth using seriously, so not a usable option in practice, if I can simply get hardware where Vulkan works fine.

So as a fun experiment, it can be interesting. As something practical - doesn't seem so until all pieces are in place.

Sure. No one disagrees with that. But if you have the choice 5 years of no workable GPU. Or 2 year of no GPU, then have a workable opengl driver. And then after 4 additional years you have a vulkan driver.

I believe, and I couldn't quickly find it in the docs, that Mesa provides certain OpenGL versions if you have implement certain OpenGLES version. For for example if you have OpenGLES3 you get OpenGL 3 for free via Mesa (These version numbers are made up, I don't actually know which OGL version can be implemented in terms of OGLES)

It's the other way around. GLES Versions become a subset of later OpenGL Versions.

From a spec based standpoint you maybe right but I'm clearly not talking about that. Else it wouldn't be possible that Asahi linux is running non-ES OpenGL based application when there is ONLY an openGL ES driver.