News


Vulkan Status Update: Will Use Feature Sets, Android Support Incoming

Vulkan Status Update: Will Use Feature Sets, Android Support Incoming

Along with updates on OpenGL, Khronos is also offering a status update on the development of Vulkan at this year’s SIGGRAPH show. Khronos’s next-generation low-level API was announced last year, with further development taking off this year when it was announced at the API would be absorbing Mantle 1.0 and would operate under its current fiery name. The API is still in development, but Khronos has a few new pieces of information to share on the progress of development.

Vulkan Feature Sets

First and foremost, there has been a bit of speculation over how Vulkan would manage being a low-level API for both mobile and desktops, and Khronos is finally answering those questions. In the OpenGL ecosystem, new features would be exposed as optional extensions, and then standardized through core releases (e.g. OpenGL ES 3.2). Due to the factors that resulted in the creation of OpenGL ES, this was never a huge problem for either branch of OpenGL since each could be scoped as appropriate and integrated separately. However with Vulkan there is now just one API, and such a coarse approach would imply limiting Vulkan to just the features mobile GPUs could support, or making even more extensive use of extensions.

To that end, today Khronos is announcing that Vulkan will support defined feature sets in order to help simplify application development and to more readily support mobile and desktop hardware under the same API. Feature sets, as implied by the name, will be groupings of features that will be advertised under a single feature set name, with the idea being that developers will build their programs against a handful of feature sets instead of a massive combination of individual extensions or capability bits (though developers can still use individual features if they’d like). Feature sets are nothing new to desktop graphics, with Microsoft’s DirectX standard having supported them since DirectX 11 in 2009.

While Khronos is announcing that Vulkan will support feature sets, they are not announcing the individual feature sets, and for good reason. In traditional Khronos consortium fashion, Khronos is going to leave the feature set definitions up to the platform holder rather than define those sets themselves. This means that it will typically be the OS developer defining the feature sets, as will be the case on Android. However because Khronos is leaving this up to the platform holder, for holders who opt not to define feature sets for their Vulkan-enabled platforms, Khronos will step in and define those feature sets. In other words platform holders get first dibs, but either way someone will take on the task of defining the feature sets.

Practically speaking, this means that while Android’s feature set will be defined by Google and one can expect SteamOS’s to be defined by Valve, Windows’ feature set will be defined by Khronos. Microsoft is a member of the Khronos consortium and could define it, however Microsoft has taken a hands-off approach on Khronos’s graphics APIs in recent years – presumably in favor of focusing on DirectX – so we’re not expecting to see Microsoft make those definitions. Feature definitions have always been a weak point of the Khronos consortium structure, so giving platform holders the right of first refusal will allow holders such as Google to break the deadlock of the consortium and dictate what features will be supported on Android. Otherwise Khronos will be able to get the job done, though one would expect not without the traditional politics of the consortium.

Vulkan Feature Set Definitions
Platform Expected To Be Defined By
Android Platform Holder – Google
SteamOS Platform Holder – Valve?
Linux Khronos?
Windows Khronos (Platform holder Microsoft is anticipated to decline)

Android Support

Speaking of Android, along with announcing their support for OpenGL ES 3.2 today, Google is also announcing that they will be supporting Vulkan in a future release of Android. As with OpenGL ES 3.2, no specific timeline or version of Android is mentioned, though it’s a safe bet that it will be the 2016 release. Android has traditionally heavily relied on OpenGL ES, and with Google sewing further ties with Khronos with the Android Extension Pack, it’s not surprising that Android will include support for Vulkan in order to bring low-level graphics programming to the ecosystem’s developers.

Apple, for what it’s worth, has been absent from the Khronos announcements. As the company is pushing Metal on both mobile and desktop, it looks unlikely that they will be adopting Vulkan any time soon. In which case Vulkan wouldn’t quite match OpenGL ES 3.0’s universal reach due to Apple’s reliance on proprietary APIs.

Vulkan Conformance Tests Will Be Open Source

Meanwhile on the testing and validation front, Khronos is announcing that they are teaming up with Google and the Android Open Source Project to release the Vulkan conformance tests as as open source tests. The tests themselves are being developed by Khronos members and contractors, with the Khronos/ASOP connection coming in to provide the frameworks. The tests themselves are portable to other platforms – Khronos made this point very clear in our briefing – but partnering up with Google helps Khronos get the tests out there sooner and to fulfil their open source goals.

ETA: Late 2015

