I guess a proper stack for doing 3D graphics, instead of the gimmicks that X has had over the years?
I lost count how many times I sat at FOSDEM X room, seeing the improvements that would eventually come (some day).
I lost count how many times I sat at FOSDEM X room, seeing the improvements that would eventually come (some day).
At the protocol level, X isn't involved that much with the 3D graphics stack anyhow these days. Xorg simply speaks DRI3, which is just a way to marshal file descriptors representing graphics buffers over the connection. It isn't involved in the rendering happening at either end (application and compositor).
As the name says, DRI3 was yet another attempt to improve the whole performance stack on Linux.
As mentioned, I did my share of FOSDEM sessions.
thanks for the laugh
"John Carmack: Its still OpenGL, although we obviously use a D3D-ish API [on the Xbox 360], and CG on the PS3. Its interesting how little of the technology cares what API you're using and what generation of the technology you're on. You've got a small handful of files that care about what API they're on, and millions of lines of code that are agnostic to the platform that they're on."
http://fd.fabiensanglard.net/doom3/pdfs/johnc-interviews.pdf
AAA studios already adopted Metal on their engines, Vulkan only matters on GNU/Linux among those having supported graphics cards.
On Android, it is only available as optional graphics API in 10% of devices available worldwide.
On Windows, it is only supported on legacy Win32, it isn't and it won't be supported on UWP.
On Nintendo Switch, there is the option to use the more lower level API NVN instead.
So laugh at will, lets see which APIs game studios care about.
- Tessellation is weird in Metal, as you don't have hull shaders and have to wedge it into the compute pipeline.
- I haven't found a good way to disable multisampling while rendering into a multisample texture, something that is trivial in OpenGL. This can be useful for various effects.
- Switching command encoders is really slow.
- There is no good way I have found to be able to get good timing information inside the app as opposed to the profiler. The info is available on iOS, but not macOS. This is important for telemetry, etc.
Studios are obviously just going to choose the API that's supported on the platforms they're shipping to. Usually there's only one "blessed" API, and so that's the one they pick. It doesn't say anything about the quality of those APIs.
Genuine question : Do AAA studio really care about metal ? Is gaming on Mac a thing now ?
Also Apple's augmented reality is based on Metal, and they had Valve on stage praising it at WWDC, with native support on SteamVR SDK.
Finally, many of the frameworks that made use OpenGL, including the window manager, are now working on top of Metal.
You haven't said anything about Vulkan vs. Metal, and you can't, because Vulkan is a better API for the reasons I described upthread.
Full disclosure: I have colleagues and friends on the Khronos standards group, and I don't like seeing their work bashed without specific technical reasons.
I have said it has insignificant market share and that share won't get better outside GNU/Linux for the foreseeable future.
That has nothing to do with quality.
Gaming on the Mac is a thing to some extent. See Steam for MacOS.
On X there is a mixture of X protocol, 3D stack and the interactions among all possible combinations.