RADV Gets Patches For Float64 Support, Now In Mesa Git

[phoronix]

Phoronix: RADV Gets Patches For Float64 Support

Less than 24 hours after RADV geometry shaders landed in Mesa Git along with other improvements, patches have been published for wiring up Float64 support for this open-source Radeon Vulkan driver...

http://www.phoronix.com/scan.php?page=news_item&px=RADV-Float64-Patches

[oooverclocker]

Google has contracted AMD for GPUs for deep learning that could also be used for other purposes that (Editerhaps) support a 1:2 performance ratio - FP64:FP32.

[grndzro]

I wonder if AMD is thinking...why didn't we open all our crap up sooner? We could have had perfect open source drivers years ago.

[oooverclocker]

Indeed. Being able to improve the drivers by yourself of course makes the hardware extremely more attractive especially for companies. You can minimize issues and downtimes of services, speed up development processes that rely on features or bugfixes you would have to wait for instead and also commit socially at the same time which is great for marketing. For these companies employing the MESA people this ability has pretty surely been a major reason.
Also for game developers these benefits are essential and are some of the main arguments for Vulkan. There have been at least reports by devs in the MESA bugtracker that have been fixed quite soon. When there are more companies joining the development for SteamOS/Linux it could bring optimization for AMD hardware in the lead.

Nvidia's strategy is quite opposing. It looks like they will perhaps become more open minded for Vulkan stuff but their major strength in older APIs lies in the closed sources and they profit from vendor locks etc. So basically what AMD did was hitting Nvidia where it hurts most.
For Valve smooth 60FPS/Hz for SteamOS do basically suffice until Vulkan gets more common. For the most people playing on TVs an CPU bound FPS cap at 100Hz is no issue at all. For the software that Google runs they can of course optimize it for the architecture so there are no issues at all.

[bridgman]

I wonder if AMD is thinking...why didn't we open all our crap up sooner? We could have had perfect open source drivers years ago.

Actually we were only closed for ~4 years (2002-2007). Before 2002 the Linux drivers were open source, and we restarted the open source effort in ~2007 albeit on a larger scale than before. It took a while to catch up after being away though, and took a lot more years to bring the open source stack up to the same performance & feature level as the code-shared one.

[humbug]

Actually we were only closed for ~4 years (2002-2007). Before 2002 the Linux drivers were open source, and we restarted the open source effort in ~2007 albeit on a larger scale than before. It took a while to catch up after being away though, and took a lot more years to bring the open source stack up to the same performance & feature level as the code-shared one.

seems like in the last couple years or so we are getting a lot of pay off from that effort with basically all GCN GPUs becoming capable of providing a solid user experience on open drivers.

when vega comes do you plan to have both open and AMDGPU PRO options available at launch day?

[smitty3268]

seems like in the last couple years or so we are getting a lot of pay off from that effort with basically all GCN GPUs becoming capable of providing a solid user experience on open drivers.

when vega comes do you plan to have both open and AMDGPU PRO options available at launch day?

Pretty sure they've said in the past they are aiming to get the open drivers support on launch, but at this point it's pretty clear it won't be upstream in time. Probably a forked branch somewhere and public patches, like they already have for DAL. Maybe in the next upstream unreleased branch if they get lucky (I'm doubtful though).

[tomtomme]

Google has contracted AMD for Instinct GPUs for deep learning that could also be used for other purposes and will very likely support a 1:2 performance ratio - FP64:FP32.

a pitty. your source says nothing about such a google-contract. It just links to AMD design wins for a google data center - not deep learning.

[liam]

Indeed. Being able to improve the drivers by yourself of course makes the hardware extremely more attractive especially for companies. You can minimize issues and downtimes of services, speed up development processes that rely on features or bugfixes you would have to wait for instead and also commit socially at the same time which is great for marketing. For these companies employing the MESA people this ability has pretty surely been a major reason.
Also for game developers these benefits are essential and are some of the main arguments for Vulkan. There have been at least reports by devs in the MESA bugtracker that have been fixed quite soon. When there are more companies joining the development for SteamOS/Linux it could bring optimization for AMD hardware in the lead.

Nvidia's strategy is quite opposing. It looks like they will perhaps become more open minded for Vulkan stuff but their major strength in older APIs lies in the closed sources and they profit from vendor locks etc. So basically what AMD did was hitting Nvidia where it hurts most.
For Valve smooth 60FPS/Hz for SteamOS do basically suffice until Vulkan gets more common. For the most people playing on TVs an CPU bound FPS cap at 100Hz is no issue at all. For the software that Google runs they can of course optimize it for the architecture so there are no issues at all.

If a company is willing to go that far (fixing driver bugs), fpgas make more sense, especially with deep learning.

[oooverclocker]

a pitty. your source says nothing about such a google-contract. It just links to AMD design wins for a google data center - not deep learning.

Yeah, I mixed that up with this article: Google Taps AMD For Accelerating Machine Learning In The Cloud
But the purpose of Instinct GPUs is quite likely the same... The raw performance is clearly better