The Khronos Group announced on Friday that the Vulkan API will not ship until next year. The standards body was expecting to launch it at some point in 2015. In fact, when I was first briefed on it, they specifically said that 2015 was an “under-promise and over-deliver” estimate. Vulkan is an open graphics and compute standard that was derived from AMD's Mantle. It, like OpenCL 2.1, uses the SPIR-V language for compute and shading though, which can be compiled from subsets of a variety of languages.
I know that most people will be quick to blame The Khronos Group for this, because industry bodies moving slowly is a stereotype, but I don't think it applies. When AMD created Mantle, it bore some significant delays at all levels. Its drivers and software were held back, and the public release of its SDK was delayed out of existence. Again, it would be easy to blame AMD for this, but hold on. We now get to Microsoft. DirectX 12, which is maybe even closer to Mantle than Vulkan is due to its shading language, didn't roll out as aggressively as Microsoft expected, either. Software is still pretty much non-existent when they claimed, at GDC 2014, that about 50% of PC games would be DX12-compatible by Holiday 2015. We currently have… … zero (excluding pre-release).
Say what you like about the three examples individually, but when all three show problems, then there might just be a few issues that took longer than expected to solve. Again, this is a completely different metaphor of translating voltages coming through a PCI Express bus into fancy graphics and GPU compute, and create all of the supporting ecosystems, too.
Speaking of ecosystems, The Khronos Group has also announced that Google has upgraded their membership to “Promoter” to get more involved with Vulkan development. Google has been sort-of hostile towards certain standards from The Khronos Group on Android in the past, such as disabling OpenCL on Nexus devices, and trying to steer developers into using Android Extension Pack and Renderscript. They seem to want to use Vulkan proper this time, which is always healthy for the API.
I guess look forward to Vulkan in 2016… hopefully early.
So Google has finally
So Google has finally realized that Vulkan as a more vendor neutral way of doing things is best, Google will save on software development expenses and they have probably seen what the Vulkan and other HSA aware APIs can do for computing and graphics. Vulkan with its SPIR-V IL will allow for that GPU acceleration alongside the graphics workloads in a very HSA aware way similar to the HSA foundation’s HSAIL. So Vulkan will be delayed until 2016, but even as this article states DX12 enabled games are not being used extensively either, so a little more time for Khronos and its industry members to get things finalized, and Khronos has AMD, Nvidia, Imagination Technologies(PowerVR), Intel, ARM, Qualcomm, Samsung and many other members! So like any standards base organization there are delays that come with having many interests involved!
It’s good to see Google involved so maybe even more improvements will keep coming for the Vulkan graphics/compute API. With all those industry players, if you can blame Khronos for the delay then you have to blame all of the members that make up the Khronos Group and that comes to just about everybody in the computing business.
The delay is not a surprise.
The delay is not a surprise. Look at the VR Headsets. They’ve also been delayed to 2016.
In a way, it’s a good thing to delay them to insure that they work correctly and that they are ready for consumers.
2016 will be an interesting year. For the good and the bad.
Don’t expect any vulkan
Don’t expect any vulkan titles until 2017, the battle of the APis with any significant titles with real world scenarios and non of that sponsored synthetic bs. Vr won’t be anything good either until 2020 when Developers, next gen consoles which are rumored to have 5 times more power per watt and would be capable of vr at enjoyable settings 2k @ 144hz, and then the pc can get the proper vr ports when everyone is on the same page when the wealest link is equal to todays enthusiast level pc.
According to my discussions
According to my discussions with The Khronos Group, Vulkan is not HSA-aware. Memory sharing is something they're looking at for future releases, though.
That’s HSA foundation 1.0
That’s HSA foundation 1.0 compliant memory sharing(UMA hardware), but OpenCL is HSA aware because it accelerates compute on the GPU, Vulkan is HSA aware because it accelerates graphics/compute on the GPU. Now the HSA foundation’s HSA 1.0 compliance also includes hardware compliance, but Vulkan is an HSA aware software API, and even the HSA foundations HSAIL is a software API. So when I say HSA aware, I mean able to accelerate compute on the GPU in addition to graphics. HSA aware, and The HSA foundation’s software/hardware compliance specification(HSA 1.0) is different matter more or less. Vulkan by being able to accelerate general purpose computation on the GPU via SPIR-V is very similar to the software side of the HSA foundation’s HSAIL in its software reach. The hardware side is another matter, and the HSA foundation is taking the lead on that, so heterogeneous compute has been around for decades. So let’s call Vulkan heterogeneous compute aware, and let the HSA stand for both software/hardware side of things. Things are evolving so fast with heterogeneous compute/HSA in both software and hardware.
I will also note that only AMD’s latest GCN GPU hardware in association with AMDs most current APUs is currently the only hardware that is fully HSA foundation HSA 1.0 compliant for hardware.
Neither AMD nor the HSA foundation have the rights to being in control over the only heterogeneous compute aware APIs out there, and the same companies for the most part that make up the HSA foundation’s membership also are the same companies that makes up for the Khronos group’s membership. HSA like aware software is not to be confused with the HSA foundation’s 1.0 specification’s hardware compliance, and Vulkan will run under Non HSA foundation 1.0 compliant hardware as well as the HSA foundation’s HSA 1.0 compliant hardware.
Currently there is only one series of AMD processors(APUs) that are Fully HSA foundation 1.0 HSA Standard compliant. Personally I’d like to see all APU/SOC hardware HSA foundation 1.0 compliant, but that’s not going to happen unless Intel joins in, so for now Vulkan and SPIR_V will have a much broader reach on the software side on the graphics/GPGPU API reach for now on all hardware platforms than even the HSA foundation’s HSAIL. And having The Vulkan SPIR-V IL with its API and HSA foundation’s HSAIL and its API are not necessarily mutually exclusive on many hardware platforms so there will be APU/SOC systems that will have both of these abstraction layers/APIs.
I would not expect that Vulkan is fully HSA foundation specification 1.0 compliant. But little hardware that Vulkan currently runs under is HSA foundstion 1.0 compliant also. I’m hoping for more HSA foundation 1.0 hardware compliance among the CPU/SOC members of the HSA foundation also, and they have just begun to move in that direction, but they are still all behind AMD for the HSA 1.0 hardware compliance.
What does HSA-aware mean for
What does HSA-aware mean for Vulkan? Is it going to have to do unnecessary memory copies on HSA compliant systems? Is such memory management even visible to the API? Intel doesn’t support HSA of some kind (?); do Intel systems using the integrated graphics core have to set aside an area of memory that can only be used for graphics like old IGP systems? Do AMD APUs not have to do that? It would be good if you could write up an article about how the graphics memory management currently works. What is handled by the OS, the driver, and the API? There has been a lot of issues with some, but not all console ports. I was wondering if this is due to the memory architecture. Specifically, do the games with performance issues on PC suffer from graphics assets getting swapped out to disk or swapped out of graphics memory to system memory?
AMD’s HSA 1.0 compliant APUs
AMD’s HSA 1.0 compliant APUs have Unified memory Addressing(UMA) and the CPU and integrated GPU on the APU die share the same memory address space, and if the CPU needs to pass any information to the GPU, the CPU only needs to pass a 4 byte memory pointer to the GPU the same pointer passing applies if the GPU wants to pass information to the CPU. So for AMD’s UMA enabled APUs the CPU and the GPU only need to pass 4 byte address pointers as they share the same memory address space.
Intel’s SOCs do not have full unified memory addressing, on Intel’s SOCs the on die eDRAM chip acts as level 4 cache shared between the CPU and GPU, but for large video draw calls data still needs to be transferred between separate CPU and GPU memory spaces. So if the data does not already reside on the eDRAM it needs to be fetched to to the eDRAM and only 64MB can fit there at any one time. For Intel large memory transfers still have to be performed for large frame buffers, while smaller data transfers can be done via the eDRAM, while for AMD its pass a pointer among the CPU and GPU and simply a read from unified memory for the CPU or GPU. Passing a 4 byte memory pointer between CPU and GPU on AMD’s UMA enabled APUs is a whole lot quicker and less energy intensive that whole blocks of memory transferred from a CPUs separate address space to a GPUs separate address space on non UMA enabled SOCs.
On Intel’s SOC the eDRAM helps but does not fully support UMA, and AMD does have CPU and GPU Caching/Caches that will be becoming more coherent with each level of HSA revision standards adopted. That HSA 1.0 will be continuously revised with each new iteration, and on AMD’s APUs the CPU will become even more integrated with the GPU. So expect that AMDs APUs, and APUs on an interposer, will begin to share Cache/Cache coherency controllers and other coherency functionality between CPU and GPU more directly, including at some future time with CPUs on APUs that have the ability to directly dispatch FP/INT/other workloads directly to the GPUs FP/INT/other execution units. Those high performance gaming APUs will be derived from AMD’s HPC/server/workstation and exascale APU SKUs in development for the HPC/server/workstation and exascale computing markets.
HSA aware for an API, any API, and not just the Vulkan graphics/compute API, will mean that there will be the level of HSA compliance in the software that will be able to take advantage of the HSA compliant hardware to perform any types of compute workloads on the GPU, or CPU.
So Vulkan will be able to send general purpose compute workloads to the GPU for non graphics compute even for current AMD/Intel hardware. Any APU/SOC that can utilize OpenCL, or Vulkan, etc. can be said to have a level of heterogeneous compute awareness. And, If the HSA compliant APU/SOC hardware is done correctly the hardware portions of the newer HSA compliant hardware should be abstracted away from the other non OS Kernel/non Device Driver software such that any non OS kernel/non device driver software automatically takes advantage of any new HSA features in the hardware without any application code needing changes!
And this hardware compatibility should happen with very little or no changes in the underlying APIs to have a benefit from the hardware changes beyond HSA 1.0, or newer, HSA hardware standards other than what is necessary for the OS/device drivers to take advantage of any new HSA hardware changes. So Vulkan should be able to run on any newer revision of HSA 1.0/1.0+ compliant and non HSA 1.0 compliant hardware without the user having too much of a disadvantage for the most average games at average game settings.
Most changes in APU/SOC/CPU/GPU hardware should only require that changes be made to the OS kernel/OS driver code/processor driver code, and very little change to the graphics APIs other than to support some new features while also supporting legacy GPU/CPU/other hardware features. Vulkan will support most current CPUs/SOCs/APUs of the last few years, while still working with the newer systems about to come online over the next year and beyond.
nah. google will do what they
nah. google will do what they want. it has always been like that. instead of fully supporting OpenCL they favor their own render script instead. another example is nexus 9. despite nvidia tegra K1 can fully support OpenGL 4.5 the Nexus 9 has been purposely limited by google to support OpenGL ES 3.1 and AEP only. hence certain games (that exclusive to tegra K1) cannot work with nexus 9 but work just fine on other K1 device like nvidia shield tablet and xiomi mipad. so i expect google will support vulcan but it will be how google want it to be not how the industry expect it to be.
Google are actually doing a
Google are actually doing a good thing by restricting their devices to OpenGL ES. OpenGL 4.5 is not for mobiles and a lot of mobile hardware simply don’t support it. It prevents people from developing games that simply won’t work on most hardware.
Apparently there is a
Apparently there is a diminishing return when it comes to graphics apis just like how there is a diminishing return on graphics hardware, graphics performance, and graphics performance / watt.
There are also diminishing
There are also diminishing returns on the CPU way down on the motherboard with the latency inducing PCI protocol encoding/decoding steps in order to communicate with the GPU, so having more of the non-graphics gaming workloads accelerated on the GPU via the Vulkan API will allow for more responsive gaming. The VR games will have to have the lowest amount of latency possible, and things like gaming physics and other gaming non-graphics compute workloads done on the GPU will improve VR gaming/regular gaming responsiveness drastically!
Having GPU cores/ACE units with fully in GPU hardware asynchronous compute and fully in GPU’s hardware GPU processor thread dispatch will allow for more efficient offloading of graphics/non-graphics gaming compute to the GPU cores/EUs. This more ON the GPU compute of both graphics and non graphics workloads on the GPU in an asynchronous compute manner will reduce the PCI latency inducing steps to a minimum. Doing more non-graphics gaming compute on the discrete GPU along with the normal graphics workloads will take a lot of the gaming/latency stress off of the motherboard bound CPU, and as a result that PCI latency issue will be reduced for the current designs of PC based gaming platforms that rely on discrete GPUs for gaming.
Future Gaming APUs on an Interposer, as well as current APUs, and SOCs, will have some latency advantage provided the APU/SOC makers adopt unified memory addressing and other HSA aware features for their mobile SOC/APU products. The APU on an interposer Era will usher in high performance gaming on the APU, with the CPU and the GPU both sharing an interposer and a wide multi-thousand traces wide DIRECT channel from CPU to GPU traced out on the interposer’s silicon substrate, in addition to the separate memory channels to the HBM stacks! So those PCI latency inducing encoding/decoding steps will be completely avoided on the interposer based APUs/SOCs that will be coming online for future gaming systems.
The Vulkan API will work to achieve this non-graphics gaming compute acceleration on the discrete GPU seamlessly with very little overhead for games, and non gaming software on the current PC based gaming systems! The Future APU based high end gaming systems on an interposer will be a game changer for both VR and regular gaming once they come online.
DirectX 12 Games, there’s
DirectX 12 Games, there’s more than “zero”.
I was certain there were at least 4 well advertised games available right now such as that Microsoft exclusive game : Fable Legends. That and others appears to have been pushed to a 2016 release.
From this link below, there are currently 2 games that are currently DX12 compatible for 2015.
https://en.wikipedia.org/wiki/List_of_games_with_DirectX_12_support
Yes but Vulkan will be
Yes but Vulkan will be available on Linux, windows 7, 8.1, and there are many that will not give up their windows 7 no matter how hard M$ trys to slip that update to 10 in under the RADAR! So DX12 is windows 10 only, with all of windows 10’s CPU cycles/bandwidth stealing Spyware, while for windows 7, 8.1 and Linux there will be Vulkan and none of that windows 10 spyware that is also and OS.
the tin foil hat people that
the tin foil hat people that stick to 7 and won’t go to 10 don’t matter.
Remember the windows 98 people that wouldn’t jump to XP?
Remember the windows XP people that are probably still running XP.
you are now one of those people.
Enjoy.
Paid Monopoly Apologists will
Paid Monopoly Apologists will continue to paint users’ privacy wishes as just some form of Tin Foil hat paranoid concerns, but the Privacy concerns about windows 10 are justified! M$ is about to be done in by its previous OSs that have less of the spying baked into them! It’s windows 7 with Vulkan dual booted with Linux until 2020, then it’s windows 7 running in a restricted Linux based VM environment after 2020 for legacy games, while gaming on Linux and Vulkan becomes completely able to run any of the newer games/gaming engines, and most older ones as well.
Vulkan, and an OpenGL to Vulkan translation layer will allow for many of the Graphics applications, and games, that require OpenGL to run on the Vulkan graphics API while the software stack for gaming/other workloads is fully converted over to Vulkan over time. I’d imagine that there will be even a DX12 to Vulkan abstraction/translation layer for some Linux/Vulkan based gaming on Linux gaming platforms for games/games companies that are so under M$’s thumb that no Vulkan compatibility will be provided, mostly at first, before the entire gaming industry breaks free of the M$ PC/Laptop OS monopoly’s evil clutches!
Khronos is still supporting OpenGL, but there will be an OpenGL to Vulkan translation layer for those that want to slowly convert OpenGL only applications over to full Vulkan based applications a little bit at a time, and expect there to be some DX12 to Vulkan middle-ware and other software tools to break M$’s OS vendor lock-in on the gaming/other market, just like AMD is now offering tools to port over CUDA applications to more open C++/OpenCL/other standard Open graphics/GPU accelerator APIs! The break for platform freedom is just beginning to make its way forward towards total OS platform independence under the Vulkan graphics API!
M$ is not welcome to squat on MY PC/Laptop, steal MY bandwidth, MY CPU cycles, and steal IP service provider data allocation limits, and steal my personal information for any of its monetary gain! It’s time to relegate the M$ OS Trust to the same dustbin of history that the Standard Oil Trust was relegated to over a century ago! I purchased MY PCs/Laptops from an independent third party laptop/PC OEM, and not M$, so by twisted reasoning does M$ think it has the right to make ME, MY PC/Laptop hardware, and MY personal information into a product for M$’s enrichment! This is an Illegal attempt at a vertical market integration of the independent third party laptop/PC OEM market, and it is a direct violation of the Sherman Antitrust ACT! Windows 10 is an illegal monopolistic land grab onto users independently manufactured third party OEM PC/Laptop hardware, and M$ needs to be stopped!
Edit: so by twisted
Edit: so by twisted reasoning
to so by what twisted reasoning
If you truly have privacy
If you truly have privacy concerns with Microsoft OSes, then get the hell of Windows 7 and switch to Linux. And for gods sake keep it updated. The cancer of XP sticking around has been terrible for everyone, and if you really have a concern over privacy (rather then being cheap, or fearing change) then staying on Windows 7 is a terrible idea. Trusting Microsoft to run your OS in one case but not another is totally irrationally
Really there are a lot of
Really there are a lot of companies running XP in locked down Linux based VMs that are safely restricted from any internet access to run any XP only legacy code. Maybe you do not see that companies spend way more than the cost of an OS on getting their mission critical software to run with and be certified to work with a new OS!
The cost of an OS pales in comparison to the cost of getting the company’s mission critical software certified to run under a new OS in a safe and error free way! So windows 7 will in fact be the new XP, and there are even multi-million dollar pieces of machine tool/CGI machinery that only run with XP certified software, and the companies can not afford to replace the machinery until is is completely worn out.
Do not expect that windows 10 will be replacing any company’s windows 7 conversions that they have just switched to from XP, those mission critical software updates and certifications to work under a new OS will only be affordable in 5 to 10 year upgrade increments. Windows 7 will be around longer than XP, and if M$ does not provide for extended support then M$ will loose more business from enterprises.
For sure enterprises will not stand for that Spy-Ware infected consumer based windows 10 build with its forced updates that break things, and even the enterprise version of 10 is a long way off from happening from most enterprises with IT budgets to follow! It’s the mission critical software that must work to run the business and that costs in the millions to rewrite for any new OS, so the enterprise users will get their money’s worth out of the costs of converting over to 7, before they even think about 10 or 10’s replacement!
Edit: Loose
To: lose
Edit: Loose
To: lose
Just one is released with
Just one is released with DirectX 12 support, "Caffeine." Two others will be patched in 2016, and four are in early access. Also, Caffeine uses Unreal Engine 4's implementation, which is still classified as experimental.
“Nvidia loses its appeal on
“Nvidia loses its appeal on ITC patent loss”
http://semiaccurate.com/2015/12/21/nvidia-loses-its-appeal-on-itc-patent-loss/
This is no surprise, but
This is no surprise, but nvidia is trying to cover this up as much as possible.
Still, that’s quite a few patents getting officially invalidated there.
What a bunch of baloney.
What a bunch of baloney. Clearly, the media and the courts are now conspiring to make Nvidia look bad. Nvidia’s just trying to defend itself and its patents on anything and everything inside and outside the “GPU” that they so clearly and obviously invented. They’re definitely not, in any way, shape, or form, trying to use the courts to strongarm competitors into either going broke or giving them money. No way.
Nvidia’s intentions are purely honorable, and the tech press and the courts are just trying to bring them down and sabotage them. Long live Nvidia! Long live Huang!
Down with the Green Goblin
Down with the Green Goblin Gimpers at Nvidia, and their UN-enforceable overly broad GPU patents that should have never been awarded a patent for in the first place! The USPTO needs to only employ experienced engineers and lawyers with the proper computer engineering backgrounds to stop all of this poorly awarded and opportunistic(Nvidia in this case) patent filings for patents that result in millions spent on court costs and litigation. Nvidia did not invent the GPU, there where others with prior ART, and that includes the other Nvidia patents that were rightfully voided.
Better get your fully in hardware asynchronous compute and fully in hardware GPU processor thread dispatch ducks in order, Nvidia, or you will begin to be at a serious disadvantage for VR gaming relative to AMD. Those AMD high end gaming APUs on an interposer are going to seriously put Nvidia at a disadvantage if Nvidia can not get into the Gaming APU/SOC on an interposer market.
“that about 50% of PC games
“that about 50% of PC games would be DX12-compatible by Holiday 2015”
?
Did they really say that?
I know they said something like “50% of GPU’s would be DX12 compatible” but 50% of games seems an odd thing to say given how long game development takes.
If they did say it, I wonder if they were including the XBOX ONE into that figure.
Or perhaps they meant the games could easily incorporate DX12 due to the newer game engine because, note, they didn’t say the games “would run DX12” but rather “were compatible with DX12” which seems a different thing to me.
This was said during Ryan’s
This was said during Ryan's live blog at Microsoft's GDC 2014 (almost two years ago) when DirectX 12 was first announced.
Nvidia ants are everywhere.
Nvidia ants are everywhere. Mother Nvidia controls all Nvidia ants. The NVidia ants (NVidia fanboys) are unable to function without mother NVidia.
That is the way things are going to stay.
Nvidia loses its appeal on ITC patent loss:
http://semiaccurate.com/2015/12/21/nvidia-loses-its-appeal-on-itc-patent-loss/
So is Khronos Group pickup
So is Khronos Group pickup where AMD left off? Saying it will release in a certain time frame then miss it by least 3-6 months?
And Nvidia is a member of the
And Nvidia is a member of the Khronos group, the Khronos Group’s president is employed by Nvidia! So Go Figure, you you negative Spin Minion!
https://en.wikipedia.org/wiki/Khronos_Group
HA HA, that’s pretty funny,
HA HA, that’s pretty funny, and ironic actually.
Still, I’m sure he’s stalling as much as he can for nvidia to patch in code to plug in what is missing at the hardware level.
Nvidia can patch away, but
Nvidia can patch away, but unless they get that fully in hardware asynchronous compute ability and that fully in hardware graphics/compute GPU processing thread scheduling and dispatch circuity, Nvidia is going to waste GPU execution resources via underutilized GPU core execution resources. That inability to interleave graphics and compute processing threads on Nvidia’s GPUs will result in underutilized FP/INT/Other resources. That software based GPU thread scheduling and dispatch will keep the execution queues backed up while FP/INT/Other units sit Idle!
Just Imagine Intel’s version of SMT(Hyper-Threading) implemented in software instead of fully in hardware, the software would never be able to keep the processor’s threads scheduled efficiently without the circuity in the core to schedule and dispatch processing threads. Simply having to go off the core to fetch the scheduling algorithms from memory, or even Cache memory, would see many idle execution pipelines waiting for the scheduling/thread dispatch code to be fetched and decoded from memory and executed. What a train wreck that would be!
I’m forced to wonder if you
I’m forced to wonder if you even bothered to read any of the article, or if you just saw an article about Vulkan being delayed and saw an opportunity to bash AMD and shill for Nvidia.
Because if you had actually bothered to read any of the article, you would have seen this passage:
“I know that most people will be quick to blame The Khronos Group for this, because industry bodies moving slowly is a stereotype, but I don’t think it applies. When AMD created Mantle, it bore some significant delays at all levels. Its drivers and software were held back, and the public release of its SDK was delayed out of existence. Again, it would be easy to blame AMD for this, but hold on. We now get to Microsoft. DirectX 12, which is maybe even closer to Mantle than Vulkan is due to its shading language, didn’t roll out as aggressively as Microsoft expected, either. Software is still pretty much non-existent when they claimed, at GDC 2014, that about 50% of PC games would be DX12-compatible by Holiday 2015. We currently have… … zero (excluding pre-release).
Say what you like about the three examples individually, but when all three show problems, then there might just be a few issues that took longer than expected to solve.“
I am a little off-topic, but
I am a little off-topic, but the following is true.
Nvidia ants (NVidia fanboys) bash AMD on many many websites. Mother Nvidia infringes Samsung patents. NVidia ants tell us that Mother NVidia is the most respected company in the world.
http://seekingalpha.com/news/3001126-itc-judge-rules-nvidia-infringes-samsung-patents
Who is lying? ITC judge or Nvidia ants? I think Nvidia ants are controlled by very strong substance.
When this is released, it
When this is released, it should give more respect to the intellectual abilities of the klingon people. For too long, they have been considered merely great warriors with guts and glory with hardly the ability to develop complex systems without special drugs to inhibit their, sometimes considered, barbaric behavior to other races, now banned.