Will APPLE ever make good Driver to Acess his GPU like NVIDIA is doing ?

[InwardMomentum]

I mean , We all know that apple have enough resources to do this , And that The new Apple silicon MAX cpu with 32 core of GPU is very powerfull and efficient ,if we think about power consumptions.

What I am wondering is , Does the low framerate for gaming a Driver problems ? And about the Deep learning field , with no good drivers , its very hard ( lets say , too much time consuming ) to acess the GPU acceleration.

What we know is that Nvidia driver excel for both of these problem , And my guess for the low performance in gaming and Machine learning of the apple computer is all about Drivers.

So the big question is , Will apple ever put the same effort as NVIDIA to acess his GPU , as I think this will be a game changer for the PC world, as a lot of people dont want to go for apple because of that. ( and It can save a lot of ENERGY )

Am I right or wrong on the subject?

Good day to you.

 

[JohnHerzog]

I think interoperability is an objective for all technology companies to facilitate the proliferation of their products and services and that over time this homogeneous compatibility will become a reality

 

[leman]

Apple GPU drivers are excellent, I am not sure what problem do you think there is? The rest is up to the software devs.

 

[T'hain Esh Kelch]

I think OP is confusing GPU drivers with Graphical APIs and cost/benefit for porting software.

 

[leman]

I agree, there seems to be a lot of confusion going on with OP

 

[Xiao_Xi]

I think OP is confusing GPU drivers with Graphical APIs and cost/benefit for porting software.

Apple could adopt standards like Vulkan or make a library to convert CUDA code to Metal.

And about the Deep learning field , with no good drivers , its very hard [...] to acess the GPU acceleration.

Apple will fix the problem with deep learning libraries when it finishes its half-baked Tensorflow plugin.

 

[leman]

Apple could adopt standards like Vulkan

They most certainly will not. Why would they sabotage their own ecosystem?

 

[Xiao_Xi]

Why would they sabotage their own ecosystem?

Standards make development easier and cheaper. Vulkan natively in Apple hardware could reduce the cost of ports and eliminate the need for MoltenVK. Using Metal instead of VoltenVK could be too costly for some apps. For example, Blender planned to use MoltenVK instead of Metal for the viewport.

 

[Boil]

Standards make development easier and cheaper. Vulkan natively in Apple hardware could reduce the cost of ports and eliminate the need for MoltenVK. Using Metal instead of VoltenVK could be too costly for some apps. For example, Blender planned to use MoltenVK instead of Metal for the viewport.

Isn't the use of MoltenVK for the Blender viewport a decision for cross-platform support...?

 

[leman]

Standards make development easier and cheaper. Vulkan natively in Apple hardware could reduce the cost of ports and eliminate the need for MoltenVK. Using Metal instead of VoltenVK could be too costly for some apps. For example, Blender planned to use MoltenVK instead of Metal for the viewport.

That’s the benefit for third party, sure, but where is the benefit for Apple? By officially adopting Vulkan Apple has to submit to the hegemony of the mainstream GPU makers and the committee. Let’s not forget that Apple was an original developer of OpenCL and an initial backer of Vulkan, they de-facto withdrew their participation from Kronos (although they remain a core member) when it became clear that there was no practical way towards a unified vision.

Also, let’s not forget that Apple contributed OpenCL shortly after Longs Peaks went down the drain (we do not know which committee member killed it, my bet is on Nvidia). Metal was released couple of years later, when Apple became disillusioned with the lack of committee progress.

 

[T'hain Esh Kelch]

Apple could adopt standards like Vulkan or make a library to convert CUDA code to Metal.

Standards make development easier and cheaper. Vulkan natively in Apple hardware could reduce the cost of ports and eliminate the need for MoltenVK. Using Metal instead of VoltenVK could be too costly for some apps. For example, Blender planned to use MoltenVK instead of Metal for the viewport.

But Metal is already a standard - There are literally more than a billion phones, tablets and computers who run Metal. It is merely a question of developers actually learning to use it properly.

On the Windows side, since most development is done in DirectX, which means that Vulkan development is an added hurdle in most cases. And then you would have to do additional porting, to get proper MoltenVK support, instead of just jumping directly to Metal. I agree that it would be awesome to get MoltenVK officially supported by Apple, and it would be a great start, but it likely would just ensure that Metal would never get proper support going.

 

[Xiao_Xi]

Metal is already a standard

You can consider Metal an industry-standard in mobile platforms, but not in computers.

By officially adopting Vulkan Apple has to submit to the hegemony of the mainstream GPU makers and the committee. Let’s not forget that Apple was an original developer of OpenCL and an initial backer of Vulkan, they de-facto withdrew their participation from Kronos (although they remain a core member) when it became clear that there was no practical way towards a unified vision.

Leader companies dictate terms, sabotage open standards and use vendor lock-in to keep their dominance. Nvidia hampers the development of any API that can endanger CUDA hegemony. So, AMD had to develop tools that translate CUDA code instead of using OpenCL.

That’s the benefit for third party, sure, but where is the benefit for Apple?

macOS users would get better software. For example, Blender for macOS would be less optimized because Blender devs never planned to use Metal for the viewport. So, Apple has to pay a developer to create a Metal backend to optimize Blender por macOS.

Isn't the use of MoltenVK for the Blender viewport a decision for cross-platform support...?

Blender devs are rewriting the viewport to support Vulkan because they believe Vulkan is the future in the PC. MoltenVK helps to port PC apps to Macs.

 

[leman]

macOS users would get better software.

What makes you so confident about it? First-class support for Vulkan would mean that macOS users would get applications that targets common denominator hardware, not Mac hardware.

For example, Blender for macOS would be less optimized because Blender devs never planned to use Metal for the viewport. So, Apple has to pay a developer to create a Metal backend to optimize Blender por macOS.

That's between Blender and Apple. Financially, it makes more sense for Apple to pay devs to optimise popular software for their platform rather then give up their autonomy in exchange for better software support.

Please also keep in mind that Apple is not after instant gratification here. Their game is much much longer. For example, the smooth ARM transition we see now started years ago, when Apple started slowly but surely deprecating 32bit support. Metal and GPU will be similar. It will take years for the Mac to become an acknowledged force in the GPU market, but when (and if) that times, comes, Apple's gambit will pay off hundred times over. Having an API that plays to the strength of your hardware instead of accepting artificial limitations cause "Nvidia said so" is a huge thing.

 

[leman]

P.S. Personally, I think it might a good idea for Apple to add some compatibility features to Metal that would more closely align to certain Vulkan and DX abstractions (wrt. to bindings btw). This will simplify the life of the porting houses without really sabotaging Metal itself, since Metal will stay superior. Also, add more advanced C++ support to MSL, an MSL to SPIRV compiler and a CUDA to MSL compiler. Metal shading language is vastly better than GLSL or HSL, if cross platform tooling were available it could help Metal adoption.

 

[Xiao_Xi]

First-class support for Vulkan would mean that macOS users would get applications that targets common denominator hardware, not Mac hardware

Apple could help Vulkan to make it 100% compatible with Apple hardware.

Metal shading language is vastly better than GLSL or HSL, if cross platform tooling were available it could help Metal adoption.

Apple could make Metal SL open-source and donate it to Khronos to improve Metal SL adoption.

It will take years for the Mac to become an acknowledged force in the GPU market, but when (and if) that times, comes, Apple's gambit will pay off hundred times over.

Instead of adopting APIs that can benefit Apple customers from day one, Apple has decided to take advantage of its customers' patience to increase its vendor lock-in. It is a risky bet that only will benefit Apple.

 

[JMacHack]

Instead of adopting APIs that can benefit Apple customers from day one, Apple has decided to take advantage of its customers' patience to increase its vendor lock-in. It is a risky bet that only will benefit Apple.

As opposed to the commitment to open libraries like NVIDIA?

 

[avkills]

As opposed to the commitment to open libraries like NVIDIA?

nVidia does not support open libraries at all.

 

[leman]

Apple could help Vulkan to make it 100% compatible with Apple hardware.

Apple can add Vulkan extensions that take advantage of unique features of Apple hardware... but there is the thing: one would still need to write specialised code to use these extensions. Most devs would probably not bother and just deliver the solution that caters to the lowest common denominator.

Apple could make Metal SL open-source and donate it to Khronos to improve Metal SL adoption.

Like what they did with OpenCL? Why would that work better this time?

Instead of adopting APIs that can benefit Apple customers from day one, Apple has decided to take advantage of its customers' patience to increase its vendor lock-in. It is a risky bet that only will benefit Apple.

Again, I see it differently. I think it will benefit the Mac long-term, because it will enable a more feature-full, easier to use development ecosystem. Add to this the fact that the next-gen WebGPU API is largely based on Metal and you'll see the logo-term game Apple is playing.

The thing is, I used to be a passionate proponent for open standards in GPUs. Around 15 years ago, I was very involved in the OpenGL community. As the time passed and fiascos accumulated, it became clear to me that a committee is not a good way to manage these things. In fact, my attitude had an 180 degree turn. I think that every hardware vendor should just have their own proprietary APIs which allow them to innovate freely, and layers such as Vulkan should be implemented on top of them. There is just too much compromise and too little movement.

 

[InwardMomentum]

Thanks for all the replys guys !

It have deepend my knowledge about the issues.

Ill put some homework on understanding Metal more, And how it work with games, and all other task.

I really see those ARM chip taking over the pc market , as their are so much more power efficient.

 

[JMacHack]

Thanks for all the replys guys !

It have deepend my knowledge about the issues.

Ill put some homework on understanding Metal more, And how it work with games, and all other task.

I really see those ARM chip taking over the pc market , as their are so much more power efficient.

There’s occasional enlightening posts around here.

A little backstory on Metal: Apple designed it during a period when OpenGL was stagnant, and before Vulkan existed. Apple was originally a member of Khronos Group, the group behind Vulkan, but left eventually.

We can speculate whether it was because they felt Metal would be a better platform, or whether it’s for the sake of vendor lock in. Either way, Apple chose Metal over Vulkan. CUDA was never an option after they severed ties with NVidia.

For games and gaming development, APIs typically play a big role behind the scenes, but not so much in typical development, which is often in engines that obfuscate away things like Metal, DirectX, and the like. It’s mostly relevant to the people programming the engines and tools ised for game development.

As for where the industry goes, we don’t know.

 

[Xiao_Xi]

nVidia does not support open libraries at all.

Companies create proprietary or open-source libraries depending on whether they will help them to sell or not. Market leaders like Nvidia tend to create proprietary libraries like DLSS or CUDA because they reinforce their market leadership. If Nvidia fell behind AMD and Intel in GPU market share, Nvidia would make CUDA and DLSS open-source or adopt open standards.

By the way, contrary to AMD or Apple, Nvidia regularly donates vendor-agnostic code to Blender. Why? Because Nvidia knows that the better Blender is, the more Nvidia GPUs people buy.

Most devs would probably not bother and just deliver the solution that caters to the lowest common denominator.

The situation would be slightly better if Apple adopted the Vulkan API natively. Currently, devs code for lowest common denominator and need to use MoltenVK.

Like what they did with OpenCL? Why would that work better this time?

What could Apple lose by making Metal SL open-source? If other companies don't adopt it, Apple can keep developing it for its hardware. If other companies use it, Apple can share the development with them.

I think that every hardware vendor should just have their own proprietary APIs which allow them to innovate freely, and layers such as Vulkan should be implemented on top of them. There is just too much compromise and too little movement.

It could work if all the players had a similar market share. But, Nvidia is the undisputed leader, and it will hamper any project that threatens its sales.

Proprietary or open standards/libraries are not good or bad per se. Proprietary standards/libraries become useless when they are worse than their open counterparts. For example, Apple started to use the USB only on the iPad (and not in the iPhone) because I imagine that it considered that the lightning connector could harm iPad sales.

 

[leman]

A little backstory on Metal: Apple designed it during a period when OpenGL was stagnant, and before Vulkan existed. Apple was originally a member of Khronos Group, the group behind Vulkan, but left eventually.

Apple is still listed as a promoter member of Khronos, although they do not show much participation as of later.

We can speculate whether it was because they felt Metal would be a better platform, or whether it’s for the sake of vendor lock in. Either way, Apple chose Metal over Vulkan.

The interesting thing is that Apple was on board of the original Vulkan backers, but completely disappeared from the list shortly before the initial Vulkan spec has been made available. We don't know the reasons behind it, but I don't think it is very difficult to guess:

- Vulkan ist a notoriously cumbersome and difficult to use API, Apple instead wanted something that devs could pick up quickly
- Vulkan is too much of a committee-designed common denominator API
- Apple's hardware vision would require a new "Apple Vulkan" dialect anyway

Once you consider these factors (and add in the mix of "we can do it better"), the rest is history.

The situation would be slightly better if Apple adopted the Vulkan API natively. Currently, devs code for lowest common denominator and need to use MoltenVK.

I think it's a bit of the other way around: devs who target the lowest common denominator use MoltenVK. Devs who are interested in better performance/compatibility use Metal directly. Of course, it is difficult to speculate on "what if when".

What could Apple lose by making Metal SL open-source? If other companies don't adopt it, Apple can keep developing it for its hardware. If other companies use it, Apple can share the development with them.

Ecosystem fragmentation and susceptibility to embrace, extend, and extinguish strategies. The last thing Apple wants is another company forking their own flavour of Metal. On the other hand, making Metal compiler backend pluggable would allows many interesting things — like for example compilation for Nvidia PTX directly.

Proprietary or open standards/libraries are not good or bad per se. Proprietary standards/libraries become useless when they are worse than their open counterparts.

I fully agree. And in the context of this discussion, I would consider it very petty from Apple if their Metal was just a crappy copy of DX/Vulkan. In the beginning, it kind of was, original Metal was basically DX11 "light" with a bit more syntactic sugar and user friendliness. But the subsequent releases made Metal a fully-featured API with its own separate design and vision, which I personally consider to be superior to Vulkan and DX12 in many areas.

 

[l0stl0rd]

After reading this I think apple should bring out a new metal version.

We're Getting There — CrossOver Support for DirectX 12 | CodeWeavers Blog

By All Blogs | CrossOver support for DirectX 12 on Linux and Mac.

www.codeweavers.com

 

[Xiao_Xi]

We're Getting There — CrossOver Support for DirectX 12 | CodeWeavers Blog

By All Blogs | CrossOver support for DirectX 12 on Linux and Mac.

www.codeweavers.com

Can someone explain what "In general, Metal does tessellation differently, and is missing geometry shaders and transform feedback." mean?

 

[leman]

Can someone explain what "In general, Metal does tessellation differently, and is missing geometry shaders and transform feedback." mean?

In a nutshell:

- Tesselation is the GPU pipeline for generating geometric primitives from parametric surfaces (e.g. Bezier patches). Tessellation API is usually organised into three stages (programmable tessellation control shader, fixed-function tessellator proper and programmable tessellation evaluation shader). DirectX calls them differently, but the purpose is the same. These stages are there for historic reasons, it was implemented this way the first time and APIs kind of kept this schema to be backwards compatible. Now, Apple in their usual fashion decided that the "old way" is too cumbersome and have rolled their own approach to tessellation which relies on regular old compute shaders and vertex shaders (no special shader stages with their own names). Again, the end result is the same, and Apple's approach is arguably more sensible (as it is less idiosyncratic), but it does create difficulties when porting software from other APIs.

- Geometry shaders are special shader stages that can generate geometry for further processing. Their introduction is now generally regarded as a design mistake, as they are difficult to parallelise and therefore perform poorly (modern DX12 introduced mesh shaders to replace most advanced applications of geometry shaders). Apple never introduced geometry shaders in Metal — again, a "correct" decision (since geometry shaders suck), but one that makes porting some software that uses these shaders more cumbersome. Technically, Metal does not need these shaders as anything you would use them for can be easily done either in the vertex shader or compute shaders.

- Transform feedback is functionality for capturing transformed (after common shader stages) vertex data for further processing. I see it mentioned here and there that Metal does not support transform feedback, but it is not really true. Metal trivially supports this functionality via the regular pipeline — vertex shaders in Metal can write to memory. So if you want to store the transformed vertex data all you need is a vertex shader that saves the data to a buffer.

After reading this I think apple should bring out a new metal version.

We're Getting There — CrossOver Support for DirectX 12 | CodeWeavers Blog

By All Blogs | CrossOver support for DirectX 12 on Linux and Mac.

www.codeweavers.com

Quick note on the "500000 resources per argument buffer" limitation vs. DX12 "one million" — it's not as straightforward. DX12 limits refer to max number of descriptors (entries that described resource binding of some sorts). Metal limits refer to the max number of available texture or buffer resources. My guess is that DX12 applications will use more descriptors on average, since they have to access any kind of data via a descriptor — this is not the case for Metal, where directly provided data and things like textures can be bound within the same argument buffer. The differences in how APIs are approaching resource binding makes it difficult to compare.

I think that one can get very far by simply implementing these things without any regard to differences in API limits. It is highly unlikely that any shipping game actually makes use of DX12 limits (one million descriptors is a LOT), and if it does, well, there is not much one can do anyway, so one just has to crash.