AMD To License Out Radeon GPU IP to Samsung For Use In SLSI Mobile GPUs
by Andrei Frumusanu on June 3, 2019 10:30 AM EST
Today Samsung and AMD announced a new multi-year strategic partnership between the two companies, where Samsung SLSI will license graphics IP from AMD for use in mobile GPUs.
The announcement is a major disruptive move for the mobile graphics landscape as it signifies that Samsung is going forward with the productization of their own in-house GPU architecture in future Exynos chipsets.
Samsung is said to have started work on their own “S-GPU” at its research division back around in 2012, with the company handing over the new IP to a new division called “ACL”, or Advanced Computing Lab in San Jose, which has a joint charter with SARC (Samsung Austin R&D Center, where Samsung currently designs its custom mobile CPU & memory controller IP).
With today’s announced partnership, Samsung will license “custom graphics IP” from AMD. What this IP means is a bit unclear from the press release, but we have some strong pointers on what it might be.
Samsung’s own GPU architecture is already quite far along, having seen 7 years of development, and already being integrated in test silicon chipsets. Unless the deal was signed years ago and only publicly announced today, it would signify that the IP being talked about now is a patent-deal, rather than new architectural IP from AMD that Samsung would integrate in their own designs.
Samsung’s new GPU IP is the first from-scratch design in over a decade, in an industry with very old incumbents with massive patent-pools. Thus what today’s announcement likely means is likely that Samsung is buying a patent-chest from AMD in order to protect themselves from possible litigation from other industry players.
Of course, it is also possible that today’s announcement could signify Samsung’s abandoning of its own in-house core compute design in favour of AMD’s new IP. The announcement specifically mentions “custom graphics IP based on the recently announced, highly-scalable RDNA graphics architecture”, and Dr. Lisa Su also mentions “significantly expanding the Radeon user base and development ecosystem.”. The latter quote of expanding the development ecosystem wouldn’t make sense if the licensed IP would be solely patent related.
The licensing deal mentions coverage for mobile devices, including smartphones, which complement AMD product offerings, which in a way could preclude Samsung from using the new IP in larger form-factors such as laptops.
Dr. Lisa Su, AMD president and CEO:
“Adoption of our Radeon graphics technologies across the PC, game console, cloud and HPC markets has grown significantly and we are thrilled to now partner with industry leader Samsung to accelerate graphics innovation in the mobile market, this strategic partnership will extend the reach of our high-performance Radeon graphics into the mobile market, significantly expanding the Radeon user base and development ecosystem.”
Inyup Kang, president of Samsung Electronics’ S.LSI Business:
“As we prepare for disruptive changes in technology and discover new opportunities, our partnership with AMD will allow us to bring groundbreaking graphics products and solutions to market for tomorrow’s mobile applications. We look forward to working with AMD to accelerate innovations in mobile graphics technologies that will help take future mobile computing to the next level.”
Facebook
Twitter
RSS
46 Comments
View All Comments
tekniknord - Monday, June 3, 2019 - link
Mobile GPU mostly support and use OpenGL ES and Vulkan.webdoctors - Monday, June 3, 2019 - link
Yup, but there's other standards like programming APIs . So on Windows you have DirectX, which is obviously not on Apple or Android OS. But stuff like vulkan and openGL is already running on Linux so would run fine on Apple/Android stuff.mode_13h - Monday, June 3, 2019 - link
Apple uses Metal, which AMD already supports on MacOS.Android uses Vulkan, OpenGL, and RenderScript - not sure if AMD supports the last one, but I guess it'd be a requirement to have AMD APUs in Chromebooks.
ChrisGX - Tuesday, June 4, 2019 - link
Support for Renderscript could be flagging at Google. There have been large performance regressions on Renderscript code with the latest versions of Android on the latest mobile SoCs. While I don't know the reason for this it is possible that Google could be thinking about the virtues of industry standards - and the standards promulgated by AMD are open and as universal as you can get at this point - for Android, not so much as an advertising point but to remove resistance from developers. Still, no announcements yet. I am speaking only about possibilities, here. But those regressions do need to be explained.mode_13h - Monday, June 3, 2019 - link
You can use both AMD and Nvidia GPUs on POWER systems, FWIW.ChrisGX - Tuesday, June 4, 2019 - link
Note of caution: I am not someone with the proper qualifications to be answering this question but I too would like to see it answered. Hopefully, someone more qualified will comment. Here is my take on it.Deep within an x86 CPU there are architectural elements that aren't directly reliant on the x86 instruction set to do what they are designed to do. Or to generalise the point: processors that are rather similar from an architectural point of view do in fact support different instruction sets. Notably, Intel CPUs are RISC age processors with a CISC instruction set tacked on for the sake of backward compatibility. Now, good GPU designers who know what it takes to make a good GPU are not thinking about the CPU instruction set that much in developing their design. Their designs are certainly affected by such considerations insofar as the GPU has to be adapted to work with the CPU but those things are not dominating considerations. Probably more thought would go into how software very often designed with a specific family of CPUs in mind will benefit from the GPU. That this is somewhat achievable is pretty amazing.
CiccioB - Tuesday, June 4, 2019 - link
It's quite simple.CPU and GPU work on separate domains relative to instructions and data to process.
All they need to work together is a "bus", that is a communication channel of whatever type, with whatever protocol (of course both HW have to support them) and through this communication channel CPU can send to the GPU the commands and the basic data the GPU needs to start processing the image getting more data autonomously from storage (be it shared RAM or dedicated graphics RAM) like for example textures.
Any CPU can instruct a GPU to run a certain job if you know exacly what the GPU is expecting, where and how and how it communicates back the results of its operations. That's the work of the driver, which translates high level language commands (like those of the above mentioned graphics libraries) into simple list of commands/data (the draw calls) for the GPU.
So in the end you can have CPU X, Y and Z work together with GPU A (for example x86, ARM, Power work with nvidia pascala architecture) exactly as you can have GPU A, B and C work with CPU X (that is GCN, Maxwell, Pascal and Turing work with x86).
It's all based on standards (the type of bus used to comminicate) and the provision of the right drivers (which in PC market are written by AMD and nvidia both to translate standard (or mainstream) graphics library functions into GPU own instruction stream).
Hope it is clear.
Wardrive86 - Monday, June 3, 2019 - link
So what exactly did Qualcomm buy all those years ago if AMD is able to still build smartphone mobile GPUs?brakdoo - Monday, June 3, 2019 - link
They bought the team that built mobile GPUs and they licensed whatever they needed, but now AMD is developing "scalable" architectures with their main team...NixZero - Monday, June 3, 2019 - link
the Imageon team from Ati, their IP plus several licenses enabling them to use OpenGL ES 2.0 and OpenVG 1.0 in their products