HSA FOUNDATION INTELLECTUAL PROPERTY RIGHTS POLICY

HSA FOUNDATION  INTELLECTUAL PROPERTY (“IP”) RIGHTS POLICY
1.         Definitions.  All capitalized terms that are not otherwise defined in this Intellectual Property Rights Policy (“IPRP”) shall have the meaning defined in the Membership Agreement attached hereto.
1.1       “Encumbered Technology” means technology covered by certain patent claims with respect to which a patent holder is unwilling to grant the Reciprocal License.
1.2       “Final Draft Specification(s)” means a final Draft Specification(s) produced by an HSA Foundation working group or committee that will be forwarded to the Board for Ratification and, upon the discretion of the Board, subsequent public release.
1.3       “IP Disclosure Certificate” means a written Notice delivered to the Board of Directors and the chair of any affected working groups or committees that identifies specific Necessary Patent Claims together with a statement as to whether those Necessary Patent Claims will be licensed to all Members in accordance with the Member Agreement. An IP Disclosure Certificate must identify in writing:  (a) the patent holder(s); (b) for each issued patent and published patent application containing a Necessary Patent Claim, and the patent number or publication number, respectively; (c) for a pending unpublished patent application containing a Necessary Patent Claim, and a general description of the technology covered by the application; and (d) reasonable identification of the specific parts of Draft Specification(s) whose implementation may be covered by the Necessary Patent Claims. The IP Disclosure Certificate must contain reasonably sufficient detail so as to enable the HSA Foundation and Members either to exclude the subject inventions from a Draft Specification(s) or to develop a commercially reasonable non-infringing implementation if the corresponding Necessary Patent Claims are not to be licensed under the Member Agreement. An IP Disclosure Certificate may be accompanied by submitting any of the following, in the Member’s sole discretion: (i) Specific License Terms for any Necessary Patent Claims not to be licensed; or (ii) any relevant patent applications in their entirety, including amended and newly added claims, as well as the effective filing date.
1.4       “HSA Foundation Representative” means any employee or contractor of a Member who attends at least one (1) HSA Foundation working group meeting or is otherwise substantially involved in the development of any Draft Specification(s) within the relevant HSA Foundation working group.
1.5       “Managing Director” means the Managing Director of the HSA Foundation.
1.6       “Member” means any Member of the HSA Foundation.
1.7       “Membership Agreement” means the agreement signed by a Member to join the HSA Foundation and to which this Attachment A is attached and incorporated by reference.
1.8       “Notice” means a written notice as defined by the HSA Foundation Membership Agreement.
1.9       “Ratification” means the Board approving a Final Draft Specification(s) for public release as provided in the Bylaws.
1.10     “Reciprocal License” means the license under any Necessary Patent Claims in accordance with the license terms and conditions set forth in the Members’ Member Agreement.
1.11     “Specific License Terms” means a minimal set of terms and conditions that a license must address in order for the HSA Foundation to consider incorporating Encumbered Technology into a Specification(s), provided that the Board has no obligation to accept such license even if it includes all of the Specific License Terms and may withhold such acceptance at its sole discretion. The minimal set of terms and conditions shall include: price (fees and royalties), geographical scope, revocability, whether license is perpetual, definition of licensed patents, scope of license including any restrictions, sublicense conditions (if any), term of license agreement, termination conditions, whether licensor can defensively terminate or suspend license upon suit against them by licensees, and reciprocity. Notwithstanding any of the foregoing, however, in all instances the Specific License Terms shall otherwise be under reasonable and non-discriminatory terms and conditions.
2.              Disclosure of Necessary Patent Claims
2.1.         HSA Foundation Responsibility.  The HSA Foundation shall not be responsible for identifying patent rights for which a license may be required, or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention.
2.2.         No Member Disclosure Necessary. A Member is not required to disclose a Necessary Patent Claim if the Member commits to license such Necessary Patent Claim according to the terms and conditions of the Reciprocal License.
2.3.         IP Disclosure Certificates for Draft Specification(s). If any HSA Foundation Representative of a Member organization has actual knowledge of claims that may be Necessary Patent Claims owned or controlled by that Member with respect to that Member’s Contributions or any other aspect of a Draft Specification(s) that will not be licensed under the Reciprocal License, the HSA Foundation Representative of such Member must submit an IP Disclosure Certificate with the submission of a Contribution or as soon as is reasonably possible. In satisfying the disclosure obligation set forth herein, Members are not required to conduct searches of their patent portfolios, nor are they required to disclose Necessary Patent Claims of other Members or other third party patents.  Each Member shall ensure its HSA Foundation Representative understands the foregoing obligation and shall be responsible for the actions and omissions of its HSA Foundation Representative.
2.4.         Procedure for IP Disclosure Certificates.  The HSA Foundation shall post all received IP Disclosure Certificates on a HSA Foundation website, which is accessible only by Members, promptly after receipt and send an email notification to the Board and all Members.
2.5.         IP Disclosure Binding If a Member proposes Specific License Terms in the IP Disclosure Certificate that are subsequently accepted by the HSA Foundation, and are required by the Final Draft Specification(s), then the Member is irrevocably required to grant a license under such Specific License Terms or under terms and conditions that are materially similar to or better than such Specific License Terms for the Necessary Patent Claims.
2.6.         Confidentiality of IP Disclosure Certificates.  Prior to the date on which a Specification(s) relating to an IP Disclosure Certificate is made public, Members and the HSA Foundation shall not make public the content of any Member’s IP Disclosure Certificate outside of the HSA Foundation. IP Disclosure Certificates received with respect to a particular Draft Specification(s) shall be made public after such Draft Specification(s) has been ratified by the Board.
2.7.         Termination of Disclosure Obligations.  The disclosure obligations described in this Section 2 for a Draft Specification(s) terminate upon Ratification of the Draft Specification(s) by the HSA Foundation or when a working group or the HSA Foundation formally indicates in writing that work on the Draft Specification(s) has terminated without Ratification by the HSA Foundation.
2.8.         No Notice.  Each Member agrees that receipt of IP Disclosure Certificates by any Member shall not be deemed to be notice of any patent listed therein for purposes of damages or willfulness.
3.              Ratification Periods.
3.1.         Notice of Ratification Period.  Promptly upon a working group’s or committee’s issuance of a Final Draft Specification(s), the working group chair shall request that the Board issue a Notice of Ratification Period to all Members notifying that an announced period of time not shorter than fourteen (14) days and not to exceed sixty (60) days (the “Ratification Period”) has commenced. The Notice of Ratification Period shall clearly indicate the location of the Final Draft Specification(s) on the HSA Foundation web-site and the deadline for the receipt of any IP Disclosure Certificates from any Member. At the end of the Ratification Period, the Board will vote for Ratification of the Final Draft or establish an IP Committee as defined below.
3.2.         Failure to Submit IP Disclosure Certificate.  If a Member fails to submit an IP Disclosure Certificate prior to the expiration of an applicable Ratification Period, the Member shall be deemed to have granted the Reciprocal License for that Final Draft Specification(s).
4.              Reciprocal License Certificate.  At any time during the creation of a Draft Specification(s) or during the Ratification Period for a Final Draft Specification(s), any Member may choose to issue an IP Disclosure Certificate accompanied by a signed certificate (“Reciprocal License Certificate”) certifying Member’s grant of the Reciprocal License for disclosed Necessary Patent Claims for, or expected to be for, a Final Draft. A Reciprocal License Certificate may be accompanied by, in the Member’s sole discretion, the results of any searches conducted by the Member of the Member’s IP, or any publicly available prior art. As an example, a Member may choose to issue a Reciprocal License Certificate for a Contribution that it wishes to see incorporated into a Draft Specification(s) to assist the working group in deciding whether to incorporate that Contribution, but is not required to do so.
5.              Existing Specification(s).
5.1.         New Member Reciprocal License Grant.  By signing and submitting a Membership Agreement, a new Member agrees to grant a Reciprocal License for all Specification(s) as of the joining date of the Member, unless, within sixty (60) days of the submission of the Agreement, the Member submits IP Disclosure Certificates as set forth herein.
5.2.         Member Patent Purchase.  An existing Member purchasing a patent agrees to grant the Reciprocal License for all Specification(s), unless, within sixty (60) days after purchase of the patent the Member submits an IP Disclosure Certificate as set forth herein, which excludes the obligation to grant a Reciprocal License for the patent. After such period any non-excluded Necessary Patent Claims that shall be deemed to be licensed under the Reciprocal License.
6.              Member Initiated Disclosure Request.
6.1.         Member Request.  A Member may, in good faith, request in writing that the Managing Director issue a written request from the Board delivered to another Member requesting that the other Member issue an IP Disclosure Certificate for specific patent or patents owned or controlled by that Member relevant to a Draft Specification(s) being discussed in a working group (“Disclosure Request”). For clarification, the Disclosure Request must specifically identify the respective patent or patents by providing the corresponding patent numbers. Further, the number of patents included in any Disclosure Request must be reasonable, and the Board shall act in good faith when issuing any particular Disclosure Request or combination of Disclosure Requests. A Disclosure Request is subject to approval by the Board. If approved, the Disclosure Request shall be sent as a Notice by the Managing Director on behalf of the HSA Foundation to the applicable Member and shall include the HSA Foundation’ reasons for making the request, the Draft Specification(s) in question, and any relevant meeting minutes and other documents.
6.2.         IP Disclosure Certificate in Response to a Disclosure Request.  Any HSA Foundation Representative in a Member organization who has received from the Managing Director a Disclosure Request with respect to a Draft Specification(s), or any person in a Member organization who has received, either directly or indirectly, a Disclosure Request from a HSA Foundation Representative of that Member organization; and who has actual knowledge of claims included in the patent or patents specifically identified in the Disclosure Request that are Necessary Patent Claims of that Member organization must issue an IP Disclosure Certificate in accordance with this policy as soon as reasonably possible after receipt of a Disclosure Request.
6.3.         Failure to Comply to a Disclosure Request.  A Member who does not comply with the disclosure obligations set forth in this section automatically grants the Reciprocal License for any Necessary Patent Claim(s) that the Member failed to disclose. Any attempt to exclude any such undisclosed Necessary Patent Claim(s) is ineffective and null and void.
7.              Withdrawal. 
7.1.         No Withdrawal.  Contributions, once accepted by the HSA Foundation, may not be withdrawn and a Reciprocal License granted thereto.  For clarification and as more clearly set forth in the definition of “Contribution,” a submission that is withdrawn from the Working Group within ten (10) business days of said initial submission shall not be deemed a “Contribution.”
7.2.         Survival of License.  A Member’s obligations to license made prior to withdrawal from the HSA Foundation shall survive such withdrawal, and shall extend to all licensees, including Members that join the HSA Foundation after the withdrawing Member’s withdrawal.
7.3.         Exclusion upon Withdrawal.  If a Member withdraws from the HSA Foundation prior to the expiration of an applicable Ratification Period, then the Member may exclude patents that the Member is not already obligated to license before the expiration of an applicable Ratification Period. Failure to exclude will result in the former Member granting the Reciprocal License. Upon withdrawal from the HSA Foundation, the Member may submit at any time any and all IP Disclosure Certificates that the Member chooses to submit pursuant to the foregoing clause of this Section 7, without the obligation to wait until a Ratification Period is defined by the HSA Foundation with respect to any particular Draft Specification(s).
7.4.         Rights after Withdrawal.  Except as explicitly described in this Attachment A, a prior Member shall have no other obligations to the HSA Foundation or to Members as to technologies or IP rights developed by the Member after its withdrawal from the HSA Foundation.
8.              Third Party Technology.  Nothing in the Membership Agreement shall compel nor prevent the HSA Foundation from including in Draft Specification(s) or Specification(s) a reference to, or suggestion to adopt or employ, a non-Member technology, whether or not such third party technology must be licensed on a royalty-bearing or royalty-free basis in order to avoid infringement or intellectual and/or proprietary rights, provided that said non-Member technology shall not be required to implement the Specification if it is not licensed on a royalty-free basis.

