Console developers need to use the APIs that are laid out by the system's creator. Nintendo has their own graphics API for the last three generations, called GX, although it is rumored to be somewhat like OpenGL. A few days ago, Nintendo's logo appeared on the Khronos Group's website as a Contributor Member. This leads sites like The Register to speculate that Nintendo “pledges allegiance to the Vulkan (API)”.
I wouldn't be so hasty.
There are many reasons why a company would want to become a member of the Khronos Group. Microsoft, for instance, decided that the small, $15,000 USD/year membership fee was worth it to influence the future of WebGL. Nintendo, at least currently, does not make their own web browser, they license NetFront from Access Co. Ltd., but that could change (just like their original choice of Opera Mini did). Even with a licensed browser, they might want to discuss and vote on the specifics. But yes, WebGL is unlikely to be on their minds, let alone a driving reason, especially since they are not involved with the W3C. Another unlikely option is OpenCL, especially if they get into cloud services, but I can't see them caring enough about the API to do anything more than blindly use it.
Vulkan is, in fact, most likely what Nintendo is interested in, but that also doesn't mean that they will support it. The membership fee is quite low for a company like Nintendo, and, even if they don't use the API, their input could benefit them, especially since they rely upon third parties for graphics processors. Pushing for additions to Vulkan could force GPU vendors to adopt it, so it will be available for their own APIs, and so forth. There might even be some learning, up to the limits of the Khronos Group's confidentiality requirements.
Or, of course, Nintendo could adopt the Vulkan API to some extent. We'll see. Either way, the gaming company is beginning to open up with industry bodies. This could be positive.
If they use an AMD APU, then
If they use an AMD APU, then it obviously makes sense to use Vulkan. Given the current situation, it seems like a bad idea to try to push their own API. Microsoft has DX12, but it seems to be very similar to Vulkan, so making an engine that will work on an XBox and on Vulkan might not be too difficult. Apple is big enough that they can force developers to use their own proprietary API, at least for mobile. I have no idea if Metal is similar to Vulkan though.
They’ve used an AMD / ATI GPU
They’ve used an AMD / ATI GPU in the last three generations of their console hardware. It’s looking like that will not change in the next generation. Whether or not they use an APU similar to the Jaguar used by Sony and Microsoft remains to be seen (but is rumored to be true.)
Metal is not similar to
Metal is not similar to Vulkan. It's a highly efficient API, but it still uses the "binding" model (instead of the command queue model of DX 12, Vulkan, Mantle, and even OpenCL).
Nintendo been in strong
Nintendo been in strong friendship with ATi and AMD for many years. Super Famicom and Gamecube both had ATi video in them (I don’t remember about N64, but I think it had ATi’s video too), while WiiU uses AMD’s CPU just like other two modern consoles out there.
It most certainly does not.
It most certainly does not. The Wii U uses the so called ‘Espresso’ CPU as its main processor, which is based on IBM’s Power architecture (the same one used in the Wii and the Xbox 360). This is what makes it so easy for the Wii U to run original Wii software, it just boots its processor as a Wii-processor. Like al recent Nintendo-consoles, it does use an AMD/ATi GPU.
The Nintendo NX is rumored to use the same AMD APU-design as the XBone and the PS4 though.
Nintendo better wait and
Nintendo better wait and future proof their gaming platform with an AMD APU on an interposer, because the interposer will be a game changer once those APUs on an interposer systems start arriving. Nintendo better wait for Zen, and Arctic Islands with the possibility of AMD adding a FPGA to the HBM’s die stack/s for even more specialized distributed compute. AMD’s APU on an interposer for console gaming, as well as PC gaming will be hard to best, as the interposer will allow for a separate CPU die to be wired up/connected to a separate GPU die with Thousands of wide parallel traces to wire up the CPU to the GPU as if they where on the same monolithic die.
These APU’s on an Interposer will have that HBM memory and maybe even some FPGA programmable logic Die/s added to the individual HBM die stack/s with the FPGA sandwiched between the HBM’s bottom memory controller die and the HBM dies stacked above, with the FPGA able to work directly from the above HBM memory dies and do processing/post processing work in addition to the CPU and GPU on the interposer package. A gaming console system like this with some FPGA ability added will be future proofed for any new features added to the Vulkan/other Graphics APIs as the FPGA could be reprogrammed for any newer graphics API improvements and allow for more features to be added.
That is a bit much for a
That is a bit much for a console device. Also, they would probably be waiting a long time if they wanted to use even Zen, not to mention all of the other tech in the pipeline. Nintendo does not have a history of using bleeding edge tech in their consoles. Sony attempted to do so withe the PS3 using the Cell processor, and it did not work out that well really; it was powerful, but difficult to program for. For the PS4, Sony went for more commodity hardware, very similar to a low power PC rather than risking going with bleeding edge technology. I suspect we will just get a relatively standard APU. It would be great if it is on a smaller process then the ancient 28 nm node. It would be great if it is on a silicon interposer. I suspect that there is a good chance it will just be an APU with GDDR5, like the PS4. This seems to be the most economical solution right now. If the APU is on a smaller process, then it could outperform the older consoles easily, even without using HBM on a silicon interposer.
APUs on an interposer are not
APUs on an interposer are not that much different than a standard APU except the interposer will allow for HBM, and a larger GPU, or more smaller GPUs. A custom console order for the Zen based part could probably come online in the same time frame as the first server Zen based APUs on an interposer. The interposer based APUs are not going to be any different to program than an APU on a single monolithic die.
Nintendo could order the Zen/GPU/HBM part and have plenty of upgrade options designed into the interposer substrate like making the GPU portion of the interposer based APU out of smaller individual GPU dies and pre-engineering of various interposer bases to accept more/smaller GPU dies allowing for GPU horse power to be added in a modular fashion at a later time for when an GPU upgrade was needed, the same for CPU dies. The amount of Power and space saved when using HBM on an interposer will justify its extra expense, and with Nvidia’s use of HBM expect that the HBM pricing will come down more quickly as HBM supplies become more plentiful.
AMD has an advantage with its custom console business as it can spread the R&D funding for the parts across multiple users, so AMD could begin by offering Nintendo, as well as the other console makers some custom APU on an interposer base configurations with the customer able to order various APUs on an interposer configurations at various power/performance levels at various price points. The console makers could add as much or as little modular GPU/CPU/FPGA power, and HBM memory as they wanted to differentiate their products, and most console makers use exclusive games/ecosystems even more so than different hardware to differentiate their respective offerings.
This could carry over to the PC/Laptop market with various interposer designs built to accommodate increasingly more powerful interposer based APUs.
I don’t think I implied that
I don’t think I implied that there would be any difference in programming. Using HBM would be the same as using GDDR5 from a programming perspective, just faster and lower power. Many of the features you describe are going to be for AMD’s very high-end HPC part. It will probably be quite some time before these features make it down to a console part. I would think there is a very, very low chance of the console containing FPGAs.
I am not saying it is impossible for Nintendo to use an APU on an interposer in their next console, but I would say it is wild speculation at this point. If it is an APU on a newer process (16 or 14 nm), then it could have significant performance and power advantages even without using HBM. We don’t really know any solid information yet. It may even be possible to use stacked memory without using a silicon interposer. The stacked memory could be placed in a separate package with a different bottom logic die to convert the wide interface into a narrower interface suitable for communication through a PCB. This would allow some of the power savings of HBM while avoiding the risk associated with using new technology like a silicon interposer. Intel is working on some similar tech to compete with silicon interposers. It is called EMIB (embedded multi-die interconnect bridge). This places small chips upside down, embedded into the package, that provide higher levels of interconnectivity than going via the PCB. I don’t think this provides the same levels of interconnect as a silicon interposer, but it is mostly based on existing technology.
The silicon interposer technology is not that mature yet. AMD is not even using it throughout their product line. It is limited to their high-end, low-volume parts. Even though they are using it only for their low-volume parts, these parts seem to be in short supply. This could be due to limited GPU yeild, since it is a very large die, but it is on a mature process, so it is unclear what the limiting factor is. As far as being able to upgrade the part, this is not a concern for a console. The whole idea behind a console is that they keep the hardware the same to allow a stable configuration (stable software target). Upgrading the hardware in any significant way means releasing a new console. Making a small die modular gpu would be interesting for the HPC and desktop market, but that is a different discussion.
Yes and not just for
Yes and not just for HPC/workstations AMD could create a standard set of interposers and base all of its system on the interposers, and have the ability to fab smaller GPU modular dies and add the GPU dies to match the customers’ needs. And what is so hard about etching traces in silicon, that is what interposer is made of, 10 of thousands of traces can be etched in an interposer’s substrate enough to directly and wire for wire a connect a separate CPU die to a GPU die or other types of dies/die stacks like HBM.
AMD could very well design some Interposers that are made to host lower powered APUs on an interposer all the way up to larger HPC/workstation interposers able to host large numbers of separate CPU/GPU dies as well as HBM. And do you think the AMD console makers would not want AMD to spread the R&D cost of its custom gaming APUs on an interposer and be able to offer all of AMD’s console customers a better product at a better price point.
The Console makers are already using AMD gaming APUs so if AMD switches to making the gaming APUs on an interposer then AMD could make various modular interposer designs and install various CPU and GPU modular configurations to the customers’ specifications, and the tape-out of the GPU modular units does not have to change or the fabrication process, the customer could order a new part with more modular GPU dies and save on having to do any new tape-outs or die redesigns, same goes for adding more CPU cores to a future version of a customer’s console gaming APU, just add more CPU dies for more power, no need to re-tape out a design with more cores just order a larger interposer next generation with more modular resources. An entire line of AMD custom gaming APU’s on an interposer could be created with each interposer made larger to host more modular components, and AMD could also offer these APUs on various interposer designs from small to large for the PC/Laptop market and could create an entire line of APU products based off of modular CPU(4 cores per die) and modular smaller GPU units(8/16 ACE units per GPU module), along with HBM stacks, stacks that could also host FPGA’s in addition to the memory logic die, and HBM dies. Most console maker’s AMD based APUs are relatively similar to start with, and the console makers will mostly use exclusive games, and games ecosystems to differentiate their products.
Interposers are nothing more than smaller in silicon based versions of a PCB equivalent with the traces able to be made much closer together by the thousands wide of parallel interposer traces, to host whatever chips are attached with the micro-bumps, and PCBs could never host the numbers of traces that an interposer could host. It’s not hard to see that an all interposer based product line made of smaller and easier to manufacture modular CPU/GPU/FPGA/Other units could make for great savings for AMD, and much better yields with defects not making a larger monolothic die useless for what it was designed for.
Silicon Interposers are not new technology, and they are just silicon with metal traces etched in them, how hard could that be for anyone! and most silicon interposers do not use latest process node, an older larger process node is still capable of producing traces in the 10s of thousands enough to wire up directly CPU to GPU, and HBM. Interposers could even be made to host some logic for complex connection fabrics, it depends on the design usage.
That was a typo. I’ve meant
That was a typo. I’ve meant to say “AMD’s GPU” no “CPU”.
Would be good sign for indie
Would be good sign for indie devs. Nintendo used their own GX(2)API for the last gens and effectively shut them out without them having intimate knowledge of the framework, they only opened somewhat in the last few years.
Interesting to see whether Sony adds Vulkan too, though their API should be even more C2M.
Nintendo is a dinosaur. They
Nintendo is a dinosaur. They either need to get with the times or die out. Traditional consoles are dying as a whole, they won’t last past another 2 generations with broadband taking off and the move towards streaming gaming services. If Nintendo wishes to stay relevant, they should start developing Android based consoles that utilize Vulkan as the API. Konami made the right move by ditching console development and going to mobile, that’s where the numbers and money are.
If Nintendo does not adapt,
If Nintendo does not adapt, their market share will continue in its steady decline. Probably the best thing they could do is make/remake their game library to play on the current MS/Sony consoles. Those idiots are sitting on a veritable gold mine of IP that so many people have missed out on as a result of their myopic view of the gaming world…
Nintendo is a hardware
Nintendo is a hardware company that makes games and creates this “valuable IP” as a way to showcase their vision of how to create games and apps for *their platforms* and also to make their platforms successful.
They know they have to adapt. That’s why they have already implemented a mobile strategy and are partnering with DeNA to make the mobile vision a reality (from the infrastructure side of the fence.) Nintendo is / will be developing mobile games on the DeNA platform.
Giving up and pushing their IP onto Sony and Microsoft hardware is not as easy as it sounds. They have limited developer resources, and those resources already have a full slate of games they are working on. Nintendo is a company that takes a lot of pride in the products they ship. They do not release games early with a metric ton of bugs. If they aren’t finished with a game, they are prepared to leave money on the table and ship the game late. They do this all the time.
They’re not in the situation SEGA was in 15 years ago, not by a long shot. They have plenty of cash in the bank.
Building a system on top of Android is not something they’d do without a lot of consideration.
Nintendo has talented developers on staff. If anything, they might license code from various entities and leverage the DeNA parternship to build out the server side of the equation, but Android is a huge can of worms which I believe they are not going to open on their next platform.
They (most likely) will have something that resembles the Microsoft / Sony platform of today with the 3DS / Vita mobile platform. That is, AMD on the console (home base) and ARM on mobile. Nintendo is not new to ARM chips – they’ve been using them for years and years. This means Android isn’t “needed” to run their games on mobile.
But, as stated, they do have a mobile strategy, and that will undoubtedly include a limited selection on the Android and iOS platforms.
Protecting their core IP is of utmost importance to them. Android would, from a 50,000 foot point of view, be counter to that requirement.
Everyone keeps seeing they’re
Everyone keeps seeing they’re going to do this hybrid console, but I see that as being far too expensive to make. They’d essentially be selling something of the level of an XBO that is also a smartphone.
Maybe they do, and it’s just really expensive to own the whole thing. Nintendo is good at selling that type of hardware.
One rumor is the “home base”
One rumor is the “home base” will be about $150 (up to $199 depending on SKU.) The mobile station will be in line with New 3DS XL to Sony Vita pricing.
Are they rumored to be doing
Are they rumored to be doing something like Nvidia shield portable and shield TV box which supposedly allow streaming games from a PC? Streaming games from a console to a portable makes some sense, I guess.
Dun-dun-DUUUUUNNN!!!11
It’s
Dun-dun-DUUUUUNNN!!!11
It’s over. Now we can pretty safely say that DirectX12 fad is finished. The future is for Mantle’s true successor – Vulkan OGL. There is no place for such proprietary anal garbage as DX12 in our modern day and age. Windows 10 turned out to be a hole-ridden spying rootkit of an “OS”, it’s only true “benefit” was the proprietary anal support of DX12. Now it’s done for, since Vulkan OGL supports pretty much everything and is a completely open platform. There is literally no reason to go that Windows garbage now, since Vulkan will have full support of Windows 7 just fine, while having all of the functionality (AND MORE) the proprietary anal garbage DX12 “provides”.