I was wondering if someone here can explain in a few quick words. I noticed the PS3, PS4 and Switch are based on FreeBSD but have very different graphics APIs. The PS4 has their custom Gnm and Gnmx API while the Switch has a Vulkan based API. Also Vulkan isn't fully supported in FreeBSd. So a few things bug me:

1.Does that mean that Nintendo has to do a custom implementation of Vulkan just to have the thing to render a single triangle?

2. How does the PS4 handle game engines such as Unity if it has a custom API?

3.Do they develop the software for specific hardware? And if so how do they transfer it to the newest if the development lasts let's say 5 years? Wouldn't the hardware on which they started development be obsolete after 5 years?

4. Why not work on a linux based system? Most of the APIs are handled log ago. Performance? Is the boost even worth the thousands of hrs of extra development?

PS Not looking to make my own OS, just curious

I work at a AAA studio that makes games for PlayStation, so I'll leave a couple of my thoughts.

1. I don't develop for Switch, but I can imagine a couple reasons why Nintendo would use the Vulkan API. For one, Vulkan is becoming more widely-used and supported in the industry, so it's likely easier on developers to program against a known API rather than a closed, platform-specific one. Furthermore, I believe the Switch uses custom Nvidia silicon for its GPU - it's possible Nintendo worked with Nvidia to co-develop the underlying Vulkan implementation since Nvidia already has Vulkan drivers for other platforms.
2. Big game engines handle custom console API's like they do any other API: they have their own abstraction above the platform-specific graphics layer. It's the same concept as abstracting away DX12, Vulkan, or Metal.
3. Yes - generally the kernel or platform API's for a console are re-written (or at least extended) for each new console generation. One of the main selling-points of a console is direct access to a fixed set of hardware specs, so the OS-level APIs are going to give direct access to that hardware so developers can use it to its full extent. Developing for a console that isn't released yet is certainly tricky - for some time before the console is available there are usually development kits available. For more extreme cases the console manufacturer may provide hardware or hardware specifications of a “PC equivalent” that exhibits similar performance characteristics to the target console, but of course that means the developer needs to effectively port their engine to PC if they haven't already.
4. I don't have a great answer for this one. Probably for performance and practical reasons? The “OS” that runs on a console is generally very different from a generic implementation of a Linux-based OS and has very specific memory/performance/hardware interface requirements - why bother implementing generic Linux API's that can only express a subset of the particular hardware the OS is running on?

Just to add to question 1.
There is no such thing as default Vulkan implementation, the specification is the standard that drives the implementation. Implementation is hardware specific which implies that every Vulkan implementation for different hardware family is ‘custom’ .i.e tailored to the hardware on which its running.

Linux comes with a GPL license which manufacturers may not like.

Also, a full OS may be overkill, you can have something as simple as DOS where the application has full control over everything.

@Valakor Thanks a lot for the in depth answer. I figured most of the stuff is like you said it is but it's really hard to find anything online that covers stuff like this.

@cgrant Oh I know there isn't one. When I said custom I meant that they had to make one themselves from scratch and couldn't just use an existing one.

Thanks everyone. Appreciate the info. Really didn't know where else to ask these questions since there is very little documentation about specific stuff like this. This gives me a nice basis to keep looking.

Cheers