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.
Author Archive: gstoner
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:
- 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.
- 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.
- 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:
- C++ and C++AMP Project
- CL Offline Compiler (CLOC) Project and examples
- OKRA Runtime
- HSAIL Assembler and Disassembler
(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, AMD, ARM, Imagination Technologies, MediaTek 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
- Nandini Ramani APU13 Keynote
- Opensource Developer Program
- Visit the HSA Foundation GitHub site to access open source code
- Like the HSA Foundation on Facebook
- Follow the HSA Foundation on Twitter
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.
- C++ AMP Algorithms Library (STL-style Algorithms)
- C++ AMP RNG Library (Random Number Generator)
- C++ AMP FFT Library (Fast Fourier Transform)
- C++ AMP BLAS Library (Basic Linear Algebra Subroutines)
- 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 |
|||||||||||
|
|||||||||||
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.
Heat and power drive architecture decisionsMobile 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. AMP architectures struggle to break into PC/server applicationsWhy don’t AMP architectures dominate PC and server applications? Because it’s hard to implement!
The HSA approach requires a technical framework and architectureThere are several issues that must be addressed to successfully bring these two worlds together:
HSA Foundation provides key tools for unlocking heterogeneous programmingToday, 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 solution stack: Abstracting away hardware specificsTo 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 hardware-specific HSA Finalizer is a key componentA 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.
Benefiting from heterogeneous architectures requires smart schedulingIn 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. Interconnect fabric-assisted scheduling is required to implement scalable HSA systemsExisting 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. ResourcesFor more guidance on heterogeneous system architectures, visit the HSA Foundation or the Arteriswebsites. |
|||||||||||
| Keywords: computer system design, genera | |||||||||||
HSAemeu Full system simulatior for HSA
Great Paper on HSAemu Full system simulator built form PQUEMU to do Full System Emulation of HSA from our Academic Member Yeh-Ching Chung of National Tsing Hua University
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
HSA Presentation at Linaro Conference in Dublin Jul 10, 2013
Presenting on HSA and how it is relevant to ARM Ecosystem at Linaro conference.





