RPCS3 and Dolphin on macOS using gfx-portability • Hacker News Board

Re: RPCS3 and Dolphin on macOS using gfx-portability

#11

Post by pjmlp » Tue, Sep 04, 2018, 2:43 PM UTC

skohan wrote: post #7

hd4 wrote: post #6

Earlier quoted context omitted.

Yes but there's nothing surprising about the Walled Garden Company promoting their own snowflake version of Vulkan and insisting everyone who wants to run software must do things their way. This is the same company who has totally locked down the tooling to create and publish iOS apps to only be possible on their hardware.

To be fair, Metal is more than a "snowflake version of Vulkan". For one thing, it was in production before vulkan, largely to address the issue of OpenGL's overhead on mobile devices, and basically it achieves that goal. Also there are certain things which are exposed in Metal which are not in Vulkan, for instance more control over the tile memory which mobile GPUs use. So it's not as if there is no reason for Metal…

Some devs are so obsessed complaining about Metal that most aren't aware that UWP and Windows Store are DirectX only.

An advantage of all proprietary 3D APIs is the amount of out-of-box infrastructure code, debugging tools and having progressed beyond C, while Khronos APIs are still mostly C, and requiring creating mini-engine from scratch after fishing for libs.

Re: RPCS3 and Dolphin on macOS using gfx-portability

#12

Post by pjmlp » Tue, Sep 04, 2018, 2:45 PM UTC

zamadatix wrote: post #10

pjmlp wrote: post #9

Earlier quoted context omitted.

Swift and Objective-C API with C++14 shaders vs plain old C API and manually compilation of shaders? Obvious choice, plus all engines that matter already support Metal. Same situation on PS4, XBox and UWP.

There is nothing wrong with saying something new could be better but is Metal actually so much better than Vulkan to be the only supported API?

The fact that Vulkan is a C API and requires searching for extensions even for a plain 3D Hello World, makes Metal a better option on the Mac.

Re: RPCS3 and Dolphin on macOS using gfx-portability

#13

Post by ReverseCold » Tue, Sep 04, 2018, 2:47 PM UTC

hd4 wrote: post #6

skohan wrote: post #5

Earlier quoted context omitted.

It is. Also not supporting Vulkan natively is a mistake.

Yes but there's nothing surprising about the Walled Garden Company promoting their own snowflake version of Vulkan and insisting everyone who wants to run software must do things their way. This is the same company who has totally locked down the tooling to create and publish iOS apps to only be possible on their hardware.

And not only do you need a Mac to write iOS apps, you need to pay them $100/yr to run the apps on anything other than your own devices.

And even on your own devices, you need to reinstall every few (days? weeks?) because the certificate expired.

Re: RPCS3 and Dolphin on macOS using gfx-portability

#14

Post by mikhailt » Tue, Sep 04, 2018, 2:50 PM UTC

skohan wrote: post #7

hd4 wrote: post #6

Earlier quoted context omitted.

Yes but there's nothing surprising about the Walled Garden Company promoting their own snowflake version of Vulkan and insisting everyone who wants to run software must do things their way. This is the same company who has totally locked down the tooling to create and publish iOS apps to only be possible on their hardware.

To be fair, Metal is more than a "snowflake version of Vulkan". For one thing, it was in production before vulkan, largely to address the issue of OpenGL's overhead on mobile devices, and basically it achieves that goal. Also there are certain things which are exposed in Metal which are not in Vulkan, for instance more control over the tile memory which mobile GPUs use. So it's not as if there is no reason for Metal…

> With regard to applications in which graphics API's are relevant (i.e. games) Apple still has a minuscule market-share, and it seems like they would be well served by adopting the dominant technology. Lock-in only works if you're already winning.

