Science Rules!

[T'hain Esh Kelch]

MoltenVK takes care of that.

OpenGL and CL will be phased out, and that will have some backslash.

MoltenVK is far from being in a state where it can be used to port anything reliably. Of course, the Dota2 port is a good indication on what may be possible, but from a commercial developers POV it still has very far to go. And being an open source project, I won't bet on anything just yet.

Dropping OpenGL will be terminal for Mac gaming until developers adopt Vulkan (in about 2-4 years). Even then if Apple doesn't play nice with Valve, they might drop MoltenVK which will be terminal for Mac gaming, period.

Most major AAA game developers are already publishing games using Metal, so the death of OpenGL and lack of MoltenVK will not be the death for Mac gaming. It will remain in the sorry state it has always been, but it won't be in a worse position.

iOS seems to do ok without it.

iOS does not have many AAA sized games going for it, so it isn't really comparable.

Everyone seems to build their opinion of the state of Mac gaming on the number of AAA games, lack of upgradeable hardware, and the frames per second they can get out of it, despite being able to run said games perfectly with modern hardware and the Mac having an enormous game library.

Ok, you made me go google. "Thunderbolt combines PCI Express (PCIe) and DisplayPort (DP) (specifically DisplayPort 1.2, same as the one used before Thunderbolt was introduced) into two serial signals" so what that means thunderbolt 2 just has a Mini DisplayPort inside it, just how usb c has thunderbolt 3, hdmi and DisplayPort and other things inside it. So you don't have to use T3 to transfer video, you could use hdmi for example. But for egpu you aren't transferring video, you transfer data for egpu to generate video that it will transfer through it's own ports.

But if you're aren't being an ass, all of these things are interchangeable in a conversation, ofc.

Allow me to clear it up:
USB-C is a connector, not an interfacing standard.
Thunderbolt 3 uses the USB-C connector, and so does most USB3.1 Gen 1 and Gen 2 and USB3.2 implementations, but USB3.x is not automatically using USB-C, as you can also get it with USB-A connectors. So no, USB-C does not “have Thunderbolt 3, HDMI and DisplayPort” - The Thunderbolt 3 interface uses an USB-C connector, incorporates the DisplayPort protocol, which in itself is backward compatible with the HDMI protocol.

 

[thingstoponder]

The game I am developing as a hobby is only using Metal and Vulkan. Metal is a pleasure to work with, a truly beautiful API, even though it has some bugs. Vulkan is kind of horrible



I don't think that will ever happen. Also, what do you mean by "Kronos graphics snubbed out"? Metal is certainly not going to replace Vulkan. Vulkan is a lower-level API that allows to use the hardware more efficiently — with some effort.

How much lower level is Vulkan? And how does DirectX 12 compare?
[doublepost=1528617669][/doublepost]

If I had to guess I bet Apple is super giddy about the idea of eGPUs. It means they can build prosumer products that can get a boost from existing computer graphics hardware. I think the next iteration of thunderbolt will solve the eGPU question completely.

The next version of PCI will be big. You'll get 8x speed with the 4x lanes of thunderbolt. Although I wonder if future versions of Thunderbolt with use more than 4 lanes and if you could use multiple Thunderbolt ports for eGPUs.

 

[leman]

Leman, what do you think about the new Metal 2 feature in Mojave? It seems that we're getting async compute and reusable command buffers. No geometry shaders though.

I also haven't found a comprehensive list of new features yet, but browsing through APIs and looking at WWDC slides, there are some rather dramatic changes this year.

Probably the most crazy thing is that Metal now supports creation of command buffers on GPU entirely. You can now emit draw commands, switch pipelines and resources using the GPU only. This seems to be similar to the VK_NVX_device_generated_commands Nvidia extension, only it appears to works across all Apple-supported hardware. I am not aware of any other API that would support this (except this Nvidia extension of course). Add to this the fact that Metal already could manipulate resource binding on shader level (again, I don't think that this is possible in Vulkan or DX12 but I am not sure) and you can do some quite crazy stuff. Other features induce explicit syntonisation primitives — something Metal was badly lacking — which allow fine-grained control of execution across queues and GPUs. I guess this is what you refer to with "async compute".

As to geometry shaders: I think I understand Apple's reason to omit them. Geometry shaders are simply bad design. They work agains GPU's parallel nature and that is also the reason why they have been plagued with performance problems. By omitting geometry shaders as a future, Apple forces you to think more critically about what you want to achieve and implement more efficient algorithms using compute shaders. I have to say, I like their API design (also how they did the tessellation shaders) more, its more elegant, compact, and just as powerful. Again, this is the instance where Apple didn't blindly go with the "traditional" design, but tried to improve things.

 

[Malus120]

I also haven't found a comprehensive list of new features yet, but browsing through APIs and looking at WWDC slides, there are some rather dramatic changes this year.

Probably the most crazy thing is that Metal now supports creation of command buffers on GPU entirely. You can now emit draw commands, switch pipelines and resources using the GPU only. This seems to be similar to the VK_NVX_device_generated_commands Nvidia extension, only it appears to works across all Apple-supported hardware. I am not aware of any other API that would support this (except this Nvidia extension of course). Add to this the fact that Metal already could manipulate resource binding on shader level (again, I don't think that this is possible in Vulkan or DX12 but I am not sure) and you can do some quite crazy stuff. Other features induce explicit syntonisation primitives — something Metal was badly lacking — which allow fine-grained control of execution across queues and GPUs. I guess this is what you refer to with "async compute".

As to geometry shaders: I think I understand Apple's reason to omit them. Geometry shaders are simply bad design. They work agains GPU's parallel nature and that is also the reason why they have been plagued with performance problems. By omitting geometry shaders as a future, Apple forces you to think more critically about what you want to achieve and implement more efficient algorithms using compute shaders. I have to say, I like their API design (also how they did the tessellation shaders) more, its more elegant, compact, and just as powerful. Again, this is the instance where Apple didn't blindly go with the "traditional" design, but tried to improve things.

Thanks for the rundown. I've been curious about this. I wonder if Apple could get you to speak at the WWDC Keynote next year... (/s but not really)
I couldn't believe when Craig got up on stage and was like "Metal, it's so great, check out this demo.... and moving on." It's like, did you add anything new or are you just patting yourself on the back? The whole keynote was a hot mess that kept me asking, "so.... what's actually new?..." Ugh.

 

[jeanlain]

Probably the most crazy thing is that Metal now supports creation of command buffers on GPU entirely. You can now emit draw commands, switch pipelines and resources using the GPU only. This seems to be similar to the VK_NVX_device_generated_commands Nvidia extension, only it appears to works across all Apple-supported hardware. I am not aware of any other API that would support this (except this Nvidia extension of course). Add to this the fact that Metal already could manipulate resource binding on shader level (again, I don't think that this is possible in Vulkan or DX12 but I am not sure) and you can do some quite crazy stuff. Other features induce explicit syntonisation primitives — something Metal was badly lacking — which allow fine-grained control of execution across queues and GPUs. I guess this is what you refer to with "async compute".

They just listed "async compute" on a slide. They also list something called "texture buffers", which to me sounds like a pretty basic feature (but I know almost nothing our 3D APIs. )

What's frustrating is that very few games appear to use cutting edge Metal features. Apparently UE4 doesn't use argument buffers or resource heaps (but it seems they don't use equivalent features on DX12 either). I suppose Unity isn't any better.
And while Metal-specific features are great, I don't see any ported engine using them. I get that porting an engine pertains to mapping what's done on DX11/12 to the closest Metal equivalent, sometimes using translation layers.
For an engine to use an API as its full potential, it has to be written with it in mind. I'm not sure such engine exist for Metal, even on iOS. Apple would have to release a true game console.

 

[827538]

On Windows or Mac?

I played those games on Windows.

 

[leman]

Thanks for the rundown. I've been curious about this. I wonder if Apple could get you to speak at the WWDC Keynote next year... (/s but not really)

Ahaha, its very kind of you, but I don't think I am nearly qualified enough to get such an invitation 3D programming is just a hobby currently, although I do have some illusions of grandeur as prospective indie game developer.

I couldn't believe when Craig got up on stage and was like "Metal, it's so great, check out this demo.... and moving on." It's like, did you add anything new or are you just patting yourself on the back? The whole keynote was a hot mess that kept me asking, "so.... what's actually new?..." Ugh.

Well, they can't really go into too much detail in the keynote. Individual sessions are much more informative. BTW, they are available for free at https://developer.apple.com and give much more insight into actual changes.

And while Metal-specific features are great, I don't see any ported engine using them. I get that porting an engine pertains to mapping what's done on DX11/12 to the closest Metal equivalent, sometimes using translation layers.
For an engine to use an API as its full potential, it has to be written with it in mind.

Very true. We are only in the early phases of next-gen APIs, and a lot of code is still based on "old" concepts and understanding of how graphics works. For instance, not too many games use DX12 as well. I am sure that we will see more and more utilisation of these features as time goes on though.

How much lower level is Vulkan? And how does DirectX 12 compare?

While I do not think I am qualified to give a concise answer (my exposure to Vulkan is basically just writing some very basic code + reading the documentation, and I never directly worked with DX12), I can at least try to sum up some key differences. With Metal, Apple attempted to create an API that is "close to Metal" while also remaining user-friendly. Vulkan, on the other hand, is explicit to the bone, sometimes obnoxiously so. You need to do your own memory management, resource metadata and access synchronisation has to be super precise etc. etc. Metal comes with much more "support" in this regard. You can (to a certain degree) do memory management yourself, but Metal can also do it for you. With Metal 2.*, you can also do synchronisation explicitly, but again, if you want, Metal can do it for you automatically, potentially losing some performance. Basically, explicitness (especially of the annoying kind) is to a certain degree opt-in in Metal, but this does not compromise the low-level nature of the API. Overall, Metal will have higher CPU overhead than Vulkan (and also DX12), but I don't think that this will be noticeable in a typical application. I believe that Apple has successfully managed to create a very adequate light abstraction over the hardware without alienating the programmer. And some things, like sharing data declarations between the shaders and your app code, are just beautiful.

I was very dissapointed when Apple dropped from the Vulkan support list, but I think I can guess some of their motivation. I believe that they wanted to have a user-friendly API, with opt-in expressiveness, since they wanted the devs to adopt it quickly. Vulkan is certainly not user-friendly Now, with Metal 2.1, it seems that the API finally reached a level where it can be used to achieve some really great things with very good performance. And all that, without going completely crazy trying to express your intent in code.

 

[leman]

BTW, for those interested in Metal, check out this WWDC presentation and the corresponding demo: https://developer.apple.com/videos/play/wwdc2018/607/

They demonstrate how to draw highly complex objects entirely on the GPU, with minimal CPU involvement. The GPU is used to detect visible objects (going as far as checking visibility of small patches within your geometry!), select the level of detail, dispatch the draw calls and then finally draw the scene. This is very exiting stuff and I do not (correct me if I am mistaken though) think that you can do anything like this using Vulkan (maybe with some vendor-specific extensions?) or DX12 currently. This is truly next-gen technology for computer graphics and allows you to dramatically improves the efficiency of your code. Actually, this is exactly the stuff that graphics people have been dreaming of for years. But it requires one to radically change the approach to constructing redesign pipelines. Kind of like going from single-threaded programming to multi-treaded.

 

[thingstoponder]

While I do not think I am qualified to give a concise answer (my exposure to Vulkan is basically just writing some very basic code + reading the documentation, and I never directly worked with DX12), I can at least try to sum up some key differences. With Metal, Apple attempted to create an API that is "close to Metal" while also remaining user-friendly. Vulkan, on the other hand, is explicit to the bone, sometimes obnoxiously so. You need to do your own memory management, resource metadata and access synchronisation has to be super precise etc. etc. Metal comes with much more "support" in this regard. You can (to a certain degree) do memory management yourself, but Metal can also do it for you. With Metal 2.*, you can also do synchronisation explicitly, but again, if you want, Metal can do it for you automatically, potentially losing some performance. Basically, explicitness (especially of the annoying kind) is to a certain degree opt-in in Metal, but this does not compromise the low-level nature of the API. Overall, Metal will have higher CPU overhead than Vulkan (and also DX12), but I don't think that this will be noticeable in a typical application. I believe that Apple has successfully managed to create a very adequate light abstraction over the hardware without alienating the programmer. And some things, like sharing data declarations between the shaders and your app code, are just beautiful.

I was very dissapointed when Apple dropped from the Vulkan support list, but I think I can guess some of their motivation. I believe that they wanted to have a user-friendly API, with opt-in expressiveness, since they wanted the devs to adopt it quickly. Vulkan is certainly not user-friendly Now, with Metal 2.1, it seems that the API finally reached a level where it can be used to achieve some really great things with very good performance. And all that, without going completely crazy trying to express your intent in code.

Is DirectX 12 kind of in between Vulkan and Metal when it comes to complexity and overhead? And is OpenGL significantly worse than all of them?

 

[NT1440]

Thanks for the rundown. I've been curious about this. I wonder if Apple could get you to speak at the WWDC Keynote next year... (/s but not really)
I couldn't believe when Craig got up on stage and was like "Metal, it's so great, check out this demo.... and moving on." It's like, did you add anything new or are you just patting yourself on the back? The whole keynote was a hot mess that kept me asking, "so.... what's actually new?..." Ugh.

...that’s what the entire session “what’s new in Metal” is for.

 

[jeanlain]

This is very exiting stuff and I do not (correct me if I am mistaken though) think that you can do anything like this using Vulkan (maybe with some vendor-specific extensions?) or DX12 currently.

I don't know if it's related, but the speaker says that more and more games determine the visibility of objects on the GPU.