Apple basically just released Proton for Mac

[Paul Thexton]

It does feel like people are getting a bit carried away by the game porting toolkit to me.  Yeah it's cool to see these games running through Rosetta2 -> Wine -> MoltenVK/SomeOtherThing (DXMetal was it?) on Macs, but keep in mind Apple are specifically touting this as a way for developers to get an initial indication of where their baseline is should they want to port their game to Mac.

 

This isn't really Proton for Mac, even if enthusiasts are going to try and use it like it is.

 

What I find interesting is that Apple are putting real effort in to providing tools to take the pain out of porting, where-as their previous attempts to woo game developers to their platform was to simply stand on stage and say "Metal is great! Woo!"

[Paul Thexton]

4 hours ago, Fasterthannothing said:

honestly that's amazing 

It's legitimately cool. I just kinda hope that the developers of those games see it / try it / want to do something with it. If they don't, then it's simply just a cool side show I'm afraid.  Maybe if Crossover can convince Apple to let them use that DXMetal library as an official part of Crossover it might have some legs, but others have said the licensing for it seems pretty restrictive.

[Obioban]

14 minutes ago, Paul Thexton said:

It does feel like people are getting a bit carried away by the game porting toolkit to me.  Yeah it's cool to see these games running through Rosetta2 -> Wine -> MoltenVK/SomeOtherThing (DXMetal was it?) on Macs, but keep in mind Apple are specifically touting this as a way for developers to get an initial indication of where their baseline is should they want to port their game to Mac.

 

This isn't really Proton for Mac, even if enthusiasts are going to try and use it like it is.

 

What I find interesting is that Apple are putting real effort in to providing tools to take the pain out of porting, where-as their previous attempts to woo game developers to their platform was to simply stand on stage and say "Metal is great! Woo!"

For me at least, I don't care that much about performance demanding games, so the above is fine (even if not the intent). The most compelling reason for me to boot up my gaming PC at the moment is C&C remastered, which could probably be run fine with a mac emulating a PC emulating a mac emulating a PC. It's a game I literally originally played on DOS

[hishnash]

1 hour ago, Paul Thexton said:

What I find interesting is that Apple are putting real effort in to providing tools to take the pain out of porting, where-as their previous attempts to woo game developers to their platform was to simply stand on stage and say "Metal is great! Woo!"

Yer the emulator is mostly there just so that a dev on the team at the game studio can have somthign running and point to it and say to the PM team "look it runs and if we do X we can have it run 2x to 3x better lets do dit."  The history of most Macs having such underpowered GPUs means many PM in gaming might just assume thier game cant run  all on any Mac, no point putting in R&D spend if its only going to run on top end Studio with an Ultra chip as there are no users using that device.  Only relay worth porting if it runs on M1 and runs well on M1 Pro models as that is the majority of the market.

The real thing that helps the porting and most improtantingly reducing the on-going cost of the port is the HSLS -> Metal IR compiler. This is not a source code translator like other solutions that tend to have a laid if issue you need to hand tune this is a compiler backend to LLVM to adapt the HSLS -> LLVM IR pipeline to then map two Metal IR, (part of the magic of LLVM).  This means studios can keep having just one set of files for all thier shaders across both platforms.  Then the work needed to call the nessarery metal apis is not that large, even in a complex game engine there will be only a few hundred calls sites were your calling DX directly an most modern titles are using middleware's for audio, input etc so these already support apples respect sys apis. 

 

 

It used to be that you would need to use some HSLS to metal converter that create metal shader code files (with bugs) fix them then update the code paths (and somehow deal with your tesolation and geometry stages... in a compute shader maybe) making your pipeline much more complex and no longe match your DX pipeline at all.  Then you would also need to rewrite your audio system apis and your user input, and many of these used to be only in object-c so you then needed to write a lot of bridging headers to access them (all very painful). 

 

The other big change this year that people might not think helps porting but will is the new swift c++ interlope. This means you can write code in swift (to talk to system apis) and call it directly form C++ in a much easier way than using objective-c. Any C++ dev will find swift easy to pickup and this lets them integrate into system features, that do not have a c++ api much easier and much cleaner. 