Except Metal is the dominant API on almost all Apple platforms. Metal supported-iOS devices are at 700 million (last year's WWDC stat) and majority of games are using Metal on iOS. You can't ignore that market, iOS games are very profitable.

Fortnite made $3M in sales in the first three days on iOS: https://www.tweaktown.com/news/61266/fortnite-mobile-makes-1...

Re: RPCS3 and Dolphin on macOS using gfx-portability

#15

Post by skohan » Tue, Sep 04, 2018, 2:54 PM UTC

pjmlp wrote: post #12

zamadatix wrote: post #10

Earlier quoted context omitted.

There is nothing wrong with saying something new could be better but is Metal actually so much better than Vulkan to be the only supported API?

The fact that Vulkan is a C API and requires searching for extensions even for a plain 3D Hello World, makes Metal a better option on the Mac.

Erm, not really. I have implemented a reasonably serious PBR renderer in Vulkan on Mac on top of MoltenVK, and the C API is not at all an obstacle. Swift/C interop is fairly straightforward, and Objective C is a superset of C so that is a total non-issue.

The ability to easily integrate the wealth of C libraries directly into your high-level code (as opposed to, say, the verbosity of implementing a JNI) is one of the strengths of Swift.

Re: RPCS3 and Dolphin on macOS using gfx-portability

#16

Post by Volt » Tue, Sep 04, 2018, 2:54 PM UTC

skohan wrote: post #7

hd4 wrote: post #6

Earlier quoted context omitted.

Yes but there's nothing surprising about the Walled Garden Company promoting their own snowflake version of Vulkan and insisting everyone who wants to run software must do things their way. This is the same company who has totally locked down the tooling to create and publish iOS apps to only be possible on their hardware.

To be fair, Metal is more than a "snowflake version of Vulkan". For one thing, it was in production before vulkan, largely to address the issue of OpenGL's overhead on mobile devices, and basically it achieves that goal. Also there are certain things which are exposed in Metal which are not in Vulkan, for instance more control over the tile memory which mobile GPUs use. So it's not as if there is no reason for Metal…

Well as you say, Metal is really for iOS. And I think the evidence points to Apple caring much more about iOS than the Mac. So it makes sense from that perspective.

Re: RPCS3 and Dolphin on macOS using gfx-portability

#17

Post by mikhailt » Tue, Sep 04, 2018, 3:03 PM UTC

What's funny and sad is that Vulkan may be the one in the long run that helps make macOS (and Linux) relevant longer for games.

Imagine if Apple did support Vulkan natively, all Windows games via Steam Play Beta can be run on macOS easily and with support of eGPU, it would help a lot to make them run better.

All I can realistically hope for is that Apple continues to close the gap between Metal and Vulkan, so projects like Metal on Vulkan (MoltanVK), Proton (Steam Play + dxvk + Wine) can benefit with less work to do.

It'll be interesting to see what Apple does with Metal 3 in the next few years. If they're smart (they haven't been in the last few years with Mac Pro, rMBP keyboard+touchbar, etc), they'd work with the Kronos group.

Re: RPCS3 and Dolphin on macOS using gfx-portability

#18

Post by skohan » Tue, Sep 04, 2018, 3:06 PM UTC

pjmlp wrote: post #11

skohan wrote: post #7

Earlier quoted context omitted.

To be fair, Metal is more than a "snowflake version of Vulkan". For one thing, it was in production before vulkan, largely to address the issue of OpenGL's overhead on mobile devices, and basically it achieves that goal. Also there are certain things which are exposed in Metal which are not in Vulkan, for instance more control over the tile memory which mobile GPUs use. So it's not as if there is no reason for Metal…

Some devs are so obsessed complaining about Metal that most aren't aware that UWP and Windows Store are DirectX only. An advantage of all proprietary 3D APIs is the amount of out-of-box infrastructure code, debugging tools and having progressed beyond C, while Khronos APIs are still mostly C, and requiring creating mini-engine from scratch after fishing for libs.

> having progressed beyond C

I don't really see the issue with C APIs. IMO C is a fantastic integration point for a library which wants to have the widest reach possible. Interoperability with C is a solved problem in a wide variety of languages, so C APIs tend to be easy to integrate. Also since C is a fairly thin abstraction on top of what a computer actually does, good C APIs tend not to be opinionated about how they should be integrated.

I would consider working with C APIs to be a basic programming skill.

Re: RPCS3 and Dolphin on macOS using gfx-portability

#19

Post by skohan » Tue, Sep 04, 2018, 3:13 PM UTC

pjmlp wrote: post #9

AdrianRossouw wrote: post #4

i still think osx killing opengl support is ridiculous.

Swift and Objective-C API with C++14 shaders vs plain old C API and manually compilation of shaders? Obvious choice, plus all engines that matter already support Metal. Same situation on PS4, XBox and UWP.

> C++14 shaders

What's a C++14 shader? Metal uses MSL last time I checked...

> manually compilation of shaders

The toolchain for this in Vulkan is pretty solid. It's actually nice to be able to write shaders in a high-level language, and then compile them down to SPIR-V which is more likely to be interpreted consistently across drivers than a high-level language.

Re: RPCS3 and Dolphin on macOS using gfx-portability

#20

Post by kvark » Tue, Sep 04, 2018, 3:26 PM UTC

mikhailt wrote: post #17

What's funny and sad is that Vulkan may be the one in the long run that helps make macOS (and Linux) relevant longer for games. Imagine if Apple did support Vulkan natively, all Windows games via Steam Play Beta can be run on macOS easily and with support of eGPU, it would help a lot to make them run better. All I can realistically hope for is that Apple continues to close the gap between Metal and Vulkan, so project…

> projects like Metal on Vulkan (MoltanVK)

It's not Metal on Vulkan, it's the other way around. Also, kind of strange to bring this up when the topic is about gfx-portability progress (which is competing with MoltenVK).