Announcement

Collapse
No announcement yet.

R600g "Soft" FP64 Shows Signs Of Life, Enabling Older GPUs To Have OpenGL 4 In 2018

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

  • #11
    Originally posted by marvin42 View Post
    Now someone needs to implement tessellation shaders using glsl, e.g.
    http://www.diva-portal.org/smash/get...FULLTEXT01.pdf
    What exactly do you mean? The document you are linking to is from 2010. OpenGL defines tesselation shaders. and R600 supports them.

    Comment


    • #12
      A couple questions:
      1. Will this reflect OpenCL? Keep in mind, compute tasks are what demand FP64 the most.
      2. What exactly is processing the FP64? Is the CPU taking the load? Because if so, I imagine the performance would be so bad that you might as well just use SWR, softpipe, llvmpipe, or whatever. Though, I suppose that also depends on the task being calculated.

      If Arlie can manage to get R600 to have at least 1/16 FP64 performance, that'd be incredible. That'd breathe new life in some of this old hardware I have currently running on fglrx.

      Comment


      • #13
        Originally posted by schmidtbag View Post
        A couple questions:
        1. Will this reflect OpenCL? Keep in mind, compute tasks are what demand FP64 the most.
        2. What exactly is processing the FP64? Is the CPU taking the load? Because if so, I imagine the performance would be so bad that you might as well just use SWR, softpipe, llvmpipe, or whatever. Though, I suppose that also depends on the task being calculated.

        If Arlie can manage to get R600 to have at least 1/16 FP64 performance, that'd be incredible. That'd breathe new life in some of this old hardware I have currently running on fglrx.
        The soft FP64 support is implemented in GLSL so on the GPU.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #14
          Originally posted by Michael View Post

          It would be mostly useless if someone spent all that effort to do a Vulkan driver for HD 5000/6000 since most games have a GL renderer complementing Vulkan (even with RADV right now it still generally trails RadeonSI performance and any older Vulkan driver would see even less work than RADV so would likely be much slower than R600g) and any Vulkan-only game likely is too demanding for running on HD 5000/6000 class hardware.
          The only Vulkan games I'm trying to use is Dolphin and RPCS3. Both of which run already with OpenGL. And we know Doom 2016 runs on the HD 6850 which is what I own. Doom 2016 is going to run on the Nintendo Switch which isn't exactly a powerful machine.

          https://www.youtube.com/watch?v=opHA9_eIFHA

          Comment


          • #15
            Originally posted by schmidtbag View Post
            A couple questions:
            1. Will this reflect OpenCL? Keep in mind, compute tasks are what demand FP64 the most.
            No. OpenCL uses different compiler (LLVM), even native fp64 for pre-GCN asics that support it is missing. GL compute shaders should work though.

            Originally posted by schmidtbag View Post
            2. What exactly is processing the FP64? Is the CPU taking the load? Because if so, I imagine the performance would be so bad that you might as well just use SWR, softpipe, llvmpipe, or whatever. Though, I suppose that also depends on the task being calculated.
            it's running on the GPU using integer instructions to implement the operations. I.e. instead of using one fp64 instruction it'll use dozens integer instructions.

            Originally posted by schmidtbag View Post
            If Arlie can manage to get R600 to have at least 1/16 FP64 performance, that'd be incredible. That'd breathe new life in some of this old hardware I have currently running on fglrx.
            That would make him a magician. AMD hw usually has between 1/16 to 1/64 fp64 performance in HW. It means that the same operation (single instruction) takes 64x longer for DP. Moreover, most advanced operations (log, exp, ...) only have fp32 instructions, so the entire operation needs to be implemented in SW for fp64, that usually means 100s of GPU instructions.

            all in all, sw fp64 will be there to enable rare use of fp64. Any shader that uses fp64 heavily will be likely 100-1000x slower.
            Last edited by orome; 19 January 2018, 11:11 AM.

            Comment


            • #16
              Originally posted by Michael View Post
              The soft FP64 support is implemented in GLSL so on the GPU.
              Originally posted by orome View Post
              No. OpenCL uses different compiler (LLVM), even native fp64 for pre-GCN asics that support it is missing. GL compute shaders should work though.

              it's running on the GPU using integer instructions to implement the operations. I.e. instead of using one fp64 instruction it'll use dozens integer instructions.
              Thanks for the clarifications. I guess for the time being I won't be depending on these drivers for OpenCL for a while. That's fine though - fglrx's OpenCL performance is still pretty good.
              That would make him a magician. AMD hw usually has between 1/16 to 1/64 fp64 performance in HW. It means that the same operation (single instruction) takes 64x longer for DP. Moreover, most advanced operations (log, exp, ...) only have fp32 instructions, so the entire operation needs to be implemented in SW for fp64, that usually means 100s of GPU instructions.
              AMD's hardware isn't that bad with FP64. From my research, most mid range or higher GCN models are 1/32 at the worst, but most are better. I have a HD 7770 that I think is 1/16, which is pretty decent for a mid-range consumer-level GPU. I have a FirePro V7900 that from my recollection has 1/8 FP64. Despite being 7 years old, that GPU still outperforms modern GPUs that are more power hungry than it. It crunches through [email protected] workloads in about 2.5 minutes, sometimes even less than 2 minutes.

              Comment


              • #17
                Originally posted by orome View Post

                No. OpenCL uses different compiler (LLVM), even native fp64 for pre-GCN asics that support it is missing. GL compute shaders should work though.


                it's running on the GPU using integer instructions to implement the operations. I.e. instead of using one fp64 instruction it'll use dozens integer instructions.


                That would make him a magician. AMD hw usually has between 1/16 to 1/64 fp64 performance in HW. It means that the same operation (single instruction) takes 64x longer for DP. Moreover, most advanced operations (log, exp, ...) only have fp32 instructions, so the entire operation needs to be implemented in SW for fp64, that usually means 100s of GPU instructions.

                all in all, sw fp64 will be there to enable rare use of fp64. Any shader that uses fp64 heavily will be likely 100-1000x slower.
                I disagree. Only reason for sw fp64 are conformance with OpenGL 4.whateveritwas. You're not expected to use it ever

                Comment


                • #18
                  Originally posted by nanonyme View Post

                  I disagree. Only reason for sw fp64 are conformance with OpenGL 4.whateveritwas. You're not expected to use it ever
                  Yes exactly. At the time when r600g was being developed clover was supposed to be the corresponding OpenCL implementation. Unfortunately that implementation didn't work well. So really the only good reason for this is to knock it off the feature list so a higher GL status can be achieved.

                  Comment


                  • #19
                    Originally posted by Xorg View Post
                    Yes, that's my case. But, unfortunately, forcing OpenGL 4.3 doesn't allow me to run CAT Interstellar on Steam. Time has come to change my video card, I hope Navi will rocks.
                    Forcing 4.3 doesn't allow to run genymotion for example, it crashes instantly, but 4.3COMPAT does run it.

                    Comment


                    • #20
                      Originally posted by leipero View Post

                      Forcing 4.3 doesn't allow to run genymotion for example, it crashes instantly, but 4.3COMPAT does run it.
                      As already said, it implements a compatibility profile, which mesa will never support. The only option is to contact them and try to explain why compatibility profiles will never be supported. That way they can fix their own code.

                      Comment

                      Working...
                      X