Finally, Khronos is also offering a bit more guidance on when to expect the first revision of Vulkan. Khronos’s goal for the specification is to release it by the end of the year, which means they should be wrapping up development of the specification soon. Meanwhile driver/runtime development has been occurring concurrently with the development of the specification, which means that the first drivers will be ready at the same time. Khronos does require that there are working implementations before a specification is released to production, so with any luck Vulkan will be ready as a development target and for early end-user testing by the end of 2015.

Update: And speaking of Vulkan’s ETA, there are multiple Vulkan demos on the SIGGRAPH showfloor, demonstrating the API and the current status of vendor implementations. First out of the gate is Imagination, showing off a demo running on Android.

Vulkan Status Update: Will Use Feature Sets, Android Support Incoming

Vulkan Status Update: Will Use Feature Sets, Android Support Incoming

Along with updates on OpenGL, Khronos is also offering a status update on the development of Vulkan at this year’s SIGGRAPH show. Khronos’s next-generation low-level API was announced last year, with further development taking off this year when it was announced at the API would be absorbing Mantle 1.0 and would operate under its current fiery name. The API is still in development, but Khronos has a few new pieces of information to share on the progress of development.

Vulkan Feature Sets

First and foremost, there has been a bit of speculation over how Vulkan would manage being a low-level API for both mobile and desktops, and Khronos is finally answering those questions. In the OpenGL ecosystem, new features would be exposed as optional extensions, and then standardized through core releases (e.g. OpenGL ES 3.2). Due to the factors that resulted in the creation of OpenGL ES, this was never a huge problem for either branch of OpenGL since each could be scoped as appropriate and integrated separately. However with Vulkan there is now just one API, and such a coarse approach would imply limiting Vulkan to just the features mobile GPUs could support, or making even more extensive use of extensions.

To that end, today Khronos is announcing that Vulkan will support defined feature sets in order to help simplify application development and to more readily support mobile and desktop hardware under the same API. Feature sets, as implied by the name, will be groupings of features that will be advertised under a single feature set name, with the idea being that developers will build their programs against a handful of feature sets instead of a massive combination of individual extensions or capability bits (though developers can still use individual features if they’d like). Feature sets are nothing new to desktop graphics, with Microsoft’s DirectX standard having supported them since DirectX 11 in 2009.

While Khronos is announcing that Vulkan will support feature sets, they are not announcing the individual feature sets, and for good reason. In traditional Khronos consortium fashion, Khronos is going to leave the feature set definitions up to the platform holder rather than define those sets themselves. This means that it will typically be the OS developer defining the feature sets, as will be the case on Android. However because Khronos is leaving this up to the platform holder, for holders who opt not to define feature sets for their Vulkan-enabled platforms, Khronos will step in and define those feature sets. In other words platform holders get first dibs, but either way someone will take on the task of defining the feature sets.

Practically speaking, this means that while Android’s feature set will be defined by Google and one can expect SteamOS’s to be defined by Valve, Windows’ feature set will be defined by Khronos. Microsoft is a member of the Khronos consortium and could define it, however Microsoft has taken a hands-off approach on Khronos’s graphics APIs in recent years – presumably in favor of focusing on DirectX – so we’re not expecting to see Microsoft make those definitions. Feature definitions have always been a weak point of the Khronos consortium structure, so giving platform holders the right of first refusal will allow holders such as Google to break the deadlock of the consortium and dictate what features will be supported on Android. Otherwise Khronos will be able to get the job done, though one would expect not without the traditional politics of the consortium.

Vulkan Feature Set Definitions
Platform Expected To Be Defined By
Android Platform Holder – Google
SteamOS Platform Holder – Valve?
Linux Khronos?
Windows Khronos (Platform holder Microsoft is anticipated to decline)

Android Support

Speaking of Android, along with announcing their support for OpenGL ES 3.2 today, Google is also announcing that they will be supporting Vulkan in a future release of Android. As with OpenGL ES 3.2, no specific timeline or version of Android is mentioned, though it’s a safe bet that it will be the 2016 release. Android has traditionally heavily relied on OpenGL ES, and with Google sewing further ties with Khronos with the Android Extension Pack, it’s not surprising that Android will include support for Vulkan in order to bring low-level graphics programming to the ecosystem’s developers.

Apple, for what it’s worth, has been absent from the Khronos announcements. As the company is pushing Metal on both mobile and desktop, it looks unlikely that they will be adopting Vulkan any time soon. In which case Vulkan wouldn’t quite match OpenGL ES 3.0’s universal reach due to Apple’s reliance on proprietary APIs.

Vulkan Conformance Tests Will Be Open Source

