68 replies to this topic

[mattw]

IMHO this Vulcan announcement may or may not help but Metal and the number of quality triple A titles coming - especially from Feral these days is probably as good as we have ever seen.

The hardware situation remains uncertain due to the push for thin and long waits between revisions. The option of external GPUs may help overcome this to some degree.

Unknown is the effect of the 32-bit purge - will titles get patched or will work arounds appear? It may also kill off WINE on Macs which removes a way of getting access to many classics.

Both consoles have recent updates so should present a reasonably static target hardware level for game developers today so Macs that can offer this level of gaming performance should be OK for a while I would guess. Also the currency miners have put GPU upgrades out of reach for many average PC gamers so the rate of progress there may be slower until (or even if) this can be resolved.

[Janichsan]

mattw, on 28 February 2018 - 05:36 AM, said:

Unknown is the effect of the 32-bit purge - will titles get patched or will work arounds appear? It may also kill off WINE on Macs which removes a way of getting access to many classics.

There already is a 64 bit version of Wine.

[Thain Esh Kelch]

G_Player, on 28 February 2018 - 02:22 AM, said:

So, gentlemen, given that Metal2 has been out for a bit and now there are Metal "backends", since I know next to nothing about programming, how would you rate the current state of (and future) of Mac gaming?

Is there more hope now?

Unchanged, as the current state of MoltenVK is not in a shape where AAA games will use it.

[Spike]

Thain Esh Kelch, on 28 February 2018 - 09:18 AM, said:

Unchanged, as the current state of MoltenVK is not in a shape where AAA games will use it.

So DOTA 2 (and more coming) is not a AAA game?

[MrUNIMOG]

Spike, on 28 February 2018 - 10:33 AM, said:

So DOTA 2 (and more coming) is not a AAA game?

Dota? Not really I guess.

[jeannot]

Dota 2 is pretty basic in the graphics department.

[mattw]

<p>

Janichsan, on 28 February 2018 - 05:59 AM, said:

There already is a 64 bit version of Wine.

Yes there are betas etc. but the last point they note is the problem:

"Current Wine includes support for 64 bit Wine on Mac OS X; however, this has not been tested very much, and some applications may never work due to an ABI incompatibility between Win64 and OS X".

[Thain Esh Kelch]

Spike, on 28 February 2018 - 10:33 AM, said:

So DOTA 2 (and more coming) is not a AAA game?

I do consider it an AAA game, but as other mention, it is pretty basic in the graphics department, even though it looks good as such.

But the main point here is more that MoltenVK is not supporting the full set of Vulkan features, making it unuseable for many modern AAA games.

[UmarOMC1]

MoltenVK Sees Big Update To Jump-Start Vulkan On macOS In 2019

Changes noted on their GitHub changelog;

• Support runtime config via runtime environment variables
  
• Add full ImageView swizzling to config, and disable it by default.
  
• Add GPU switching to config, and enable it by default.
  
• Add queue family specialization to config, and disable it by default.
  
• Enable synchronous queue submits as config default.
  
• Support 4 queue families.
  
• Pad fragment shader output to 4 components when needed.
  
• Add support for copying to and from PVRTC images.
  
• Log Vulkan versions in human readable form when reporting version error.
  
• Update VK_MVK_MOLTENVK_SPEC_VERSION to 16.
  
• Update copyright to 2019.
  
• Advertise the VK_AMD_gpu_shader_half_float extension.
  
• Support the VK_KHR_variable_pointers extension.
  
• MoltenVKShaderConverter tool exit with fail code on any file conversion fail.
  
• Update to latest dependency libraries for Vulkan SDK 1.1.97.
  
• Update to latest SPIRV-Cross version:
  
  • MSL: Support SPV_KHR_variable_pointers.
    
  • MSL: Workaround missing gradient2d() on macOS for typical cascaded shadow mapping.
    
  • MSL: Fix mapping of identity-swizzled components.
    
  • MSL: Support composites inside I/O blocks.
    
  • MSL: Fix case where we pass arrays to functions by value.
    
  • MSL: Add option to pad fragment outputs.
    
  • MSL: Fix passing a sampled image to a function.
    
  • MSL: Support std140 packing rules for float[] and float2[].
    
  • MSL: Fix image load/store for short vectors.
    
  • Performance improvements on iterating internal constructs.
    
  • Update copyright to 2019.

[Janichsan]

