These guys also have an implementation[1] of OpenGL that’s optimized for Metal, and supports more modern OpenGL than Apple’s pathetic “frozen in time” implementation. Sadly it’s not open source, but I suppose a company’s gotta make money somehow.
Such a shame that such essential support for hardware that comes with every Mac apparently needs to be provided by a third party.
> Such a shame that such essential support for hardware that comes with every Mac apparently needs to be provided by a third party.
Why? The whole point of having a general purpose computer is that you can install stuff. I do prefer to use the bundled facilities in my OS but sometimes third party alternatives are superior.
Except this model is for third parties to provide user products on a solid OS foundation. Apple cripples their OS in multiple ways to make developing for it harder artificially, necessitating third parties to do the work to make the platform usable for developers. That is Apples failure as a platform maker, but they don't get any ire for it because respectively their hardware is good and their phone platform cannot be ignored when developing for mobile.
This is less like choosing which browser you want and more like macOS only supporting USB 1.1 and all USB2/3 drivers being provided by a third party company.
That'd be pretty shameful, were it real. How macOS has handled the whole metal saga has been pretty shameful too.
Ironically it’s usually easier to install and use open source software on macOS than in Windows, since most of it is developed for Linux, and the Mac version of Unix is close enough to make ports easy.
macOS, also the latest version High Sierra, is even certified Unix [0].
Mac has non-standard hardware yes, bespoke software hell yes, but also pretty good standard compliance when it comes to the lower level system interfaces - lower level as in below the various high level frameworks such as the UI toolkit Cocoa.
The Linux Standard Base is a superset of POSIX (Portable Operating System Interface [for Unix]), with some small incompatibilities [1]
But why do they want that? That’s just making life harder for all the devs. It’s absolutely not realistic to expect devs to want to lock themselves into the macOS and iOS ecosystem by using only Metal, so then they must duplicate their own efforts in Metal that they are already making in OpenGL or in Vulkan or in DX12. Having to maybe care about DX12 even though you don’t want to is bad enough on its own.
It's how Apple has been operating for 10 years with dozens of other frameworks. Plenty of people have been writing programs against Foundation, CoreAudio, MapKit, EventKit, etc, for their {mac,i,tv,watch}OS apps, and obviously different libraries for any other platforms they wish to target.
I do agree that this time it might be different. There's no great cross-platform open-spec solution for, say, EventKit, so when Apple offers up their own API, we've just gone with it. Game Developers are a huge existing community, in a way that Calendar Developers are not. Metal and Vulkan are an unstoppable force meeting an immovable object.
As someone who learned to program in the 1980's, it's pretty amazing that it's getting feasible to target high-performance graphics on every major platform from a single code base. Targeting every user in the world using only 2 graphics libraries doesn't seem so terrible to me. Consider how different the "Lemmings" source code must have been for Commodore Amiga versus the Commodore C=64, for example, not to mention the other 25 platforms it was ported to.
Core Audio is the one of those tools that I know pretty well, and the reason people use Core Audio is because it is legitimately better than the other options out there. I recently had to retool my video rig to use ASIO on Windows for audio rather than Core Audio on an OS X sidecar and it's way more finicky and difficult to work with.
Metal has no such argument, to the best of my knowledge.
Yep, fully OO, C++14 shaders and all the respective libraries for textures, fonts, scene definitions,....
Vulkan is the typical Khronos API, pure C, has the extension dance to find out what is available, just knows about pixels and for everything else everyone needs to go fishing for libraries.
> Plenty of people have been writing programs against ...
Maybe in absolute terms, but relatively speaking these things could not exist and nothing would change. They are /exceptionally niche/ libraries at best .. non-existent if honest
When Apple announced Metal, Alex St. John, one of the original creators of DirectX, posted his take on why this happens:
>At the time that DirectX was created Microsoft also largely controlled the OpenGL standard, the success of DirectX in gaming caused Microsoft to largely lose interest in OpenGL leaving it in the hands of the 3D chip OEM’s to advance as an open standard that they could use to pressure Microsoft to implement features they wanted in DirectX. Apple’s adoption of OpenGL and subsequent active participation on the ARB breathed life into OpenGL in mobile gaming because Apple’s iPhone implementation of OpenGL became the “standard” that other mobile phone and chip vendors had to emulate if they wanted to get IOS games ported to their devices. Without some form of “standard” hardware definition, OpenGL drivers and media drivers in general are often just a grab bag of broken inconsistent functionality. Of course in the absence of a “DirectX” like media API of their own design, Apple had little choice but to jump on the OpenGL bandwagon and ride it for gaming, but clearly it is not to Apple’s competitive advantage to be propping up OpenGL support in mobile for all of their competitors. Just as it did for Microsoft, creating their own proprietary gaming API’s is entirely in Apple’s strategic interest…. Why help Android siphon off their game developers by propping up OpenGL?
Contrary to urban myths game consoles also don't do OpenGL, so AAA game engines always have multiple backends anyway.
And such studios prefer APIs that fully expose the hardware, and then build their own abstractions, than something that hides that extra performance features.
There is a persistent myth that the PS2 and PS3 supported OpenGL. I've worked on both and I can tell you that the implementations were nothing more than experiments that were used by near-zero and zero games, respectively.
Apple is making its own hardware (GPUs) and wants full control on the drivers and feature set for their graphics API.
As someone else mentioned, Vulkan and co are great but also limit to some extent what you can achieve / implement on a given hardware for the sake of cross platform.
95% of the time Vulcan exposes much more low level detail than Metal. A good example is that Vulkan requires you manually lay out buffers/textures in GPU memory, while Metal only lets you bin them into heaps. Vulkan also requires much more manual synchronization. Vulkan also exposes a lot of features (conventional tesselation shaders, geometry shaders) that Metal lacks.
Metal’s main advantage is that it lets you adopt more manual management incrementally (you can basically use it as a DX11 analogue if you’re not interested in low level performance gains). Vulkan is definitely intended primarily for engine developers, not for one-off games.
You are correct about Vulkan being higher level API than Metal in general but there are still Apple-specific functionality in Metal. For example when they released A11 Metal was augmented with a new shading stage intended to match HWs tiled rendering.
Not sure why people are simply downvoting you without answering your question. Apple shipped its first in-house GPU with the A11 Bionic in the iPhone 8/8+/X, and by all accounts it’s a marvel of engineering and quite fantastic for a first outing.
And you’re right - a look at the developer docs for Metal do show that ‘this matters’
Apple was basically the top buyer of Imagination GPUs for years, and worked very closely with them. Last year they severed ties and made the GPUs in-house.
Doesn’t each OS simply provide a high quality and constantly supported API locked to the OS? And leave it to third parties to map any other standards on to it? It seems like DirectX is to Windows what Metal is to macOS - they’re both locked, supported and optimised around the same, no?
Nobody is expecting Microsoft to add native Vulkan drivers on Windows, why would that be expected of Apple?
It's why AAA games have already shipped Vulkan and performed superbly with it (Doom, DOTA2, etc...), since they work with the IHVs to tune & fix bugs and then ship the driver update along with the game drop.
Microsoft doesn't support Vulkan or OpenGL, yet they also are not blocking them. That's the critical difference here. Why is Apple not allowing Nvidia or AMD to do the same on macOS? It's not a question of not supporting it out of the box or doing the work, it's a question of preventing others from supporting it.
Nvidia and AMD didn't take over supporting OpenGL when Microsoft abandoned it out of the goodness of their hearts. They did so because they were in a highly competitive marketplace and supporting OpenGL was a competitive advantage.
Meanwhile, on the Mac, the cheese grater Mac Pro is the only model you can install their graphics cards into and it exited production half a decade ago.
The problem isn't that MacOS lacks Kernel Extensions.
The question is why should Nvidia or ATI take on the expense when there is no marketplace to compete in.
They both have competitive Linux drivers which has even less market share. Given how little kernel-specific is even in the driver I don't see any reason to believe Nvidia or AMD wouldn't happily provide their latest and greatest driver. Especially since they are competing for that bid for whose GPU Apple blesses for that generation of Mac hardware.
You can buy their graphics cards and plug them into a computer running Linux, say in a render farm.
The only Mac you can purchase and use their products in exited production half a decade ago.
Without the possibility of making sales, why would they bother?
Apple's pro software made a big bet on OpenCL in the past, so I don't see them going with anybody but ATI for built in GPUs until they root that dependency out of their software and switch over to Metal for compute.
Nvidia certainly isn't going to put OpenCL performance on an equal footing with CUDA performance, so I can't see them getting a design win with Apple as long as Apple's in house software is still using OpenCL.
Perhaps so, but they haven't seen a design win for a discrete GPU on the Mac since 2013 for the iMac, and 2014 for the Macbook Pro.
That happens to be not terribly long after Apple started offering rewrites of their pro apps that went all in on OpenCL.
Nvidia did put out a driver for the cheese grater Mac pro so it can use Pascal based cards, which is nice, but I imagine that's motivated by a desire to maintain CUDA dominance.
> But why do they want that? That’s just making life harder for all the devs. [...] Having to maybe care about DX12 even though you don’t want to is bad enough on its own.
They probably figure, if developers are willing to do it for DirectX, they'll be willing to do it for Metal also / instead.
It also depends on what exactly Gartner classified as "Ultramobile (Premium)", which they apparently counted towards the "Total PC market" (262 million in 2017). Which one comes out ahead depends on the relative share of Windows 10 tablets vs. iPads in that segment.
In any case, that still puts Metal and DirectX in the same order of magnitude.
Don't know about any statistics that cover specifically that segment, but when it comes to new device shipments, it has been reported that iOS + macOS surpassed Windows + Windows Phone already in 2015, and it is estimated that this trend has continued since then.
That's probably a good question. Those who are actually pushing the hardware in both camps are most likely the minority, as opposed to those who are working with glorified web views.
But AAA on a Windows desktop commands $40-60, whereas AAA on mobile commands < $8 +/- scuzzy IAP schemes.
This list[1] is quite a bit different looking from this list[2]
They want to control the APIs so they can tie them more closely to their hardware. Most game devs I’ve heard from that want cross platform are more concerned with wether Unreal or Unity supports Metal than what OSs supppory which OpenGL or Vulkan APIs.
The gap between the last version of OpenGL that Apple supports and the release of Metal for OSX is 5 years. Even giving metal a few years of development it still means Apple abandoned OSX graphics before they began working on Metal at all. Given that they updated GLES on iOS for a couple of years after the last update to OpenGL on OSX it seems more plausible that macOS is just a second-class citizen to Apple, or at least the graphics are.
For comparison the Vulkan project began July 2014 and was released 19 months later. That released on multiple GPU vendors and OSes at launch, which Metal did not. So let's say Metal took 2 years from conception to release, even though it only targeted one platform and one GPU (and likely took less time as a result)
That means OpenGL was abandoned on OSX roughly 3 years before Metal existed as a project at all.
The timelines of Metal vs. OpenGL on OSX just don't line up at all to be any sort of API redirection effort. It just doesn't mesh.
I don't know the timeline that the graphics team at Apple follows, so the best I can provide you with is a guess as to what I think the reasons are behind their release schedule. Maybe the team was reorganized?
Why would you want a newer OpenGL? I thought the whole point of Vulkan, DX12, and Metal was to move away from such a single-threaded stack driven graphics API to something that was a much better fit for modern cards and engines.
OpenGL on OSX is stuck on 4.1, which is from 2010. It's not just a little of date such that you should begin migrating to Vulkan/Metal, it's ancient. It's old enough to not even have compute shaders (that's OpenGL 4.3)
Modern discrete GPUs also have IOMMUs and per-context page tables. It's a large attack surface which has received relatively little attention from hackers so far compared to CPUs, but there are hardware-level security features in place.
It's a really small attack surface. Other than the tiny, basic mini CPUs what's even on the GPU? There's no OS to speak of, no privileged processes to poke at, etc...
Other than the framebuffer there's not even any data of worth on the GPU.
The attack of note that's been mitigated is DoS attacks through webgl, but GPU preemption is a thing now which largely solves the infinite loop in a shader to lock up the machine.
Sorry but you are really on the wrong track on every point. Attack surface (the drivers are the GPU OS, though hardware bugs do play a part too), GPU memory sensitivity, WebGL history (it's been much worse, not DoS only etc).
(And re the MMU features upthread, it's just a building block. Just like CPU having a MMU doesn't make your OS magically secure)
You seem to have entirely lost the context. We're talking what you can attack from code running on the GPU (aka, from a compute shader), which does not include the drivers since that's not running on the GPU.
If you want to attack the shader compiler go for it, but since that lives in your own process anyway so you could skip that step and go straight to attacking whatever it is you wanted to attack.
> WebGL history (it's been much worse, not DoS only etc).
Such as? All I'm finding are DoS attacks. But regardless WebGL's problems were more due to WebGL and its designs than in vulnerabilities in the drivers or GPUs.
I am always bitterly disappointed in HN's views and understanding of graphic API's. HN, what I largely assume is a community of programmers. Not Khronos idealists. The OpenGL dream died long ago. I think we can thank CAD and GPU vendors for that.
Yet here we are again. If Valve had to port software to Nintendo or Sony; they would be using the native, supported API's. Not porting over Vulkan or OpenGL.
Vulkan is also very good, and not vendor locked. Vulkan is the sole ray of hope that one day we may have a sane graphics stack that works properly across different platforms. If I'm reading the trend right I might even be able to get rid of my Windows partition during my lifetime.
It won't be because Apple decided to make it's own competing standard.
It's not just Apple. This is what everyone forgets. It's Microsoft, Apple, Sony and Nintendo.
Every big vendor and platform for 3D games and software, has their own graphics API which work better and faster than OpenGL and Vulkan. It is only CAD still stuck on OpenGL (and the proprietary extensions).
Idealism is not the answer to positive end user experience.
"Every big vendor and platform for 3D games and software, has their own graphics API which work better and faster than [..] Vulkan."
[citation needed]
Not that they have their own API, but that it's at all better or faster than Vulkan. Remember Vulkan primarily came from AMD's Mantle. It's not the creation of a committee catering to the lowest common denominator.
And no, it's not only CAD still stuck on OpenGL. Games use it, too. Most of mobile is also on OpenGL ES. Increasingly more of them use it than they used to, even, as increasingly games are using off-the-shelf engines that are already cross-platform and have an OpenGL back-end.
The single largest consumer OS in the world (Android) only supports OpenGL ES & Vulkan, even, with no proprietary graphics API of any kind.
> Actually, most iOS games in recent years have been using Metal, as are most “off the shelf” engines internally.
Largely due to support in Unity/Unreal. They would be using OpenGL ES still if they had their own engines except maybe the biggest game studios that always have custom game engines/rendering integration.
Revenue per graphics API would be fascinating, albeit very different, investigation. It would likely also put OpenGL on desktop in a very different light given the professional products still using it.
I don't consider "Android" to be an OS. It is like Linux, there are a hundred different OSes all running on top of the same kernel and framework. For example, the OS Samsung runs on their phones is so different from the OS Xiaomi runs on theirs that a casual user might think it's a completely different system.
So lumping together all of these variants and calling them "most used OS" is not useful in any sense. They are very different for users, and very different for devs.
This is specially relevant when you want to develop a game against a graphics API. Samsung has Vulkan on their flagships for a couple years now, but not the mid/low-end devices. Pixel supports Vulkan, but the units sold are so low that they are a rounding error. No other major manufacturer significantly supports Vulkan either. In this and similar scenarios, the framework used by ios may well be the "most used" mobile framework.
Android only requires GLES 2 yet 63.6% of devices support GLES 3+ anyway.
Since nearly everyone's GLES 3 hardware both supports vulkan & has vulkan drivers already there's no particular reason to believe that an OEM will decide to just not ship vulkan support. It's more work for them to remove Vulkan from the SoC's base image than it is to just not touch it.
The low-end GLES 2 hardware is the only problem, which is a market iOS simply doesn't exist in at all. So if you're cool with ignoring that market, go for it.
I don't think that's necessarily true anymore. Vulkan and even OpenGL have shown a lot of promise recently, in real world tests. You may be right that it's simple idealism from my end but I (want to) believe that Vulkan is coming along at the right time/space to gain broad support in the industry. I'm no fan of DX12 either, or NVN or whatever it is that Sony has. The low level nature of MoltenVK and likely the future DX12 <-> Vulkan layer will result in a small enough perf hit that it will make sense for developers to target Vulkan instead of 3 different APIs. Perhaps similar libraries will become available for Sony and Nintendo platforms as well. I hope that the trend will continue and one day I won't have to resort to OpenGl ES in order to write something that's truly cross platform.
> Every big vendor and platform for 3D games and software, has their own graphics API which work better and faster than OpenGL and Vulkan.
True but console is a different beast though, it seems you are focused on that not just mobile which was always just OpenGL ES mainly since '07 until Metal entered the arena.
On consoles/custom handhelds, they have always had their own frameworks to get the most out of their custom hardware and for lock-in exclusives, to compete and advance their hardware as far as possible for the console lifeline, to sell as many games as possible as the hardware ages as game content is where they made profit. Consoles have modified versions of frameworks or their own like gcm from Sony. They do support standard ones but mostly people use the custom ones to get the most out of the hardware and the hardware makers like that.
On desktop, only two essentially in DirectX and OpenGL and was that way for a long time. Portability was fine, DX windows, OpenGL everything else but DX was the major one due to Windows desktop dominance.
On mobile, OpenGL ES on the major mobile platforms, iOS and Android, pretty much the only one since '07 until Metal.
As I mentioned in other areas, not a huge deal to game developers who aren't building their own engine but portability does matter on desktop and mobile, not just consoles which have reasons for custom rendering engines/toolkits.
and proprietary apis are not the answer to positive developer experience. time will show whether insisting on your own world-incompatible graphics apis will lead to developers writing custom apps for your platform, or whether they will use whatever lets them release on many platforms at once.
Indie titles shipped using OpenGL ES on PS3 and indies got Sony to eventually release an OpenGL wrapper for PS4 as well. If you want decent portability and all your game does is draw alpha blended sprites with simple shaders it could be a win. Questionable how much better that is than either making your game with a portable engine like most indies are doing, or using gnm directly.
mobile dev seems a lot more (for want of a better word) grassroots than professional game dev. lower barrier to entry, and a larger set of people who have a good idea they feel they can implement. also phones will probably bring up a lot of uses for a good high-performance graphics api that are not game-related, as people think of more and more things they would like to do with the computer in their pockets.
Vulkan also requires a huge amount of code to do relatively simple things, and is much easier to invoke UB with. It was always intended first and foremost for engine developers. Metal is far more appropriate for games that use their own graphics code but aren’t doing anything too special or have time for painstaking optimization.
Using Vulkan is like writing your own language runtime over system calls: you have to handle memory allocation and synchronization on your own.
> > Vulkan also requires a huge amount of code to do relatively simple things
IMO, this is a common misconception. Or, at least, the extrapolation of it is. Vulkan might require a lot of code to initialize, and has extra responsibilities related to memory management, synchronization, etc., but in my experience the end product doesn't require significantly more code than other graphics APIs. The up-front cost you pay doesn't translate to increased costs everywhere else, at least not to the same degree.
My library supports D3D11, Metal, Vulkan, and OpenGL, and Vulkan is the second-largest backend, but not by a lot (LOC: ~5k Vulkan, ~3.3k D3D11, ~2.5k Metal, 6k OpenGL). LOC is not the best indicator of complexity, to be fair. My OpenGL backend is definitely the most difficult to maintain and the largest, because the API is such a pain to deal with.
As someone with former experience at IGDA and that dwelled in a few GDCE's, I think many at HN just don't get one bit as professional game studios work and how different the game developer's culture is from FOSS.
This is the world that was born from demoscene, where exploiting cool hardware specific tricks was more valuable than writing portable code.
What do you mean by “the OpenGL dream died”? It seems to me that we were slowly moving toward a unified API across all operating systems, then Apple did what they always do and invented their own closed API.
Vulkan, as a Khronos open standard, likely wouldn't exist if Apple didn't make Metal. Khronos was content for OpenGL{ES} to sputter ad infinitum until it realized that its largest platform (iOS/macOS) was moving on. It helped that the rest of the industry (MS, AMD) was also moving in the same direction, but it was the release of Metal that broke the camel's back.
There were several efforts in the past to revamp OpenGL (e.g. long's peak), but they all failed. OpenGL was stuck and there was little reason to think the situation would improve. Writing OpenGL code that worked across multiple platforms was worse than it is today to write multiple per-graphics-API render backends.
If anything the current crop of new graphics APIs (Metal, Vulkan, and DX12) all owes their start to AMD's Mantle project. Metal certainly didn't get the ball rolling, although it almost certainly accelerated Khronos's path to standardization & shipping (which is why Vulkan adopted Mantle as the base, to ship quicker). AMD gets that claim.
Apple doesn't count? did you RTFA? It's all about apple and proprietary graphics API's.
Apple Metal launched in 2014.
Sony and Nintendo and NEVER used OpenGL for anything extensive. Sony talked the talk around 2005 and 2006 with the launch of the PS3 and OpenGL ES but PSGL was always more performant.
That's just dandy. Show me software that uses it. This is 2005 all over again. You make that deal. You talk to that support. You prove me wrong, please do! The better support, debuggers, and feature requests will come from the native API.
Yeah it might look this way if you never used graphics APIs... truth is it has never been possible to write code against OpenGL for all platforms without extra platform specifics ... it’s also never been anything but trivial to wrap graphics so that the backend is switchable. Metal, mantle, Vulcan, dx12 have done nothing to change that
There are enormous hoops to jump through to release a game on a console. Each console has its own list of certification requirements. Even ignoring the graphics API, it takes significant platform-specific development effort to port a new game engine from Playstation to Xbox.
On the other hand, when I develop OpenGL programs on Linux, it takes maybe a few hours to fix up the few compile errors I might encounter on OSX. Swapping out the graphics API would dwarf all the other porting work combined.
Seriously, all I want is to be able to write graphics programs using compute shaders and share them among my colleagues who use OSX, Linux and Windows. I don't want to write my programs three times. Is that really too much to ask?
Nintendo and Sony are a tiny insignificant speck of the market compared to all the OpenGL ES compatible devices available. I guess every smartphone vendor not called Apple is ran by Khronos idealists. Besides, the latest Nintendo device officially supports Vulkan.
Metal is great, so is Vulkan, so is OpenGL ES on mobile, but it does complicate a bit with portability where OpenGL wasn't as big of deal to port to many platforms, especially on mobile. Mobile has largely been an OpenGL ES only platform except now with Metal entering the game. When speaking of portability on mobile, it was all OpenGL ES versions. Yes consoles have always had their own frameworks to get the most out of their custom hardware and for lock-in exclusives to compete and advance their hardware as far as possible for the console lifeline, to sell as many games as possible as the hardware ages as game content is where they made profit.
The bummer about Apple is that they did help fund Khronos/OpenGL ES and subsequently WebGL from that stack that really revolutionized mobile/handheld gaming. They were big in helping open tech like that as well as canvas, html5, svg etc when the iPhone first came out. They killed Flash essentially and brought H.264 to take a big part of what Flash did, video. Part of how they won was using OpenGL ES and a decent rendering hardware device, it was an amazing thing to see in 2007 and changed handheld gaming big time.
Now Apple has Metal, their own rendering kit, that only works for macOS/iOS where OpenGL was easier to then port to iOS, Android, *nix, even use on Windows etc for desktop/mobile games especially. Apple used open rendering to allow easier porting to their platform, now they have flipped and have taken on a big part of rendering on their devices, a big software part that they hopefully will keep well maintained and up to compete.
But really today there are so many great engines that are middle tier in Unity and Unreal for instance that low level rendering frameworks aren't as big of deal to integrate as it is handled by these middle layer engines. Metal being so prevalent on iOS is only because Unity and Unreal support exporting with that as those two engines make up the largest part of mobile games.
There are four major rendering frameworks now with OpenGL, DirectX, Vulkan and Metal, including others like libGCM and flavors of OpenGL like ES/WebGL. This does complicate things for game engine developers, maintenance and portability with four market standards now. On mobile there are now a few instead of just OpenGL ES versions the dominant one since handheld gaming was taken over by Apple iOS/Google Android. Console game development is a different beast than mobile and desktop in terms of rendering frameworks used for many reasons, mainly that the hardware has to age longer and you need to get every bit of performance.
Most game studios now let the middle tier companies like Unity/Unreal/Cry/Source be their engine team now so it isn't as impactful, so studios can focus on game development, design and content. Back when you did have to write your own engine and rendering layer, it was nice to only have two essentially in DirectX and OpenGL on desktop, and OpenGL ES on the major mobile platforms, console development being the area where there are many frameworks and custom ones per hardware device. The slow progress before mobile and new frameworks was frustrating at times but primarily due to hardware progression, currently it is good to advance and get rendering kits competitive again.
Agreed. It’s awesome that you can write a game once with Unity and not only have it run on all platforms, but have it run with the native, optimized rendering framework.
A little off topic but how is SDL nowadays? I used it for a quick and dirty game back in my college days (13-ish years ago?) and I really, really enjoyed using it. It was very approachable and I could build it on my Windows and Linux PCs.
This is really great news. I wonder how this deal went down, businesswise. MoltenVK used to be a commercial offering by Brenwill Workshop. The way the press release[1] mentions how Khronos "worked" with Valve and Brenwill Workshop to "enable" this release makes it sound like there might have been money involved. If so, great for both Brenwill Workshop and the community.
I have a Windows 10 based PC at home. I use it because I like to play games, but I'm also a YouTube creator and a programmer. In Australian dollars, the build cost me about $3,000. it's an i5 6600K, 16GB of 2333MHz RAM, a 256GB Samsung 950 Pro NVMe M.2 SSD, and an nVidia GTX 1070.
I would drop this system in a heart beat if I could play all my AAA games on macOS, and I would replace it with a high end iMac Pro. Sadly two problems remain:
- I can't play my AAA games on macOS because things like Vulkan aren't fully adopted and in place yet
- You can't swap out the GPU in the iMac Pro
This is why my next build is going to be a Hackintosh.
Barely any AAA games support OSX anyway anymore. Both OSX and Linux are second class citizens for AAA publishers because all their studios drink the DX koolaid hard, even in an age where almost every game is made on Unreal / Unity / Cryengine / etc and all those engines are OS portable they still only see Windows releases.
Direct3D isn't the reason why OSX and Linux are second class citizens for AAA publishers. If those platforms had higher gaming market share publishers would do the work, but as it stands Steam is at 98.3% Windows users, 1.31% Mac users and 0.25% Linux users (http://store.steampowered.com/hwsurvey/). Linux has an extremely disproportionate amount of work involved for the user base, and Mac OS X is questionable for most titles. The Linux gaming audience is largely consists of tech people that aren't really gamers, but buy games to support Linux gaming, effectively for political reasons, this isn't a sustainable market (Humble Bundle helped indies briefly but the support has faded). Mac OS gaming is largely casual users that once again, aren't really gamers, and it has less to do with Mac's software stack (vulkan vs. metal vs. dx is irrelevant) and more with Mac hardware having underpowered GPUs for AAA games. PS4 and Switch don't support Direct3D, and plenty of big publishers port titles that make sense to mobile as well (neither major mobile platform supports Direct3D).
That’s never made much sense to me. I could see if you’re not using one of the major (portable) game engines—you might not want to spend the time developing Windows, Mac, and Linux ports. But if your underlying engine is already portable, would it kill you to hit build a few extra times to produce an “unsupported” Linux or Mac release?
Unless you’re deliberately using Windows specific stuff in you non-platform-specific areas like game logic. In which case facepalm.
EDIT: I know it’s not THAT simple but in general why not have a policy to be portable by default, platform dependent only when necessary?
The major cost barrier is support. If you are going to sell a product for a platform, you need to be able to have your CS staff handle support tickets involving it. Officially Steam on Linux only supports Ubuntu and SteamOS, so you can just throw out problems on other distros (albeit I'm not aware of any distro not taking responsibility for Steam breakages that work on Ubuntu and they aren't that common either).
Even then, having to implement that support infrastructure is time consuming if you have never supported that platform before. It is the first game that is the hardest. That is why publishers like Paradox and 2K can just throw almost every new release on Linux nowadays since they are all made on portable engines, are going to support OSX anyway, and they already have the support infrastructure for SteamOS and Ubuntu.
Its not even really an option, either. Since the games are commercial products in many (European) countries they have to by law support them in this way.
It's the other way round. Apple has never cared about games. Look at how the app store is structured. They'd aspire to be the "artiste" platform (aka photo-editing, music-creating, DJ, video-editing workstation).
That might be left in their DNA from the 80's when competitors like amiga got stereotyped as games machines and lost the much more lucrative business market. Computers where still dismissed as toys by many people and the existence of games on your platform didn't help.
I think external GPUs are an awesome idea. I've not looked into hem recently, actually. They would be awesome for making a 15" MBP from 2014 more useful going forward.
You should try installing Mac OS on your current system, it will probably work. I run it on my main system, although the only game I play on OS X is Starcraft 2, and it runs poorer than on Windows. Still I prefer the Mac environment.
Got it! Yeah I'm all over the resources you can find in the Hackintosh community. I might wait until I have my studio setup and can justify a new system build so I can build a Hackintosh then.
Is anyone else miffed that the DX on VK projects all use different nomenclature? Its impossible to tell from the name dxvk or vkd3d what version it supports. If they were named VK9, VK11, AND VK12 respectively it would be obvious. Or any permutation of their names and that paradigm - VKDX9, VX9, etc.
> While Windows, unlike macOS, does have Vulkan drivers from GPU companies, applications sold through the Microsoft Store are only permitted to use DirectX.
People making games need to make those games for platforms people play on.
You as a user can move to Linux, and game developers should support Linux, but a game which can only be played on Linux and *BSD will be incredibly unsuccessful.
Yes, I am well-versed. You can play many games in Linux and I have Steam installed on my Arch distro with latest stable kernel and graphics drivers, and they are all automatically updated using my package manager and aurutils for extended third-party. It is so much faster than PowerShell, and my i3 windows manager is much more efficient.
I just got new laptops that will support both GVT-G and PCI passthrough via OVMF so that I can run my bloatware OS in a KVM VM but still get full 3D acceleration. Hopefully Microsoft decides to contribute heavily back to Wine, or maybe open source their 4GB spyware beast to understand what it is actually doing that makes it so large compared to my distro, which does everything Windows does in much less resources both storage and compute.
Can anyone who has experience with MoltenVK discuss any potential pitfalls? (It's existed in a closed-source form for 2 years). Is it a case of loading the library and forgetting it, or will you likely need some MoltenVK-specific codepaths to use it?
This is great. I've seen MoltenVK before, but did have any reason to justify getting it.
I am a really big fan of Vulkan. While it takes a bit more work to get going and does less for you, I find the increased transparency very valuable and more enjoyable than trying to guess what the driver is doing.
Graphics programming is so painful because of these anachronisms :(
the Apple gles implementation
is buggy as hell. produces gpu crashes from compliant code etc... I have low expectations. they have made a new annoyance in our lives ... nothing more
Such a shame that such essential support for hardware that comes with every Mac apparently needs to be provided by a third party.
1: https://moltengl.com/moltengl/