Meanwhile on the testing and validation front, Khronos is announcing that they are teaming up with Google and the Android Open Source Project to release the Vulkan conformance tests as as open source tests. The tests themselves are being developed by Khronos members and contractors, with the Khronos/ASOP connection coming in to provide the frameworks. The tests themselves are portable to other platforms – Khronos made this point very clear in our briefing – but partnering up with Google helps Khronos get the tests out there sooner and to fulfil their open source goals.

ETA: Late 2015

Finally, Khronos is also offering a bit more guidance on when to expect the first revision of Vulkan. Khronos’s goal for the specification is to release it by the end of the year, which means they should be wrapping up development of the specification soon. Meanwhile driver/runtime development has been occurring concurrently with the development of the specification, which means that the first drivers will be ready at the same time. Khronos does require that there are working implementations before a specification is released to production, so with any luck Vulkan will be ready as a development target and for early end-user testing by the end of 2015.

Update: And speaking of Vulkan’s ETA, there are multiple Vulkan demos on the SIGGRAPH showfloor, demonstrating the API and the current status of vendor implementations. First out of the gate is Imagination, showing off a demo running on Android.

ASRock Rack C2750D4I and U-NAS NSC-800: A DIY File Server

Small businesses and power users often need the flexibility offered by a file server when compared to a dedicated NAS. This is where storage servers based on Microsoft’s Windows Server offerings and systems based on Red Hat or Ubuntu Linux distributions come into play. These servers can be bought as an appliance or assembled in a do-it-yourself (DIY) fashion. Today, we will be looking at the latter approach using as ASRock Rack C2750D4I Intel Avoton mITX motherboard in a 8-bay U-NAS NSC-800 chassis.

ASRock Rack C2750D4I and U-NAS NSC-800: A DIY File Server

Small businesses and power users often need the flexibility offered by a file server when compared to a dedicated NAS. This is where storage servers based on Microsoft’s Windows Server offerings and systems based on Red Hat or Ubuntu Linux distributions come into play. These servers can be bought as an appliance or assembled in a do-it-yourself (DIY) fashion. Today, we will be looking at the latter approach using as ASRock Rack C2750D4I Intel Avoton mITX motherboard in a 8-bay U-NAS NSC-800 chassis.

Skylake CPU Package: Mini-Analysis

Skylake CPU Package: Mini-Analysis

As a short side piece from our in depth review on Intel’s 6th Generation Core processors, codename Skylake, the well-known overclocker Splave has posted some very interesting images on the processor itself. We confirmed we are free to use the pictures below from him.


Image from Splave

First up is an image of the Skylake i7 silicon die on package. With our trusty interpolation measuring skills, the die area for the GT2 enabled quad core system comes out at 9.05 mm by 13.52 mm, or 122.4 square mm. Let’s put this into perspective with other dies:

CPU Specification Comparison
CPU Process
Node
Cores GPU Transistor
Count
(Schematic)
Die Size
Intel Skylake GT2 4C 14nm 4 GT2 ? 122.4mm2
Intel Broadwell-H GT3e 4C 14nm 4 GT3e ? ?
Intel Haswell-E 8C 22nm 8 N/A 2.6B 356mm2
Intel Haswell GT2 4C 22nm 4 GT2 1.4B 177mm2
Intel Haswell ULT GT3 2C 22nm 2 GT3 1.3B 181mm2
Intel Ivy Bridge-E 6C 22nm 6 N/A 1.86B 257mm2
Intel Ivy Bridge 4C 22nm 4 GT2 1.2B 160mm2
Intel Sandy Bridge-E 6C 32nm 6 N/A 2.27B 435mm2
Intel Sandy Bridge 4C 32nm 4 GT2 995M 216mm2
Intel Lynnfield 4C 45nm 4 N/A 774M 296mm2
AMD Trinity 4C 32nm 4 7660D 1.303B 246mm2
AMD Vishera 8C 32nm 8 N/A 1.2B 315mm2

This makes Skylake the smallest die size for a quad core desktop processor from Intel we have seen, and that is including the integrated graphics in that calcualtion. Depending on the exact architectural details, previously in Haswell the die area was a near even split for cores and graphics after the L3 cache and IO functions (PCIe, Memory, DMI) were removed. 

We won’t know exact transistor numbers until they are disclosed at Intel’s Developer Forum in mid-August, as well as a false color image die shot to show how much die area the main parts of the architecture are using. Although given the similarity to Haswell in terms of feature set (it seems to be similar with a few minor additions such as fixed function units, slightly different libraries, dual memory channels, DMI 3.0, etc.), if we take the number of transistors that GT2 Haswell had (1.4 billion) and put them in the die area we measure from the image, this comes out to a 11.4 million transistors per mm2.

