Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Future for Mac games in M1 era

diamond.g said:
Is it really that easy to develope a game/game engine that uses Metal and DX12 at the same time?
Click to expand...
I don't think any game development is easy. I suppose its how different is Metal compared to DX12 and do they have experienced developers capable of writing the code? I've said this before given the marketshare, I think studios will be hard pressed to spend a lot of money on producing a Mac version when their return on investment is going to be so low.
 
maflynn said:
I don't think any game development is easy. I suppose its how different is Metal compared to DX12 and do they have experienced developers capable of writing the code? I've said this before given the marketshare, I think studios will be hard pressed to spend a lot of money on producing a Mac version when their return on investment is going to be so low.
Click to expand...
It’s not easy for AAA, but if the underlying frameworks support Macs then it’s not a big deal to port a game. People tend to forget that most games aren’t made with their own bespoke engine anymore. If a game is made in an engine that supports Metal, then the bar for a port is significantly lower.

As for the economics of porting games, a lot of ports are farmed out to studios like Feral and Aspyr who specialize in Mac ports, and it’s done after the initial window of time when a game gets the majority of sales. So porting games actually increases ROI in many cases.

This os the current state of gaming on Mac, and I don’t see it changing.
 
diamond.g said:
Yeah I saw that yesterday. I hope Apple does support it as it is a free way to scale ATV games to 4k from 1080p and keep performance up. We will see how it does on IQ on the 22nd.
Click to expand...

Been doing some more reading on it, seems that AMDs solution is not an ML technique and so it’s probably not that different from one of the upscalers that Apple offers as part of Metal performance shaders.
 
leman said:
Been doing some more reading on it, seems that AMDs solution is not an ML technique and so it’s probably not that different from one of the upscalers that Apple offers as part of Metal performance shaders.
Click to expand...
Yeah, we will see on the 22nd. In the meantime I am curious if Apple is going to talk about it (upscaling or RT HW RT) at all tomorrow. Still seems odd that Apple would add support for the 6000 series GPU’s in 11.4 and then turn around and not use any of the features that the hardware supports.
 
diamond.g said:
Yeah, we will see on the 22nd. In the meantime I am curious if Apple is going to talk about it (upscaling or RT HW RT) at all tomorrow. Still seems odd that Apple would add support for the 6000 series GPU’s in 11.4 and then turn around and not use any of the features that the hardware supports.
Click to expand...

Adding basic support for Navi 2 was probably just a matter of entering some new device ids and maybe tweaking a register or two here and there. Adding RT support to the shader compiler is an entirely different t matter though…
 
leman said:
Adding basic support for Navi 2 was probably just a matter of entering some new device ids and maybe tweaking a register or two here and there. Adding RT support to the shader compiler is an entirely different t matter though…
Click to expand...
I know RDNA2 is backwards compatible with older AMD shader code, but that seems like a giant waste of time for everyone involved. Though to be fair RDNA1 supported primitive (mesh-sorta) shaders and Apple didn’t support them then either.
It was like Apple picked them for compute performance, when Vega performs better (in that capacity) And ignored the rasterization improvements RDNA1 brought to the table.
 
@leman , did you get the chance to watch state of the union ? were you impressed by anything GPU related there ? it seems like they are trying to do more in that space.
 
NotTooLate said:
@leman , did you get the chance to watch state of the union ? were you impressed by anything GPU related there ? it seems like they are trying to do more in that space.
Click to expand...

I have the impression that this year they are focussing on quality of life improvements (better debugging etc.), which I think is a good strategy. They already have a great API, now they need to convince people to use it. Documentation also seems to be improving (although the Metal shading language reference still has no hyperlinks 🙄).

The emphasis on raytracing is quite curious though. Appel seems to invest a lot in this area. They are bringing inline ray tracing to Metal, which would give it feature party with DX12 Ultimate in this area. And it's available on all Apple devices! I think this an indication that RT is going to be fast on the upcoming hardware.
 
  • Like
