Announcement

Collapse
No announcement yet.

Airlie Moves Ahead With His Plan For Soft FP64 For Mesa, OpenGL 4.3 For Evergreen GPUs

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

  • Airlie Moves Ahead With His Plan For Soft FP64 For Mesa, OpenGL 4.3 For Evergreen GPUs

    Phoronix: Airlie Moves Ahead With His Plan For Soft FP64 For Mesa, OpenGL 4.3 For Evergreen GPUs

    Yesterday we wrote about David Airlie working on a fresh push to get "soft FP64" support in Mesa for allowing some older graphics cards on the R600g driver to then have OpenGL 4 support thanks to this double-precision floating-point support being their last blocker. That code is moving forward...

    http://www.phoronix.com/scan.php?pag...Soft-FP64-Mesa

  • #2
    I think this is one of the places where free software/open source can be handy for people with lower budgets. I have a Radeon HD 5770 on this machine and it works well enough, I'm in no hurry to upgrade.

    Comment


    • #3
      Yes, baby!

      For the public interest: Remember that a bunch of AMD APUs (iirc. starting with the Brazos kind as in E-350) do use Evergreen architecture.
      I guess those should also be affected.
      And polishing that part in the driver can be done as time passes on, for now OpenGL 4+ can truly be advertised, but in reality hardly any program will really ask for a (performant) FP64.
      Stop TCPA, stupid software patents and corrupt politicians!

      Comment


      • #4
        Support for AMD cards on Linux is just amazing. Polaris/Vega GPUs will probably be supported for another decade

        Comment


        • #5
          Originally posted by Adarion View Post
          And polishing that part in the driver can be done as time passes on, for now OpenGL 4+ can truly be advertised, but in reality hardly any program will really ask for a (performant) FP64.
          With the possible exception of piglit and OpenGL conformance tests I didn't think anyone had found ANY programs that used FP64 at all. It's just one of those things that probably should not have been added to the standard in the first place (easier to say in hindsight though).
          Last edited by bridgman; 03-13-2018, 03:58 PM.

          Comment


          • #6
            Originally posted by bridgman View Post

            With the possible exception of piglit and OpenGL conformance tests I don't think anyone had identified ANY programs that used FP64 at all. It's just one of those things that probably should not have been added to the standard in the first place (easier to say in hindsight though).
            It always confused me that given that there was no push to just falsely advertise the fp64 support anyway to get GL 4 moving along. There's precedence in Mesa for doing that with certain other features. I guess at this point it doesn't matter much anymore.

            Comment


            • #7
              Originally posted by smitty3268 View Post
              It always confused me that given that there was no push to just falsely advertise the fp64 support anyway to get GL 4 moving along. There's precedence in Mesa for doing that with certain other features. I guess at this point it doesn't matter much anymore.
              There was a gentle push and a fair amount of discussion, however the consensus seemed to be to not do it because (a) over-rides were working well, (b) work had started on emulating FP64 instructions (although it stopped a couple of times after that) and (c) there was a concern that falsely advertising in upstream code would just sweep the problem under the rug and everyone would forget about it.

              In hindsight there were probably some other options that might have offered a good compromise, eg adding a drirc option to fake fp64 so that users could do a one time fake and have it persist while keeping upstream code honest. That would also prevent the user from having to pick a specific GL level to force, but I don't think that approach occurred to anyone at the time.

              Comment


              • #8
                Originally posted by bridgman View Post

                There was a gentle push and a fair amount of discussion, however the consensus seemed to be to not do it because (a) over-rides were working well, (b) work had started on emulating FP64 instructions (although it stopped a couple of times after that) and (c) there was a concern that falsely advertising in upstream code would just sweep the problem under the rug and everyone would forget about it.

                In hindsight there were probably some other options that might have offered a good compromise, eg adding a drirc option to fake fp64 so that users could do a one time fake and have it persist while keeping upstream code honest. That would also prevent the user from having to pick a specific GL level to force, but I don't think that approach occurred to anyone at the time.
                I'm pretty sure I was questioning on #radeon why feature overrides don't result in higher GL level (you can do those feature by feature through environment variable even without the drirc option) but yeah. Having a slow but non-crashing fp64 is most likely a better call than lying about features and crashing if someone wants to use them

                Comment


                • #9
                  Interesting... work has been sleep-depravation-busy recently so not sure if I missed that or forgot about it

                  Being able to override just fp64 and getting the appropriate GL level would have been ideal, but I guess the GL level logic wasn't implemented that way.

                  Comment

                  Working...
                  X