[Brooksie359]

7 hours ago, jesus123 said:

I think you are just equaling Mac users with iPhone users.

there are many cases where you need to follow simple Instructions and just copy pasting code into the the terminal. It’s nothing seriously new. The terminal in Mac is more Present for the average user than it is on windows. That’s not saying every Mac user knows it of course but I doubt the average Mac User is a bigger noob in terms of terminal than the average windows user. 
 

 And again you can implement all of this steps in a nice GUI and you don’t need to ever touch the terminal again. So what’s your point exactly?

My point is that this is only ever going to be a niche use case for tech savvy people and won't really influence the relevance of Mac gaming to any significant degree. First and foremost people have to know this even exists which is a big hurdle as this is just some code on github and not something built into say steam. Also you are thinking way to highly of average users. Anyways I think this is cool but not going to change much and Mac gaming is still going to be niche until we see more games ported to Mac officially or a big player like steam builds this into their launcher. 

[hishnash]

Just now, Brooksie359 said:

Mac officially or a big player like steam builds this into their launcher. 

The license explicitly prohibits this. 

It will have an effect on Mac gaming in the amount of games that get ported. 

[Brooksie359]

1 hour ago, hishnash said:

The license explicitly prohibits this. 

It will have an effect on Mac gaming in the amount of games that get ported. 

I am aware that the license prohibit this which is why I said this doesn't do much. I also did say Mac gaming wouldn't be relevant until more games get ported over officially so yeah I would agree that if this does actually increase the amount of games ported then it could be a big deal but I feel like that is uncertain at this point. I'm not saying that Mac gaming can't be good I am just saying we are far from there yet and this isn't as big of a breakthrough as op made it sound like. 

[hishnash]

48 minutes ago, Brooksie359 said:

it could be a big deal but I feel like that is uncertain at this point.

I think the emulation tool will be a big deal when it comes to getting buy-in from Product manager to put work into building a port. The other things they released will make the porting proses a lot easier and make maintaining a port much easier (the maintain is the most important part as this tends to cost much more than doing the port in teh first place)

[hishnash]

12 hours ago, AluminiumTech said:

That's not how computer graphics and game optimisation works. Also to get anywhere near that level of optimisation out of AS for gaming would effectively require not optimising the game for AMD or Nvidia at all.

In perciualre for older engine (not Unreal 5 that uses nanite) the HW culling of overdraw fragments does save a massive amount of gpu time, however to do this you need to completely re-organise your rendering stack, best is that if for each projection you have just one render pass and use tile compute passes within it to manage this. 

Most games (not including things like the latest unreal) will have 200%+ overdraw, or put in another way 1/2 of the fragment function calls end up being useless as it turns out something else is infont of it and the result of that fragment is discarded.  On AMD, NV and Intel gpus there are methods to fake a deferred rendering pipeline but first doing a very cheaper Redner pipeline so that the cost of the overdraw is low and then use this to either stencil out geometry when you do a follow up or use a compute shader to directly shade the visible pixels however this still has a cost both in fragment compute and in memory bandwidth. 

The advantage of the HW culling of obscured fragments can not be understated and for games that fully optimise for this you can see massive gains of the order I described.  

 

As I said above however this does not apply to the most recent of engines like Unreal5 that have bene written from the ground up to avoid this issue. 

 

The other benefits (when comparing to 10seires NV gpus) are in GPUs features for pixel formats, and mesh shader support etc, this also requires devs put in a lot of work. I expect however that devs that wish to ship games for the headers will be doing this work for apple silicon. 
 

[Brooksie359]

3 hours ago, hishnash said:

I think the emulation tool will be a big deal when it comes to getting buy-in from Product manager to put work into building a port. The other things they released will make the porting proses a lot easier and make maintaining a port much easier (the maintain is the most important part as this tends to cost much more than doing the port in teh first place)

What is there to maintain? I mean unless you are adding more content I don't see why you would have to maintain it especially because Mac hardware is very fixed and the there are very limited configurations. 