Holy crap, MoltenVK is already one year open source? The time flies…

Anyway, the more interesting question would be if the so far very limited feature set supported by MoltenVK has been in any way extended to match the Windows/Linux Vulkan desktop feature set. From this change log, it doesn't really look that way.

And another thing: "…so far the likes of Feral Interactive and Aspyr have been quiet on whether they plan to use MoltenVK to ease their porting burden." That is wrong, though. Feral has made very clear that they won't use MoltenVK, as they have an existing and well-working Metal development pipeline.

[Boland]

Janichsan, on 21 January 2019 - 06:55 AM, said:

Holy crap, MoltenVK is already one year open source? The time flies…

Anyway, the more interesting question would be if the so far very limited feature set supported by MoltenVK has been in any way extended to match the Windows/Linux Vulkan desktop feature set. From this change log, it doesn't really look that way.

And another thing: "…so far the likes of Feral Interactive and Aspyr have been quiet on whether they plan to use MoltenVK to ease their porting burden." That is wrong, though. Feral has made very clear that they won't use MoltenVK, as they have an existing and well-working Metal development pipeline.

Regarding the  "…so far the likes of Feral Interactive and Aspyr have been quiet on whether they plan to use MoltenVK to ease their porting burden."
It's simply the fantasies of what's mainly a Linux site... As you said, Feral have been very clear about it.

On another note.. MoltenVK still sucks (looks at ESO).

[jeannot]

Did a quick comparison today on Dota2. The moltenVK version is not faster than the openGL one at 1080p on my 5K iMac running Mojave.
At >4k (4096*something), it's ~25% faster than openGL
Vulkan/DX11 on Windows is ~55% faster than moltenVK at 1080p. Clearly, the translation layer comes at a CPU cost.
The openGL windows version appears bugged. Too bad, it would have been nice to compare to macOS openGL.

[jeannot]

Vulkan is still pretty niche, but with Google Stadia using it, this could change radically, provided the service takes off.
That also means a lot for Linux gaming since Stadia games will be Vulkan-Linux games running on Google's servers. It remains to be seen whether these games will be released to Linux users. That's not a given. What's clear is that developers will have to port their games to Vulkan and Linux if they want them on Stadia.
In the end, Apple may end up being even behind Linux in terms of gamers and Metal might effectively become limited to iOS/tvOS. If that's the case, not having Vulkan on macOS is going to hurt us a lot more than initially thought.
It's unclear whether Apple actually forbids Vulkan on macOS or just does nothing particular to support it. But given the current nVidia affaire, I can see Apple not signing Vulkan drivers.
With the ban of 32-bit games, Apple really makes it harder for gamers every day.

[Janichsan]

jeannot, on 07 April 2019 - 01:15 AM, said:

It's unclear whether Apple actually forbids Vulkan on macOS or just does nothing particular to support it.

The latter. The way macOS is structured, (native) Vulkan support has to come from Apple.

Quote

But given the current nVidia affaire, I can see Apple not signing Vulkan drivers.

Even if third-party developers like Nvidia or AMD wanted, they can't just add low-level support for a new graphics API to macOS. The parts that would have to be changed to add native Vulkan support, are off-limits to everyone but Apple. macOS works differently in that regard to Windows and so extent even Linux.

This is not a new thing, but is part of its design since Mac OS X 10.0. It's the same reason why third-party developers couldn't simply add support for more modern versions of OpenGL, as they do under Windows.

[jeannot]

I've never heard that macOS was different from other OSes in that respect.
I fail to see why a GPU vendor couldn't develop a Vulkan/OpenGL driver for macOS on its own, especially considering that the Darwin kernel is open source,. Would you care to explain?

[Janichsan]

jeannot, on 07 April 2019 - 05:32 AM, said:

I've never heard that macOS was different from other OSes in that respect.
I fail to see why a GPU vendor couldn't develop a Vulkan/OpenGL driver for macOS on its own, especially considering that the Darwin kernel is open source,. Would you care to explain?

Darn. I had pretty much the same discussion a year or two ago over in the Elite Dangerous forums, regarding the question why the GPU vendors don't simply add their own, updated versions of OpenGL to macOS when Apple isn't willing to do so. I had found a great website with an explanation back then, with excellent diagrams which made the differences in implementation between macOS, Windows, and Linux clear. Unfortunately, I can't no longer find that page (and FDev have completely deleted the old Mac subforum when they updated their forum earlier this year, so I can even no longer go back to my old posts… ). So I'll have to try to explain it on my own.

