6 Replies Latest reply on Apr 13, 2015 9:18 AM by jedwards

    HSA/huma under Linux

    atcl

      I would like to ask if the whole system RAM is available for hUMA or only the amount that is considered "shared memory", which in case of Kaveri was limited to 2GB for many boards?

       

      Furthermore, what will be the requirements of the driver stack for Carrizo under linux? I would guess something like "amdgpu" (?!) + "amdkfd" + "AMD app sdk" (libopencl), or will Catalyst be required?

        • Re: HSA/huma under Linux
          jedwards

          Applications using the 64 bit HSA runtime on a 64 bit operating system will be able to utilize all available system RAM for hUMA. I do not know of a 2 GB limitation on Kaveri platforms, unless the environment was using the 32 bit runtime.

           

          On Carrizo, a pure HSA application will utilize the following AMD software components on Linux:

           

          HSA-Drivers-Linux-AMD: HSAFoundation/HSA-Drivers-Linux-AMD · GitHub

          HSA-Runtime-AMD: HSAFoundation/HSA-Runtime-AMD · GitHub

           

          All other components are available to support higher level programming models, such as C++ AMP, Python, etc. OpenCL is considered a higher level programming model and is not required. The Catalyst driver set is not required.

          1 of 1 people found this helpful
            • Re: HSA/huma under Linux
              atcl

              Thanks, this almost answers my questions. It is good to know the hUMA capabilitites are independent from the shared VRAM memory amount. Also, I appreciate the open source availability of the HSA stack; a good decision on AMDs part. Will these enter into the linux kernel?

               

              I would like to follow up with which drivers / libs / packages are required for OpenCL ?

               

              Thanks again.

                • Re: HSA/huma under Linux
                  jedwards

                  It is expected that the HSA driver components will be up-streamed into the Linux kernel in the future. Supporting this up-streaming was one of the main reasons for open sourcing the driver and runtime code.

                   

                  At this time, AMD's implementation of the OpenCL programming model is not officially supported on HSA, so I cannot provide a of list libraries or packages that will provide HSA support for OpenCL. However, AMD's OpenCL implementation does take advantage of APU hardware; it just uses proprietary interfaces and code that will not be available as open source. If you wish to obtain the proprietary stack visit this link: http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/

                  1 of 1 people found this helpful
                    • Re: HSA/huma under Linux
                      atcl

                      I am still a little confused. I thought the ACML6 is using an OpenCL backend (clBLAS) that utilizes hUMA, am I wrong?

                        • Re: HSA/huma under Linux
                          jedwards

                          AMD's 2.0 implementation of OpenCL exposes SVM (shared virtual memory), which is what you are talking about. On certain platforms AMD's OpenCL implementation has adopted HSA technologies to facilitate functionality. I believe this is the case for OpenCL on AMDs APU platforms which may implement SVM on top of hUMA technology. I suggest asking about hUMA and HSA support on APUs in the OpenCL forum.

                           

                          An OpenCL implementation taking advantage of full HSA support is currently not available, however.

                    • Re: HSA/huma under Linux
                      bridgman

                      Just to add a bit more detail here -- the kernel images in the HSA-Drivers-Linux-AMD github project use the radeon kernel driver to support Kaveri, but future images will also include the amdgpu kernel driver for Carrizo.

                       

                      In addition to the kernel images, we are also pushing all the kernel driver code (amdkfd, radeon changes, amdgpu) upstream so there will be a gradual transition from the binary-centric releases we have today to an upstream-centric approach; hoping to finish that transition by the end of CY 2015.