[hishnash]

23 minutes ago, Brooksie359 said:

What is there to maintain? I mean unless you are adding more content I don't see why you would have to maintain it especially because Mac hardware is very fixed and the there are very limited configurations. 

As you fix bugs, but also new content, many modern games make money not just with upfront purchase but also "loot boxes" as such gamers expect consists updates. 

 

But also during development at some point the evenge code will be mostly locked down and while you might be updating shaders etc, being able for the metal backend to share the same shader sorucecode means the lower level display stack devs could start on the metal impmenation after they finish the DX impatiens well before the game ships without risking without creating loads of extra work as the game is improved before release. 

[HomeBoi]

This will severly impact my next choice of home PC / Game station. If a Mac now can run my games i want to play, it might be bye bye windows for good. Apple tax is harsh but you know, using apple in every other thing i do except gaming so..

[dilpickle]

https://www.ign.com/articles/whoopi-goldberg-really-wants-blizzard-to-release-diablo-4-on-mac

[maplepants]

21 hours ago, dilpickle said:

https://www.ign.com/articles/whoopi-goldberg-really-wants-blizzard-to-release-diablo-4-on-mac

If this isn't on the next TechLinked I'll be very disapointed. 

[saltycaramel]

Someone send her this guide

 

https://www.outcoldman.com/en/archive/2023/06/07/playing-diablo-4-on-macos/

[WolframaticAlpha]

On 6/8/2023 at 12:47 AM, hishnash said:

HSLS -> LLVM IR pipeline to then map two Metal IR, (part of the magic of LLVM)

Why did it take them so long to do it then? DXC has been based off of LLVM since forever...

On 6/8/2023 at 12:47 AM, hishnash said:

The other big change this year that people might not think helps porting but will is the new swift c++ interlope. This means you can write code in swift (to talk to system apis) and call it directly form C++ in a much easier way than using objective-c. Any C++ dev will find swift easy to pickup and this lets them integrate into system features, that do not have a c++ api much easier and much cleaner. 

On a tangent, last time I tried calling C++ functions from a swift program, I had to use the absolute junk that obj c is. Considering how much simpler C++-swift interop seems now, do you think there might be swift in legacy mac codebases?

[Paul Thexton]

49 minutes ago, WolframaticAlpha said:

On a tangent, last time I tried calling C++ functions from a swift program, I had to use the absolute junk that obj c is. Considering how much simpler C++-swift interop seems now, do you think there might be swift in legacy mac codebases?

Where I work we're pretty happy with the official C++ interop support in the Swift language that was just added, well, happy that it's there, we've not tried using it yet... so time will tell.

 

Not sure what you mean with the swift in legacy mac codebases question, did you mean is there C++ in legacy mac codebase?

[WolframaticAlpha]

2 hours ago, Paul Thexton said:

Not sure what you mean with the swift in legacy mac codebases question, did you mean is there C++ in legacy mac codebase?

Asking whether swift-cpp interop is good enough that you can use swift now for legacy codebases, i.e. in a way similar to carbonlang. After reading some documentation , it doesn't seem so.

[hishnash]

3 hours ago, WolframaticAlpha said:

Why did it take them so long to do it then? DXC has been based off of LLVM since forever...

Its more than just a simple LLVM backend they also need to alter the shader pathways to lineup with the HW, For example the ability to them to take Geometry and Tessellation shaders and adapt them in that compiler so that they can be invested as function pointers into the Object Mesh pipeline without devs needing to re-write them.  
 

 

[Paul Thexton]

13 minutes ago, WolframaticAlpha said:

Asking whether swift-cpp interop is good enough that you can use swift now for legacy codebases, i.e. in a way similar to carbonlang. After reading some documentation , it doesn't seem so.

Ah ok... My initial thoughts are the same as yours, probably not right now. That said, Swift is an OSS project so who knows, over time it might get there.

 

Thankfully for me our interest in it is far more straightforward theoretically, we're probably not going to be putting significant effort in to seeing how useful it'll be for us until Xcode 15 comes out of Beta though.