Die size aside, Skylake also has a substantially thinner package than Devil’s Canyon:


Image from Splave


Image from PCWatch

According to PCWatch, the package thickness of the Core i7-4770K is 1.1mm, compared to 0.8mm for Skylake. This is a direct result of using fewer PCB layers, and here we count five for Skylake and eight for Haswell.

There could be several reasons for this. The removal of the fully integrated voltage regulator (FIVR) might reduce the number of PCB layers for power planes. The nature of the 14nm die might facilitate a thinner package as well. The cynical answer is that it is used to drive down cost. In the motherboard industry, a PCB with more layers is substantially more expensive but simplifies design when there are more features – there’s also a side argument if more layers or fewer layers is better for overclocking. If we transplant this thinking to the processor, it becomes a balance of cost vs. complexity. Either way, the retail price of the processor is still relatively consistent with the previous iterations. Another thought to add to the mix would be if Intel has plans in the works to launch higher end processors based on Skylake (Kaby Lake?) in the future. The slight change in Intel’s processor naming scheme (4770K to 6700K, as in 70K to 00K) also points to the potential move later in the lifetime of the product. The only hint in the naming scheme from Intel is that the ‘processor numbering reflects that these processors belong to the 6th Gen Intel Core family’.

The thinness of the package has implications for removing the lid/heatspreader of the processor as well. Splave notes that previous heatspreader methods involving force, such as vices that were common during Haswell’s tenure, may not be appropriate due to the thinness of Skylake. Splave shows an image of a failed attempt by another user on a Skylake CPU:


Image from Splave

Instead, a razor method (and something warm such as a hairdryer or the bean bags that iFixit uses to warm up glue in smartphones to take them apart) to cut through the black adhesive between the package and the IHS is suggested and it what was used for the CPU above. As there are no FIVR resistors to worry about on the top of the package, the first resistance a razor blade will encounter after the black adhesive is the silicon die itself. All that being said, over at PCWatch they successfully have used a vice method.


Image from Splave

Interestingly the heatspreader for Skylake is heavier than that from Haswell by nearly 20%, moving up from 22g to 26g. Given the copper mass that usually sits on a high end processor this should not matter much, although basic aluminium coolers might see a small benefit here by virtue of the minor extra mass. This might also just be that the mounting requirements for Haswell and Skylake are the same, and the extra mass comes from the added z-height required to maintain the mounting as before. 

So why are we talking about removing the heatspreader? Back with Haswell (as well as Ivy Bridge to a degree), it was discovered that the thermal interface material between the silicon die and the heatspreader was both an insufficient amount and lower quality than previous generations, as well as the heatspreader being far away from the CPU due to the black adhesive, causing more air bubbles and poorer heat transfer than is optimal. For a stock processor, this difference has little effect to the use of the system, but for overclockers it meant that they were more thermally limited than silicon limited with their overclocking.


Image courtesy of Idontcare

Devil’s Canyon changed that – here was a better binned Haswell processor with a higher quality package, giving a ten degrees cooler system at load. It is worth noting that previously on certain platforms Intel had been providing a mixed metal interface (generalized as a soldered interface) between the silicon and the heatspreader, which is the best but most expensive option. If the cost of the interface is reduced by 0.1 cents, then that’s a significant saving on millions of processors. Devil’s Canyon was a small subset of sales, so spending that extra for that specific crowd could be seen as beneficial to Intel’s perspective by overclockers.


Image from PCWatch

To paraphrase Splave again, he comments that the thermal paste (TIM)o n his Skylake is certainly worse than that of Devil’s Canyon. If the extra mass on the IHS is coming from a taller heatspreader (by virtue of the smaller package substrate), then more TIM is needed otherwise there will be substantial air bubbling of the TIM between the CPU and the heatspreader. By replacing his own thermal paste and resecuring the heatspreader, he saw an 18°C drop in temperatures at his highest air overclock with the old paste (5.1 GHz at 1.48 volts) – from 96ºC that overheated to 78ºC on the warmest core. An 18°C drop is immense. Under those conditions, and based on rough testing not published in our Skylake review, it could equal another 100-400 MHz depending on the quality of the processor. PCWatch confirms that switching out the paste with CoolLaboratory’s Liquid Pro (a liquid metal adhesion interface) reduced temperatures at 4.6 GHz from 88ºC to 68ºC


Image from PCWatch

This throws up some questions – is this just a result of design decisions for cost, or is there a Devil’s Canyon type processor coming later in the design cycle?

Source: Overclock.net, PCWatch