HSA System Architecture, HSA Programer Reference Manual, HSA System Runtime Specifications 1.0 Provisional are Now Available

 The three core HSA Foundation specifications are available for public review.  Also in addition a sample runtime, compiler, and driver are available for to interact for your review of the specifications.

HSA Foundation recently ratified and released  the three main HSA specifications:

  1. HSA Platform System Architecture Specification: Defines the requirements for shared virtual memory, platform coherency, signaling, queuing mechanics and packet formats, context switching, and the HSA memory model.
  2. HSA Programmer’s Reference Manual: Contains the HSAIL Virtual ISA and Programming Model, Compiler Writer’s Guide, and BRIG (the “HSAIL” compiler intermediate language) object format.
  3. HSA Runtime Programmer’s Reference Manual: Defines the APIs in the HSA Runtime used for tasks cuh as initialization and device discovery, queue creation, and memory management. These specifications are at the “1.0 Provisional” Level and are available from the HSA Foundation web site here (http://www.hsafoundation.com/standards/).

AMD is also supplying early implementation to test out capabilities of HSA

The project provides an initial implementation of the HSA specifications on the AMD “Kaveri” silicon a pre-HSA Compatible part. The implementation includes a Linux kernel and associated kernel-level drivers, the HSA runtime, and the HSAIL finalizer. The project includes a reference LLVM-based compiler which generates HSAIL and can extended to add additional languages that support HSAIL-based compute. The project also includes tools for assembling and disassembling HSAIL and for compiling OpenCL 2.0  kernels into HSAIL. Finally, the project includes an approachable runtime layer called “OKRA” designed to minimize the time required to get started with HSA.  You can access these at https://github.com/HSAFoundation

Who should use this project?

The project is aimed at:

  • Compiler and language developers who want to add parallel acceleration to a high-level language.
  • Programmers who want to leverage features of HSA such as shared-virtual-memory, platform atomics, user-level queues, and signals.

Next steps:

For an overall view of the different components of the project, see the list here.
For information regarding target platforms and installation instructions for the HSA drivers and user-mode libraries, see “HSA Platforms & Installation”.
Compiler and programming language developers should investigate the HSAIL Compiler Writers SDK.
Programmers interested in developing code that uses HSA features should investigate these projects:

(1) OpenCL and the OpenCL logo are trademarks of Apple, Inc. and used by permission of Khronos.

AMD Announces Heterogeneous C++ AMP Language for Developers

First Open Source C++ Implementation to See Broad Availability Across Linux, Windows and Other Platforms
SUNNYVALE, CA, Aug 26, 2014 (Marketwired via COMTEX) — AMD AMD, +0.48% in collaboration with Microsoft(R) MSFT, -0.28% today announced the release of C++ AMP version 1.2 — an open source C++ compiler which implements version 1.2 of the open specification for C++ AMP, available on both Linux and Windows for the first time. The release represents another step forward toward AMD’s goal of supporting cross-platform solutions, multiple programming languages and continued contributions to the open source community. The tool, which leverages Clang and LLVM, accelerates productivity and ease of use for developers wishing to harness the full power of modern heterogeneous platforms spanning servers, PCs and handheld devices.
“AMD has a consistent track record of enriching the developer experience, and we’re proud to make the first open source implementation of C++ AMP available to enable greater performance and more power-efficient applications,” said Manju Hegde, corporate vice president, Heterogeneous Applications and Solutions, AMD. “The cross-platform release is another step in strengthening AMD’s developer solutions, allowing for increased productivity and accelerated applications through shared physical memory across the CPU and GPU on both Linux and Windows.”
“AMD continues to deliver excellent developer tools for heterogeneous programming. Partnering with AMD to deliver C++ AMP to the Linux and Open Source communities was a natural step for Microsoft as we work to improve the performance and developer experience on modern computing platforms,” said S. Somasegar, corporate vice president of the Developer Division at Microsoft.
C++ AMP version 1.2 enables C++ developers to accelerate applications across a broad set of hardware and software configurations by supporting three outputs:
— Khronos Group OpenCL(1), supporting AMD CPU/APU/GPU, Intel CPU/APU, NVIDIA GPU, Apple Mac OS X and other OpenCL compliant platforms; — Khronos Group SPIR, supporting AMD CPU/APU/GPU, Intel CPU/APU and future SPIR compliant platforms; and — HSA Foundation HSAIL, supporting AMD APU and future HSA compliant platforms.
Akey performance feature of version 1.2 of the open source C++ AMP specification is support for shared physical memory, which greatly simplifies sharing of data between the CPU and GPU on heterogeneous platforms. Heterogeneous platforms built on the new spec allow programmers to benefit from minimized overhead of expensive data copies and pointer updates when accelerating applications.
Supporting Resources
— Access latest C++ AMP compiler source code here — View the Open C++ AMP specification version 1.2 here — For more information about Clang and LLVM, visit their website.
About AMD AMD AMD, +0.48% designs and integrates technology that powers millions of intelligent devices, including personal computers, tablets, game consoles and cloud servers that define the new era of surround computing. AMD solutions enable people everywhere to realize the full potential of their favorite devices and applications to push the boundaries of what is possible. For more information, visit www.amd.com.
(1) OpenCL and the OpenCL logo are trademarks of Apple, Inc. and used by permission of Khronos.
Contact: Kristen Lisa AMD Public Relations (512) 602-6020 kristen.lisa@amd.com
SOURCE: Advanced Micro Devices

Tech Giants and Leading National Labs join the HSA Foundation

 

NEWS RELEASE

 

Contact:

Morgan Frikie

HSA Foundation

512-237-7064

pr@hsafoundation.com

 

Tech Giants and Leading National Labs join the HSA Foundation

Oracle, Broadcom, Oak Ridge National Laboratory and Huawei are among industry-leading organizations recently joining the HSA Foundation to advance open standards for heterogeneous compute programming

 

Open Source Developer Program launched to drive greater developer productivity in heterogeneous computing

 

SAN JOSE, Calif. — Nov. 12, 2013 The HSA Foundation today announced at the 2013 AMD Developer Summit, “APU13”, the addition of new members spanning Fortune 500 technology giants, software innovators, high-tech silicon suppliers and the world’s most forefront research institutions. Backed by founder members, AMDARMImagination TechnologiesMediaTek Inc., Qualcomm, Samsung Electronics and Texas Instruments (TI), the HSA Foundation is dedicated to developing open-standard architecture specifications that unlock the performance and power efficiency of the parallel computing engines found in most modern devices.
“Joining the HSA Foundation represents the next step towards bringing heterogeneous computing to millions of developers, as well as the introduction of new server and cloud programming paradigms,” said Nandini Ramani, vice president of development, Java Platform, Oracle. “Our work with the HSA Foundation will help provide Java developers with the ability to quickly leverage GPU acceleration, and explore how the Java Virtual Machine (JVM), as well as the Java language and APIs, might be enhanced to allow applications to take advantage of heterogeneous compute.”
“In less than six months, more than a dozen of the industry’s elite have pledged their support to driving the HSA standard forward,” said Phil Rogers, president, HSA Foundation. “The rapid adoption of HSA and the development of the Foundation’s open ecosystem will help usher in the next era unprecedented user experiences to improving cloud-based data management, streaming, and security.”
As an independent consortium, the HSA Foundation is open to any computing industry professionals with an interest in driving the next era in computing performance and energy efficiency.  Members will assist with research, development, production, manufacture, use, and the sale of HSA and heterogeneous computing software. The latest members to join the HSA Foundation include:

  • Broadcom
  • Canonical Limited
  • Electronics and Telecommunications Research Institute (ETRI)
  • Huawei
  • Industrial Technology Res. Institute
  • Kishonti
  • Lawrence Livermore National Laboratory
  • Linaro
  • Oak Ridge National Laboratory
  • Oracle
  • Synopsys
  • TEI of Crete
  • UChicago Argonne, LLC. Operator of Argonne National Laboratory
  • VIA Technologies

 
Also announced today is the formation of the HSA Foundation Open Source Developer Program.  The new program will help drive greater developer productivity in heterogeneous computing by removing many of the barriers of traditional heterogeneous programming and enabling developers to focus on their algorithms and not managing system resources. Specifically, the program will focus on three key areas:

  • Development of core tools, runtimes and simulators that allow developers to access HSA technologies
  • Provide documentation and tools to help accelerate the development of applications on top of HSAF runtimes technologies
  • Give developers a place to contribute to the development of the open source HSA tools and runtimes

         Through the Open Source Developer Program, engaging the HSA Foundation and all the technologies that encompass the HSA specifications is now easier and more effective.  Parties interested in exploring and contributing to HSA can use the HSA Foundation Open Source Developer Program resources. Anyone can join the mailing lists, ask questions, contribute patches, report bugs, look at submitted patches, and use the tools.
 
Supporting Resources

 
About The HSA Foundation
The HSA (Heterogeneous System Architecture) Foundation is a not-for-profit consortium of  SoC IP vendors, OEMs, academia, SoC vendors, OSVs and ISVs whose challenging the normal of how whole system architecture is structured for combing CPU’s, GPU’s, DSP’s, and other accelerators to bring about forward progress in computing’s foundation to make it dramatically easier to program heterogeneous parallel devices. HSA Foundation is driving this via Royalty Free Specifications and open source software: HSA runtimes and low level compilation tools based on open source technologies like LLVM and GCC.
HSA Foundation members are building a heterogeneous compute software ecosystem which is rooted on open royalty free industry standards. We are looking to bring about applications that blend scalar processing on the CPU, parallel processing on the GPU, and optimized processing of DSP via high bandwidth shared memory access with greater application performance at low power consumption. HSA Foundation is defining key interfaces and  for parallel computation utilizing CPU, GPU,  DSP’s and other programmable and fixed function devices, which will support a diverse set of high-level programming languages creating the next foundation in general purpose computing. Most importantly we are driving to bring greater developer productivity to heterogeneous computing by removing many of the barriers of traditional heterogeneous programing so they can focus on their algorithms and not managing system resources.   One of the key attributes of Cache Coherent Shared Virtual Memory (“CC-SVM”) is begin looking at larger dataset then traditionally supported by today co-processor devices with fixed memory pools. For more information, visit www.hsafoundation.com.

Bringing C++AMP Beyond Windows via CLANG and LLVM

We are happy to report after some great work of MultiCoreWare in conduction with support from AMD and Microsoft today we are releasing a  C++ AMP compiler based on CLANG/LLVM so we can bring C++ AMP  to multiple platforms.  We want to bring this out early so we could work with the community to make sure we get there input prior to make this 1.0.  So we calling all developers who are looking for heterogeneous C++ compiler to help with finding bug, driving feature, creating optimization as well building applications and libraries drive new class of applications.
You can get access to the compiler at the Bitbucket repository link:
https://bitbucket.org/multicoreware/cppamp-driver/
We also have Samples:
https://bitbucket.org/multicoreware/cxxamp_sandbox
FEATURES:
* Compiles C++AMP to OpenCL C  and Khronos Group Provisional SPIR 1.2 for Linux. Works across major GPU platforms.
* Leverages GMAC for CPU-GPU synchronization on non-HSA GPUs.
TODOs/Ongoing works:
* Fix SPIR code generation issue. Right now system headers do not flow thru SPIR path and that causes host code to fail compilation.
* HSAIL code generation and HSA-optimized layout
* Passing MS C++AMP conformance suite
* Async API
* Better address space support — right now small changes to user code are required when taking/passing a pointer to local memory buffers. See samples for details.
* Merge into official Clang main line
 
Remember C++ AMP already has rich set of libraries which Microsoft has released under Apache License.

  1. C++ AMP Algorithms Library (STL-style Algorithms)
  2. C++ AMP RNG Library (Random Number Generator)
  3. C++ AMP FFT Library (Fast Fourier Transform)
  4. C++ AMP BLAS Library (Basic Linear Algebra Subroutines)
  5. C++ AMP LAPACK Library (Linear Algebra Package)

Asymmetric Multiprocessing with Heterogeneous Architectures: Use the Best Tool for the Job

Asymmetric Multiprocessing with Heterogeneous Architectures: Use the Best Tool for the Job   Featured
Contributor: Arteris SA
 Printer friendly
 E-Mail Item URL

September 6,2013 — Often, the term “multiprocessing” is associated with tightly-coupled symmetric multiprocessing (SMP) architectures, due in large part to SMP’s prevalence in high-performance computing, x86/x64 servers, and PCs. Unfortunately, SMP’s incremental performance scaling for most applications decreases significantly with increasing numbers of cores. This lack of scalability has prompted many processor companies to avoid purely SMP solutions for their mobile and consumer electronics applications. Instead, they have implemented asymmetric multiprocessing (AMP) architectures to make more efficient use of silicon.An example of AMP is a mobile phone’s modem baseband SOC, containing an ARM processor and a DSP to handle control and signal processing, respectively. AMP architectures are also found in mobile phone application processors, which have multiple CPU cores and separate discrete graphics cores, video cores, audio cores and imaging cores. Heterogeneous architectures also dominate in most embedded consumer applications, such as digital TVs, set-top boxes, and automotive infotainment.
 
 

Figure 1. The Qualcomm Snapdragon 800 is an example of system-on-chip that implements an asymmetric processing (AMP) architecture with multiple processing units optimized for different functions. Source: Qualcomm.

 

Heat and power drive architecture decisions

Mobile applications face significant design constraints because of battery size and heat dissipation. As a result, processor designers are forced to use “the best core for the job.” So architectures in mobility have always been created from a baseline expectation of heterogeneous core AMP.
Server and PC chips have relatively unlimited power consumption and heat dissipation capabilities, making an SMP architecture tolerable. In these applications, it is often easier to add more cores of the same type, connect them using cache coherency, and reuse the legacy software to run on top. Comparatively little attention has been paid to heat dissipation and power consumption.
But PCs are becoming smaller and mobile. And server farms are eyeing power consumption as well, forcing designers to reconsider SMP architectures. For example, for server farms that power the likes of Google and Facebook, power consumption and heat dissipation have become huge cost and environmental issues. And in the PC space, we have run into a “gigahertz wall” where the only way to have a step function increase in performance is to have different cores optimized for different workload types.

AMP architectures struggle to break into PC/server applications

Why don’t AMP architectures dominate PC and server applications? Because it’s hard to implement!
In mobile designs, each heterogeneous processing core, whether graphics, audio, DSP, etc., typically has a custom firmware and software stack associated with it. This software must be integrated to communicate with the CPU cores’ operating system, requiring coding work in the OS hardware abstraction layer and drivers. In addition, these heterogeneous cores do not have a single view of system memory, so complicated synchronization schemes are usually implemented in hardware and software. Context switching and preemption are difficult to implement. Adding to the challenge, each of these cores requires an expert programmer, conversant in a particular core’s instruction set and tool chains, to code it.
These barriers have forced AMP to remain in the mobile and consumer electronics realm, which is closed to low-level, close-to-the-hardware software developers. Alternatively, SMP has flourished in the wide-open world of PCs and servers, aided by the ease of programming.
Heterogeneous system architectures (HSA) can span the chasm between mobile/ consumer applications and PC/ server applications, easing the design burden while delivering performance, scalability, improved heat dissipation and reduced power consumption.
Recently, a number of companies, including AMD, ARM, Imagination, MediaTek, Qualcomm, Samsung and Texas Instruments, founded the HSA Foundation. HSA defines interfaces for parallel computation utilizing CPU, GPU, and other programmable and fixed-function devices, and support for a diverse set of high-level programming languages, thereby creating the next foundation in general-purpose computing.
Its goals are to:

  • Make heterogeneous programming easy and a first-class pervasive complement to CPU computing.
  • Continue to increase the power efficiency of heterogeneous systems (AMP), keeping it the platform of choice from smartphones to the cloud.
  • Bring to market strong development solutions (tools, libraries, OS run-times) to drive innovative advanced content and applications.
  • Foster growth of heterogeneous computing talent through HSA developer training and academic programs to drive both learning and innovation.

The HSA approach requires a technical framework and architecture

There are several issues that must be addressed to successfully bring these two worlds together:

  • Unified programming model – Today, CPU and GPU (or other accelerator) cores are programmed separately, with the accelerator treated as a remote processor. To make the maximum use of hardware resources while balancing ease of programming, heterogeneous architectures should allow developers to target the CPU or GPU by writing in task-parallel languages, like the ones they use today when writing for multicore CPUs.
  • Unified address space – HSA supports virtual address translation amongst the heterogeneous cores with an HSA-specific memory management unit (HMMU). HSA compute engines will use the same pageable virtual address space as used by CPUs today.
  • Queuing – CPUs, GPUs and other cores can queue tasks to each other and to themselves through an HSA run-time. Queuing can be managed in hardware to avoid OS system calls and enable very low latency communication between cores.
  • Preemption and context switching – HSA enables job preemption, job scheduling and fault handling capabilities to overcome potential problems created by rogue or faulted processes.

HSA Foundation provides key tools for unlocking heterogeneous programming

Today, CPUs and GPUs do not share a common view of system memory, requiring an application to explicitly copy data between the two devices. In addition, an application running on the CPU that wants to add work to the GPU’s queue must execute system calls that communicate through the CPU operating system’s device driver stack, and then communicate with a separate scheduler that manages the GPU’s work. This adds significant run-time latency, in addition to being very difficult to program.
HSA addresses the need for easy software programming of GPUs to take advantage of their unique capability to crunch parallel workloads much more efficiently than x86 or ARM CPUs.

HSA solution stack: Abstracting away hardware specifics

To enable easier programming, HSA allows developers to program at a higher abstraction level using mainstream programming languages and additional libraries. This HSA solution stack includes several components.
The key to enabling one language for heterogeneous core programming is to have an intermediate run-time layer that abstracts hardware specifics away from the software developer, leaving the hardware-specific coding to be done once by the hardware vendor or IP provider. The core of this intermediate layer is the HSA Intermediate Language or “HSAIL.”
 
 

Figure 2. The HSA Intermediate Language (HSAIL) is an intermediate run-time layer that abstracts hardware specifics away from the software developer. Source: AMD.

 
The HSA run-time stack is created by compiling a high-level language such as C++ with the HSA compilation stack. HSA’s compilation stack is based on the LLVM infrastructure, which is also used inOpenCL from the Khronos Group.
Creation of HSAIL can occur prior to run-time or during run-time. Here are two examples: The OpenCL run-time includes the compiler stack and is called at run-time to execute a program that is already in data-parallel form. Alternatively, Microsoft’s C++ AMP (C++ Accelerated Massive Parallelism) uses the compiler stack during program compilation rather than execution. The C++ AMP compiler extracts data-parallel code sections and runs them through the HSA compiler stack, and passes non-parallel code through the normal compilation path.
Figure 3 shows the HSA compilation stack, where programming code is compiled into HSAIL using the LLVM compilation infrastructure:
 
 

Figure 3. The HSA compilation stack creates the HSA Intermediate Language (HSAIL) prior to or during run-time. Source: AMD.

 

The hardware-specific HSA Finalizer is a key component

A key role is played by the hardware-specific “finalizer” which converts HSAIL to the computing unit’s native instruction set. Hardware and IP vendors are responsible for creating finalizers that support their hardware. The finalizer is lightweight and can be run at compile time, installation time or run-time depending on requirements.
Figure 4 shows the HSAIL and its path through the HSA run-time stack:
 
 

Figure 4. The hardware-specific components of the HSA run-time stack are the HSA Finalizer and the hardware driver. Source: AMD.

 
The HSA Finalizer is the point at which the specifics of different heterogeneous computing units are addressed. Initial HSA implementations will most likely support GPU compute with finalizers from GPU vendors such as AMD, Imagination, ARM, and Qualcomm. The quality and features of each vendor’s HSA Finalizer will help determine how software developers take advantage of each hardware element’s computing capabilities.

Benefiting from heterogeneous architectures requires smart scheduling

In addition to GPUs, many existing heterogeneous architectures have additional discrete processing units for functions such as audio (digital signal processing or stream processing), image and video processing (SIMD frame processing), and security. As HSA matures, hardware and IP vendors creating these processing units may want to enable HSA programmability on their hardware by creating hardware-specific finalizers.
Having multiple heterogeneous processing units will complicate workload scheduling from a system perspective. The harsh reality is that existing workload scheduling and OS scheduling algorithms are relatively simple and generally only take into account local activity on a processing unit or a cluster of homogeneous processing units (see the Linux Completely Fair Scheduler for one example of how scheduling is implemented: ).

Interconnect fabric-assisted scheduling is required to implement scalable HSA systems

Existing OS and middleware scheduling algorithms do not take into account the existing traffic throughout the system, nor a view into other processing units. This lack of a global perspective for scheduling virtually guarantees there will be contention and stalling as processing units wait for access to precious system resources, especially the DRAM. It’s like looking out the front door of your house to determine how bad the traffic will be on your commute to work: You are missing very relevant information that could help you determine the optimal route to take.
Probing current run-time data flows at critical points throughout a system’s SOC interconnect fabric can provide critical information to enhance workload scheduling. This information can then be used to assign priorities to workloads, and workloads to processing units. These priorities and assignments can be optimized based on performance requirements or power consumption requirements, as required for a particular use case. As heterogeneous processing becomes the norm, and more processing units are added to a system, this type of interconnect-assisted scheduling will be required.
In other words, the hardware interconnect is a key enabler to putting the heterogeneous into HSA.

Resources

For more guidance on heterogeneous system architectures, visit the HSA Foundation or the Arteriswebsites.
Heterogeneous System Architecture: A Technical Review” whitepaper by George Kyriazis, (AMD), HSA Foundation, August, 2012.
The HSA Compilation and Run-time Stack diagrams are from the whitepaper by George Kyriazis cited above.
 

By Kurt Shuler
Kurt Shuler is Vice President of Marketing, Arteris, Inc.
 
Go to the Arteris SA website to learn more.
http://www.soccentral.com/results.asp?EntryID=41133

Keywords: computer system design, genera

HOT CHIPS 2013- HSA Foundation Presented Deeper Detail on HSA and HSAIL

 

Wanting to find out more about HSA,  at Hot Chips 2013, Phil Rogers ( AMD) , Ben Gaster ( Qualcomm),  Ian Bratt ( ARM), and Ben Sander ( AMD)presented on HSA, HSA Memory Model, HSA Queueing Model and HSAIL this last Sunday.  We now have the presentations posted in our developer publications page (http://107.170.238.52/publications/)  and media presentations (http://107.170.238.52/pubs-presos/)  as well as on HSA Foundation Slideshare. (http://www.slideshare.net/hsafoundation)

Dig into the material and see if you want join the exciting future of HSA enabled devices.

[one_half]

[/one_half][one_half_last]

[/one_half_last][one_half]

[/one_half][one_half_last]

[/one_half_last]

HSAIL: Write-Once-Run-Everywhere for Heterogeneous Systems – IEEE article

Ben Sander of AMD and  Chien-Ping Lu MediaTek HSA Foundation Working group leader for HSA Programer Reference Manual pen a nice article on HSAIL and HSA technology
 
“Power efficiency has emerged as a primary design goal for modern silicon chips.  Accelerators such as GPUs have well-known advantages in compute density per-watt and per-mm^2 – note for example that the systems at the top of the latest Green500 (http://www.green500.org/) and Top500 (http://www.top500.org/) lists are now based on heterogeneous designs.
However, these systems have traditionally been difficult to program, due to two challenges.  First, many accelerators support only dedicated address spaces that require cumbersome copy operations and prevent the use of pointer-based data structures on both the accelerator and the host processor.   Second, accelerator programming has traditionally required a specialized language such as OpenCL™ or CUDA™.  Some of these specialized languages are only supported by a single hardware vendor, which further constrains their adoption.
An intermediate language called HSAIL is helping to address some of the challenges. One of the benefits of HSAIL is its portability across multiple vendor products.  Compilers that generate HSAIL can be assured that the resulting code will be able to run on a wide variety of target platforms. HSAIL also provides existing programming languages with an efficient parallel intermediate language that runs on a wide variety of hardware.  This provides the underlying infrastructure and brings the benefits of heterogeneous computing to existing, popular programming models such as Java™, OpenMP™, C++, and more”. ………..  read more at this link bellow
http://www.computer.org/portal/web/computingnow/software%20engineering/content?g=53319&type=article&urlTitle=hsail%3A-write-once-run-everywhere-for-heterogenous-systems