[hishnash]

47 minutes ago, Paul Thexton said:

Ah ok... My initial thoughts are the same as yours, probably not right now. That said, Swift is an OSS project so who knows, over time it might get there.

 

This is a state goal of the team, they are already using swift within the swift compiler now that they have swift / c++ interlope and have the concept of consuming.  

I expect there are teams at apple (and maybe outside) that want to reduce the c++ usage and rather than go to rust (an option but maybe a very steam learning curve) gradually adopting swift for low level systems will happen. 

 

I would not be surprised if in 2 to 3 years someone dumps a realtime os firmware from one of apples little co-prosoreos and from linker headers or somthing figures out some of it is in swift.   

[Paul Thexton]

3 minutes ago, hishnash said:

rather than go to rust (an option but maybe a very steam learning curve)

I'm a big fan of rust, but that comes with the enormous caveat that I haven't used it enough for me to consider myself proficient in it and definitely not enough to run in to any of the more advanced use cases that can become annoyances.... Like any language there's always going to be something that people wish wasn't so esoteric, lifetime annotation syntax looks particularly ugly in Rust compared to the rest of the language features for example.

 

Rust can be demonstrably faster than Swift for certain types of operations, but that's not to say that Swift is a slow language either...

 

My guess would be that where performance is critical in core OS frameworks/components there'll still be the traditional C++/obj-c[++] mix, but that more and more userspace stuff that sits on top of the core will start to be "Swift first".

 

[hishnash]

5 hours ago, Paul Thexton said:

My guess would be that where performance is critical in core OS frameworks/components there'll still be the traditional C++/obj-c[++] mix, but that more and more userspace stuff that sits on top of the core will start to be "Swift first".

 

From my understanding if you write code in swift using the new ownership model with consuming it can be very simlare to c++ in perf, if your using high level swift were structs are copied and objects are all auto ref counted of cource you have a perf impact. 

[maplepants]

On 6/7/2023 at 8:06 PM, Paul Thexton said:

What I find interesting is that Apple are putting real effort in to providing tools to take the pain out of porting, where-as their previous attempts to woo game developers to their platform was to simply stand on stage and say "Metal is great! Woo!"

I agree with this, and want to add that it's good to see them change the encouragement direction a little.

 

When they first launched M1 it felt like they were trying to expand the gaming library by encouraging devs to go iPhone / iPad to Mac. And this move shows them putting some effort to going from Windows to Mac.

 

The M1 and M1 Pro offer pretty playable framerates at 720p and 1080p across a variety of games, and more VRAM than many beefier desktop cards (like the RTX 3060) due to the shared memory arcitecture.

 

I've been playing Weird West on my gaming PC, and in Apple's ideal future, any game like that which recommends a GTX 1050 should be playable on every Apple Sillicon Mac. Then more demanding titles like Cyber Punk would be playable on every Apple Silicon Mac with 16GB of RAM or more.

[Obioban]

They seem to actually care about this.

 

Developer porting guidance videos:

https://developer.apple.com/videos/play/wwdc2023/10123/

 

I'm strangely excited for this. If they actually succeed, I could stop having a gaming PC, and would probably end up playing more "PC" games as a result.

 

It does feel like there's a large confluence of things that could make Mac gaming (finally) a thing.

-Higher market share than ever before

-Every product they've made since Apple Silicon coming with a functional GPU (as in, there may be an inflection point where more Macs are capable of playing PC games reasonably than PCs, despite their smaller market share)

-iOS revenue dominance meaning that game engines tend to be more Apple framework friendly than ever before (and most frameworks being shared between iOS and MacOS)

-Real controller support

-A much simpler set of hardware targets (as in, a low number of CPUs/GPUs to target)

-Game mode in MacOS

-Porting becoming vastly easier.

 

I have a hard time seeing it not take off, at this point. I don't know what the average service life of a Mac is, but we're coming up on 3 years in.  Once a significant portion of people have made upgraded to Apple Silicon... quite the juicy development target for game devs.