First of all, that macOS's kernel is open source has absolutely no consequence for this whole matter. Aside the fact that (as you might have noticed) you can't simply modify macOS's kernel, the graphics interfaces such as OpenGL, Metal, and Vulkan are part of the OS's user space, which is a whole step remote from the kernel space. The components of the user space are closed source under macOS.

The user space would also be were the major differences between macOS, Windows, and Linux lie. The diagrams I mentioned above would have clearly shown that.

Windows and Linux offer interfaces to add certain features such as newer versions of OpenGL or Vulkan to the user space as so called "Installable Client Drivers" (which – despite the name – are something very different than device drivers such as GPU drivers).

macOS has no such interfaces.

In the end, it's as simple as that: you can't add your own Vulkan/OpenGL driver to macOS because Apple does not give you a way to do so.

[jeannot]

Are you sure that the page you're referring to did not just describe difference in implementations, rather than differences in capabilities?
I know that GPU vendors don't provide their own OpenGL implementation in macOS drivers, as opposed to what's available on Windows. What I've never heard, though, is that macOS does not support installable client drivers.
The fact that Nvidia provides CUDA on macOS (when Apple approves their drivers, that is) suggests that GPU vendors can implement their own APIs... If it's possible for CUDA, why not Vulkan? What's the fundamental difference between a compute API and a 3D API?

[Janichsan]

jeannot, on 10 April 2019 - 12:21 AM, said:

Are you sure that the page you're referring to did not just describe difference in implementations, rather than differences in capabilities?

Thanks, yes, I'm sure.

Quote

What I've never heard, though, is that macOS does not support installable client drivers.

You live to learn something new every day. But let me put it this way: if there were something like ICDs in macOS, you'd assume that someone would have made use of them in almost 20 years of Mac OS X/macOS, especially in the times before Gatekeeper and SIP.

Quote

The fact that Nvidia provides CUDA on macOS (when Apple approves their drivers, that is) suggests that GPU vendors can implement their own APIs... If it's possible for CUDA, why not Vulkan? What's the fundamental difference between a compute API and a 3D API?

I have to admit that I do not really know how CUDA is implemented. From what I have found, it does not seem to be an ICD even under Windows and Linux.

But as you mention it: there is in fact a fundamental difference between a compute API and a graphics API. Simply put, in a compute API you shove numbers in and get nothing but numbers out. The results you get from the compute API are pretty much completely independent from any other component of the operating system. They are just numbers.

This is very different in a graphics API: if you want to get the graphics your API spits out on the screen, you will have to interact with other parts in the user space, such as the windowing system. Basically, you are dependent on some kind of interfaces between your API and the rest of the OS. This is not really the case for pure compute APIs.

[macdude22]

There's a kernel interface to get compute data in and out of system busses. There's no kernel interface for a new graphics API. Because of privilege boundaries it would be difficult and/or slow for someone to develop and implement a low level graphics API like Open GL. It can be done but the end result is often subpar. See Duet Display. Any casual thought of outright replacing the OpenGL frameworks went out the window with SIP and the available kernel interfaces don't cut the mustard for a graphics API.

The user graphics of OS X is handled by the `WindowServer` process along with I/O Kit. User graphics combined with kernel graphics could be considered the analogue of `win32k.sys` on Windows. The user graphics part of macOS is handled in a separate process while Windows provides the GDI32 APIs which calls “win32k.sys` directly. Apple’s approach could be considered more secure as user memory is not shared between processes. Anyone who disagree's should look at the hundreds of vulnerabilities and exploits involving GDI over the years.

[jeannot]

macdude22, on 10 April 2019 - 09:09 AM, said:

The user graphics of OS X is handled by the `WindowServer` process along with I/O Kit. User graphics combined with kernel graphics could be considered the analogue of `win32k.sys` on Windows. The user graphics part of macOS is handled in a separate process while Windows provides the GDI32 APIs which calls “win32k.sys` directly. Apple’s approach could be considered more secure as user memory is not shared between processes. Anyone who disagree's should look at the hundreds of vulnerabilities and exploits involving GDI over the years.

Does it mean that providing support for third-party graphics APIs is more difficult on macOS because of security reasons?
I just wonder if the reasons behind all this relate to Apple wanting absolute control and no competition, or whether there are technical justifications.