Reactions: ErikGrim
leman said:
I have the impression that this year they are focussing on quality of life improvements (better debugging etc.), which I think is a good strategy. They already have a great API, now they need to convince people to use it. Documentation also seems to be improving (although the Metal shading language reference still has no hyperlinks 🙄).

The emphasis on raytracing is quite curious though. Appel seems to invest a lot in this area. They are bringing inline ray tracing to Metal, which would give it feature party with DX12 Ultimate in this area. And it's available on all Apple devices! I think this an indication that RT is going to be fast on the upcoming hardware.
Click to expand...
Nice , you should catch the GPU related portion of state of the union , it looked very interesting , its on the Apple website already , starting at 45:10
https://developer.apple.com/videos/play/wwdc2021/102/
 
NotTooLate said:
Nice , you should catch the GPU related portion of state of the union , it looked very interesting , its on the Apple website already , starting at 45:10
https://developer.apple.com/videos/play/wwdc2021/102/
Click to expand...

Yeah, I watched it, the only "new" thing seems to be inline raytracing support (plus the motion blur). The rest is quality of life stuff.

I think this is also indicative of the overall theme of this year's updates. Few surface changes but a lot of under the hood improvements that simply make everything more useful and more convenient. Better automation, better APIs, more extension points (we finally have an official extension API for Apple Mail!), better tools — that's the theme of this year. I hope that this is a sign that Apple is stepping up their game.
 
  • Like
Reactions: NotTooLate
leman said:
I have the impression that this year they are focussing on quality of life improvements (better debugging etc.), which I think is a good strategy. They already have a great API, now they need to convince people to use it. Documentation also seems to be improving (although the Metal shading language reference still has no hyperlinks 🙄).

The emphasis on raytracing is quite curious though. Appel seems to invest a lot in this area. They are bringing inline ray tracing to Metal, which would give it feature party with DX12 Ultimate in this area. And it's available on all Apple devices! I think this an indication that RT is going to be fast on the upcoming hardware.
Click to expand...
Are you able to tell if the BVH is opaque like DXR yet? That seems to be a gripe about DXR that the BVH build is black box (at least on PC, I think on XSX/XSS you can manually build it).
 
diamond.g said:
Are you able to tell if the BVH is opaque like DXR yet? That seems to be a gripe about DXR that the BVH build is black box (at least on PC, I think on XSX/XSS you can manually build it).
Click to expand...

As far as I can tell, it’s opaque, yes. Abstracting such details away allow the API to pick best implementation on each hardware while keeping the design “future proof”. Do you happen away what kind of complains people gave with opaque acceleration structures?
 
leman said:
As far as I can tell, it’s opaque, yes. Abstracting such details away allow the API to pick best implementation on each hardware while keeping the design “future proof”. Do you happen away what kind of complains people gave with opaque acceleration structures?
Click to expand...
b3d being b3d again i suppose. It looks like there was some lingering wonder if the BVH that DXR builds is the best one for the hardware to step through. (or the flexibility of it at all I guess)

Really it leads me to wonder if Apple will go the AMD route (TMU that can accelerate BVH traversal when not TMU-ing) ensuring adaquate utilization of hardware instead of dedicating FF units to it (like nvidia and presumably Intel).
 
diamond.g said:
b3d being b3d again i suppose. It looks like there was some lingering wonder if the BVH that DXR builds is the best one for the hardware to step through. (or the flexibility of it at all I guess)
Click to expand...

That’s a tricky topic. I can imagine situations where your app could generate a more optimal graph by taking advantage of how your geometry gets updated. It’s difficult to find balance.

diamond.g said:
Really it leads me to wonder if Apple will go the AMD route (TMU that can accelerate BVH traversal when not TMU-ing) ensuring adaquate utilization of hardware instead of dedicating FF units to it (like nvidia and presumably Intel).
Click to expand...

