Announcement

Collapse
No announcement yet.

amdgpu questions

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

  • #31
    Originally posted by bridgman View Post
    Yes, part of the hybrid driver. The Vulkan userspace driver hooks in the same way as, say, OpenGL - command submission & resource management via the kernel driver, windowing interface via (not sure, haven't been keeping up on the details). The Vulkan userspace driver is the same for Linux & Windows, although the interface to kernel driver and windowing is obviously different.
    Does the Vulkan driver need to wait for the new hybrid driver to be released? Perhaps the Vulkan driver only depends on the opensource parts and I think all the opensource parts are pretty much done, right?
    Could you run Vulkan + MesaGL and Vulkan + NewGL as you wish?

    Comment


    • #32
      I can answer that for you (as bridgman already did before )
      Look on page 2, esp. posts #16 and #18.
      'Problem' is that they share the same code for the Vulkan drivers on both Windows and Linux. There is not everything OS-specific completely hidden behind abstraction layers yet and they're obviously not allowed to expose OS-specific internals for Windows. That's why there is this transition phase

      Comment


      • #33
        I think ernstp might have been asking a slightly different question - whether the Vulkan driver could be released to run over the open source stack rather than the hybrid stack. Quick answer is "not yet AFAIK".

        Comment


        • #34
          Originally posted by bridgman View Post
          Radeon Open Compute
          What is that supposed to be?
          Is ROC replacing OpenCL? Is that why you will open up OpenCL code?
          Is HIP replacing OpenCL?
          Is HSA for dedicated GPUs available? What else is amdkfd for?

          Comment


          • #35
            Radeon Open Compute is the "branding" for our HSA stack. It runs a bit ahead of HSA standards - as we find things are needed we implement them and propose them to HSAF in parallel. It doesn't replace OpenCL, but it probably will replace the lower level code that OpenCL runs over today.

            HCC is another language available alongside OpenCL, and is already open source.

            HIP is a porting tool that helps to convert CUDA to portable C++ which can run over HCC or NVCC (and maybe over Intel's new stack as well, not sure). Basically it's about C++ parallel extensions evolving far enough to be a good portable standard for GPU compute, and helping people move their existing programs to it.

            The HSA/ROC stack is now running on dGPUs as well, initially focusing on Fiji.

            Comment


            • #36
              so ROCK = amdkfd?
              What is the advantage of using roc instead of OpenCL, the platform/vendor-independent solution with a dGPU?

              Comment


              • #37
                Originally posted by monraaf View Post
                so ROCK = amdkfd?
                What is the advantage of using roc instead of OpenCL, the platform/vendor-independent solution with a dGPU?
                Correct...

                ROCK = Radeon Open Compute Kernel driver,
                ROCT = ROC Thunk
                ROCR = ROC Runtime
                ROCM = ROC platforM (I had to ask about that one)

                ROCM isn't an alternative to OpenCL itself, it's an alternative to what OpenCL runs over today. Actually OpenCL has picked up part of the stack already, in the sense that it compiles OpenCL kernels to HSAIL rather than AMDIL, but next step would be to run it over the ROC stack rather than over the graphics driver like we do today. We already do this for testing.

                Think "optimized compute stack with a bunch of languages running over it". The design exercise started as "what would be the ideal low level stack for OpenCL 2.0 ?" then we generalized to support other languages equally well. OpenCL 2.0 is a fairly different beast from earlier versions, in the sense that earlier versions were limited to things that could run well over a typical graphics driver of the time.

                Comment


                • #38
                  Topaz/Iceland has been a mystery for me... from amdgpu source I got that it is a GPU w/o DCE, VCE and UCD. Looks to me like it was intended for dual-graphics in notebooks along with Carrizo-APUs.
                  So first question: is there even dual-graphics support in amdgpu? If not, you can ignore the rest of the post

                  The GPU database on techpowerup (which I know is not entirely correct) states 384 shader processors / 6 CUs for PRO as well as XT (http://www.techpowerup.com/gpudb/#topaz). Also it sais there should be a 128 bit wide GDDR5 and PCIe3.0x8 interfaces which seems legit to me.
                  In theory and in my unprofessional opinion, this combination seems very unbalanced. The 8 CU APU GPU having <34 GiB/s of memory bandwidth shared with the CPU part and the second GPU with only 6 CUs having 64 GiB/s. How do you balance that in real time 3D, where we rely on alternate frame rendering for multi-GPU configurations? Are there provisions made in the drivers to balance and smooth that out?

                  Comment


                  • #39
                    IIRC "dual graphics" in Windows is another name for "Hybrid Crossfire", ie splitting a single graphics workload across two GPUs where one is the integrated graphics in an APU. If so then no plan to support that in amdgpu however one of the goals of Vulkan/DX12 is to shift that functionality from driver to game engine or app.

                    The 6 CU / 384SP number sounds right but my recollection was that Topaz had a 64-bit memory bus, which would make the performance of the two parts relatively similar (one has bigger engine, one has bigger tires ). If you dig a bit deeper into the techpowerup database you'll see that the references to 128 bit memory (at least the ones I looked at) describe memory as "system shared" (presumably the dual channel DIMMs) which is AFAIK not correct; the 64-bit references correctly talk about separate VRAM on a 64-bit bus.

                    EDIT - looks like the 64/128-bit confusion comes from the way that some tools describe the "composite" GPU - picking up 128-bitness from the APU's DIMMs and VRAM-ness from the dGPU.

                    The driver code does have some provision to deal with unequal render times, basically separating rendering from presentation with a short flip queue in between.

                    AFAIK the "canonical reference" for hardware is the Wikipedia pages, and they seem to be wrong in this case as well (describing some parts as being based on Cape Verde when I'm pretty sure they are actually Iceland/Topaz). My CZ laptop has a Topaz in it AFAIK, will check that.
                    Last edited by bridgman; 18 March 2016, 05:38 AM.

                    Comment


                    • #40
                      Originally posted by bridgman View Post
                      ... AFAIK the "canonical reference" for hardware is the Wikipedia pages, and they seem to be wrong in this case as well (describing some parts as being based on Cape Verde when I'm pretty sure they are actually Iceland/Topaz). ...
                      It would be nice if you would revise the Wikipedia pages.

                      Comment

                      Working...
                      X