Announcement

Collapse
No announcement yet.

Radeon Open Compute 1.3 Platform Brings Polaris & Other Features

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    No dice. Copied the 4 files to /usr/lib64, created all the necessary symlinks, and still coredumping. Removed 'ocl-icd' too, didn't help .

    Comment


    • #72
      bridgman When will the -pro stack support SI completely?

      Comment


      • #73
        Not sure yet - my guess is early 2017, but we should be picking up the code before that. Should know more in a week or so.
        Test signature

        Comment


        • #74
          OK. Just pasting here the output of gdb:

          Code:
          [Thread debugging using libthread_db enabled]
          Using host libthread_db library "/usr/lib/libthread_db.so.1".
          
          Program received signal SIGSEGV, Segmentation fault.
          0x00007ffff0852d22 in amdgpu_query_gpu_info () from /usr/lib/amdgpu-pro/libdrm_amdgpo.so.1

          Comment


          • #75
            Dammit no edit feature.

            Ran clinfo on dgb. The folder was renamed to 'amdgpu-pro', no interference with mesa's OpenCL at all.

            /usr/lib/amdgpu-pro/libamdocl12cl64.so
            /usr/lib/amdgpu-pro/libdrm_amdgpo.so.1.0.0
            /usr/lib/amdgpu-pro/libamdocl64.so
            /usr/lib/amdgpu-pro/libdrm_amdgpo.so.1
            /usr/lib/amdgpu-pro/libOpenCL.so
            /usr/lib/amdgpu-pro/libOpenCL.so.1
            /usr/lib/amdgpu-pro/libOpenCL.so.1.0.0

            I'm using amdgpu-pro files from version 16.30.3 because I can't download 16.40 for some reason.

            Ran gdb with:
            LD_LIBRARY_PATH=/usr/lib/amdgpu-pro/ gdb
            and
            env LD_LIBRARY_PATH=/usr/lib/amdgpu-pro/ gdb

            Comment


            • #76
              Originally posted by bridgman View Post
              Until we get dGPU support in amdkfd upstreamed (the 1.3 stack is the first to include eviction code, which is a pre-requisite for upstream) the ROC stack is primarily compute-oriented, ie not much testing for graphics.

              HW support is currently Fiji (honkin' fast SP), Hawaii (honkin' fast DP) and Polaris (perf/$, perf/W although Fury Nano has pretty good perf/W as well). Other CIK parts could potentially be supported but SI is a non-starter since the MEC block that HSA/ROC builds on appeared in CIK. At the moment the plan is just to enable ROC on parts which can really benefit from it, basically the list above.
              bridgman, what is the MEC block and why is it important?

              Comment


              • #77
                MEC (MicroEngine Compute) is the HW block that implements ACE (Asynchronous Compute Engine) and HWS (HW Scheduler) functionality. Basically allows compute commands to be submitted independently from graphics and allows multiple compute operations to proceed in parallel, all sharing the common shader core. MEC also uses other CIK-and-up HW features which allow command queues to live in userspace so applications can submit work directly rather than having to make kernel calls for every submission.

                Think of it as ME feeding a graphics pipeline which uses the shader core at multiple points, and MEC feeding a bunch of independent compute pipelines which each use the shader core as well.

                ME and MEC (along with PFP and a few other blocks) are all part of what we refer to as the Command Processor, although it does a lot more than that these days. The CP term started back in Rage 128 days, when added the ability for the driver to insert commands in an in-memory ring buffer and have the GPU fetch them and execute them as needed. I believe ME used to be short for Microcoded Engine (which would make MEC Microcoded Engine (for) Compute) but that was ~17 yrs ago.

                For an intro to what CP does you can look at chapter 5 of the r5xx accel documentation, although back then the ring buffers were only used for graphics (so compute was generally done via fragment shaders):



                Compute shaders were added around Evergreen timeframe IIRC, while compute dispatch commands (working directly on an N-dimensional range rather than having to leverage the graphics pipeline and draw commands) were added later.

                In SI the ME was time-shared between a graphics ring and two compute rings, then in CIK the compute rings were moved to a separate and larger engine, which became MEC.
                Last edited by bridgman; 24 November 2016, 06:32 PM.
                Test signature

                Comment


                • #78
                  Thank you for the detailed description.

                  Comment


                  • #79
                    Originally posted by bridgman View Post
                    Not sure yet - my guess is early 2017, but we should be picking up the code before that. Should know more in a week or so.
                    Any news?

                    Comment


                    • #80
                      There will be be more info going out in the next couple of days.
                      Last edited by bridgman; 07 December 2016, 04:14 PM.
                      Test signature

                      Comment

                      Working...
                      X