I still don’t really understand what Nvidias RT cores do exactly or why do they need them in the first place. I read a paper where the authors tried to reverse-engineer some of its behavior and their conclusion was that the main job of the RT cores is some sort of memory access coalescing.
 
leman said:
I still don’t really understand what Nvidias RT cores do exactly or why do they need them in the first place. I read a paper where the authors tried to reverse-engineer some of its behavior and their conclusion was that the main job of the RT cores is some sort of memory access coalescing.
Click to expand...
I can answer that, they double the price.
 
  • Haha
Reactions: diamond.g
leman said:
That’s a tricky topic. I can imagine situations where your app could generate a more optimal graph by taking advantage of how your geometry gets updated. It’s difficult to find balance.



I still don’t really understand what Nvidias RT cores do exactly or why do they need them in the first place. I read a paper where the authors tried to reverse-engineer some of its behavior and their conclusion was that the main job of the RT cores is some sort of memory access coalescing.
Click to expand...
It is literally an ASIC designed to accelerate Ray intersection testing. Returning the results to the calling shader. It is like Apples HEVC encoder in a way. Dedicated hardware that does it fast versus using general compute (doing it in software).
 
diamond.g said:
It is literally an ASIC designed to accelerate Ray intersection testing. Returning the results to the calling shader. It is like Apples HEVC encoder in a way. Dedicated hardware that does it fast versus using general compute (doing it in software).
Click to expand...

Do you know that for sure or are you guessing? Again, there is academic research out there trying to analyze Nvidia’s RT cores and their conclusion that the main function of that hardware is ray coalescing. This makes a lot of sense to me since intersection computation itself is cheap. Memory access and SIMD patterns, that’s the real problem with ray tracing. Rays tend to get scattered in different directions and break locality. That last part is the absolute performance killer. Box-ray intersections instead? GPUs eat that for breakfast.
 
maybe it’s using path tracing? I don’t know much in depth about ray tracing, but I recall seeing a video that points out the benefits of path tracing instead.
 
JMacHack said:
maybe it’s using path tracing? I don’t know much in depth about ray tracing, but I recall seeing a video that points out the benefits of path tracing instead.
Click to expand...

The core RT API just gives you basic ray tracing capabilities. You can cast rays, find intersections and execute code for those intersections. What you do with those capabilities is up to you. You can do stochastic ray tracing (aka. path tracing), you can do ray sampling, whatever you want.
 
iHorseHead said:
Macs can't even run the most popular games out there.
Click to expand...

Steam Charts - Tracking What's Played

An ongoing analysis of Steam's player numbers, seeing what's been played the most.
steamcharts.com steamcharts.com

Running down the list:
1. CS:GO, Mac Support
2. DOTA 2, Mac Support
3. Apex Legends, No Support
4. TF2, Mac Support
5. Ark: Survival Evolved, Mac Support
6. PUBG, No support
7. Rust, Mac Support
8. Destiny 2, No support
9. GTA 5, no support
10. Rocket League, had support before Epic bought Psyonix.
11. Football Manager 2021, Mac Support
12. Rainbow Six Siege, No support

Looks half and half to me.
 
  • Like
Reactions: ErikGrim
JMacHack said:

Steam Charts - Tracking What's Played

An ongoing analysis of Steam's player numbers, seeing what's been played the most.
steamcharts.com steamcharts.com

Running down the list:
1. CS:GO, Mac Support
2. DOTA 2, Mac Support
3. Apex Legends, No Support
4. TF2, Mac Support
5. Ark: Survival Evolved, Mac Support
6. PUBG, No support
7. Rust, Mac Support
8. Destiny 2, No support
9. GTA 5, no support
10. Rocket League, had support before Epic bought Psyonix.
11. Football Manager 2021, Mac Support
12. Rainbow Six Siege, No support

Looks half and half to me.
Click to expand...
See? No GTA IV and many other games and even if there is it sucks. Look at Tropico 6 etc…
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back