Announcement

Collapse
No announcement yet.

amdgpu questions

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

  • #41
    I have one more

    What about "deprecated" FirePRO cards still being sold today, like the ones based on Tahiti?
    With fglrx being dropped and no SI support in amdgpu, those will eventually be "useless". Sure, they should work with radeon+mesa but that's not what anyone buys a FirePRO for. Will there be extended fglrx support for pro customers or will AMD just refer to LTS distributions?

    Comment


    • #42
      Originally posted by debianxfce View Post
      If you have a home cinema amplifier with hdmi inputs I undestand the need [...]
      Yes I do have one. But thanks for the tip
      I don't like the situation either. HDMI being the standard for audio transmission but it doesn't go without video signal... at least using Linux I can set the 2nd monitor (amp) to overlap the primary and not bother. On Windows it has to be next to the primary so I 'lose' the mouse sometimes. Connecting the monitor through the amp is not an option with WQHD and 144 Hz...

      Comment


      • #43
        Yeah you did prove before that you don't care about gaming and don't want to or can't put yourself in the position of gamers. No, you or your kid are not valid reference for the world's population. btw: using Windows for gaming is just being pragmatic but I don't even play games atm and have no active Windows installation if that does satisfy you or calm you down.
        And this is far off topic.
        Last edited by juno; 22 March 2016, 04:58 AM.

        Comment


        • #44
          Originally posted by juno View Post
          I have one more


          Originally posted by juno View Post
          What about "deprecated" FirePRO cards still being sold today, like the ones based on Tahiti? With fglrx being dropped and no SI support in amdgpu, those will eventually be "useless". Sure, they should work with radeon+mesa but that's not what anyone buys a FirePRO for. Will there be extended fglrx support for pro customers or will AMD just refer to LTS distributions?
          Unless there was an announcement I missed they are not deprecated. Did you see something I didn't ?

          I'm hoping we can move them all to amdgpu hybrid. If that doesn't work then we'll have to extend fglrx support, and we may have to do some of that anyways. Wherever possible, though, we would rather invest time in amdgpu than fglrx.
          Last edited by bridgman; 22 March 2016, 11:20 AM.
          Test signature

          Comment


          • #45
            Originally posted by bridgman View Post
            The MEC block has 4 independent threads, referred to as "pipes" in engineering and "ACEs" (Asynchronous Compute Engines) in marketing. One MEC => 4 ACEs, two MECs => 8 ACEs. Each pipe can manage 8 compute queues, or one of the pipes can run HW scheduler microcode which assigns "virtual" queues to queues on the other 3/7 pipes.
            Seems like Windows drivers are catching up to hardware at this point: https://community.amd.com/community/...haders-evolved

            There are statements from game developers about upcoming HLSL extensions, allowing even more console-like low-level access, including scheduling with ACEs. AMD is going to publish tools for that via GPUOpen.
            Does these extensions address the MEC's 'scheduling' mode? Is this functionality also coming to amdgpu and do you know, if equivalent Vulkan extensions are planned?

            Comment


            • #46
              Yep... I believe the Linux drivers have async compute enabled as well (I think radeon exposed two of the queues by default, amdgpu either 2 or 8).

              Vulkan is the first graphics API to be able to make use of them on Linux AFAIK, but OpenCL can make use of multiple queues as well. We enable the HW scheduler by default when running the HSA stack on Linux, and I believe Windows is starting to use it as well.
              Test signature

              Comment


              • #47
                Is/will there be functionality analogue to Catalyst/Crimson's "Overdrive" on Windows? This enables to alter core and memory clocks as well as power/temperature targets and fan speed.
                It would be nice just having a userspace tool and e.g. a /etc/amdgpu.conf plain text file or something for that reason

                Comment


                • #48
                  Always a tough question... the right answer is to have those controls in each desktop's settings apps rather than a vendor-specific thing that sits outside them all, but there's a chicken/egg issue with standards for communicating with drivers. AFAIK the radeon and amdgpu drivers already have most of the functionality enabled via sysfs so it's just a matter of wiring up a userspace tool.
                  Test signature

                  Comment


                  • #49
                    Originally posted by juno View Post
                    Is/will there be functionality analogue to Catalyst/Crimson's "Overdrive" on Windows? This enables to alter core and memory clocks as well as power/temperature targets and fan speed.
                    It would be nice just having a userspace tool and e.g. a /etc/amdgpu.conf plain text file or something for that reason
                    The driver exposes the temperature and fan control via the standard Linux hwmon interfaces. There are tons of tools and GUIs for that. Adjusting the clocks is somewhat non-standard (varies based on GPU and vendor). We provide a sysfs interface to adjust them. The driver will adjust the clocks dynamically based on load. In most cases the user shouldn't need to mess with them manually.

                    Comment


                    • #50
                      Not that overclockers will care much, but most GPU's are sold at very near their clock speed limits. It's been a long time since overclocking a GPU made any sense.

                      Comment

                      Working...
                      X