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

  • #21
    Originally posted by gerddie View Post

    What exactly do you mean? The document you are linking to is from 2010. OpenGL defines tesselation shaders. and R600 supports them.
    fp64 was also supported if the hw supported it. Unfortunately, older hw does not support it, hence the software emulation. The same holds for tessellation. No support on older hw, but maybe software emu possible.

    Comment


    • #22
      Originally posted by duby229 View Post

      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.
      Or more likely to succeed, send in a mesa patch for drirc that implements the application profile hack to force the override automatically. (since apparently 4.3COMPAT does work)

      Comment


      • #23
        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.
        I can confirm 4.3COMPAT doesn't solve my issue.
        Code:
        Assertion failed: (Config.Shaders[CrossCompiler::SHADER_STAGE_VERTEX].Resource == 0) != (Config.Shaders[CrossCompiler::SHADER_STAGE_COMPUTE].Resource == 0) [File:C:\UE4_16_3\Engine\UnrealEngine-4.16.3-release\Engine\Source\Runtime\OpenGLDrv\Private\OpenGLShaders.cpp] [Line: 1737]

        Comment


        • #24
          Originally posted by smitty3268 View Post

          Or more likely to succeed, send in a mesa patch for drirc that implements the application profile hack to force the override automatically. (since apparently 4.3COMPAT does work)
          Yeah, that's true. But just for me personally I have some moral problems with that. Just for example that is -the- reason Unigine keeps releasing broken demo's.

          Comment


          • #25
            Originally posted by schmidtbag View Post
            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.
            Unless I'm mistaken, I don't think there's any amd gpu where the fp64 rate is lower than 1/16. Only select few can do better in hw and from the consumer cards even fewer can do better (I think the only consumer cards which can do 1/8 are those based on hawaii where the chip could do 1/2), so for most practical purposes it's pretty much always 1/16.
            (nvidia otoh had 1/24 on kepler and 1/32 for everything maxwell/pascal on the consumer side.)

            Comment


            • #26
              Originally posted by marvin42 View Post

              fp64 was also supported if the hw supported it. Unfortunately, older hw does not support it, hence the software emulation. The same holds for tessellation. No support on older hw, but maybe software emu possible.
              You want fp64 because the chips could otherwise do GL 4.5, but without it are restricted to GL 3.3, and noone (at least as far as games are concerned) is using fp64 anyway.
              But you don't want to emulate tessellation, and besides it wouldn't help much since there's other stuff you'd have to emulate for GL 4.0 anyway on r600/r700. Bit manipulation instructions (certainly doable just slow), the interpolateAt instructions, probably lots more stuff I forgot about.

              Comment


              • #27
                Thanks for working on r600g, Dave
                There is still users of this hardware who will continue to use in coming years, so your work is very appreciated.

                If you find time for this, please look into couple of r600g issues:
                https://bugs.freedesktop.org/show_bug.cgi?id=103900
                https://bugs.freedesktop.org/show_bug.cgi?id=100953

                Originally posted by airlied View Post
                Not everyone has a xeon, radv at least on lower CPUs seems to win out,
                But apart from Cayman I doubt a Vulkan driver would be worth it.
                Dave.
                I guess it also could be useful for DXVK project, so maybe worth not only on Cayman.

                Comment


                • #28
                  Originally posted by duby229 View Post

                  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.
                  Yes, I know from eariler posts, but as I said, if someone who have "GCN" GPU that have 4.x enabled by default can run genymotion (native GNU/Linux application) it clearly shows the problem in r600 drivers.

                  As for wine, maybe what you are talking about have something to do with this:
                  https://imgur.com/M6tYy6j

                  This is when 4.xCOMPAT profile is forced, while with core profile it does crash of course as I said before, interestingly enough, when 4.xCOMPAT profile is forced and gallium nine is enabled, those artifact do not exist (picture is as it is supposed to be), but it also crashes with core profile.

                  This is ofc. tested with latest mesa-git as of today (17.4.0_devel.99282.8ff8c82630).
                  Last edited by leipero; 19 January 2018, 07:46 PM.

                  Comment


                  • #29
                    Originally posted by leipero View Post

                    Yes, I know from eariler posts, but as I said, if someone who have "GCN" GPU that have 4.x enabled by default can run genymotion (native GNU/Linux application) it clearly shows the problem in r600 drivers.

                    As for wine, maybe what you are talking about have something to do with this:
                    https://imgur.com/M6tYy6j

                    This is when 4.xCOMPAT profile is forced, while with core profile it does crash of course as I said before, interestingly enough, when 4.xCOMPAT profile is forced and gallium nine is enabled, those artifact do not exist (picture is as it is supposed to be), but it also crashes with core profile.

                    This is ofc. tested with latest mesa-git as of today (17.4.0_devel.99282.8ff8c82630).
                    It's pretty common for gallium nine to work when wine doesn't. That's not an r600g problem, gallium nine has better compatibility than wine. It has for a long time now. But that is a separate problem.

                    As far as I can tell you are experiencing at least 3 separate problems. 1: Wine crashes when using it's default DX implementation, it may render correctly if the crash bug gets solved. 2: Wine with gallium nine renders incorrectly, that's probably a gallium nine bug handling something non-standard incorrectly. 3: The app implements compat profiles when only nVidia's driver on linux supports it, so mesa needs an override or the app itself needs fixed.

                    EDIT: In all probability each of those problems most likely boil down to non-standard use of various graphics API's. So really in the end it's the app that needs fixed.
                    Last edited by duby229; 19 January 2018, 08:24 PM.

                    Comment


                    • #30
                      Originally posted by orome View Post
                      AMD hw usually has between 1/16 to 1/64 fp64 performance in HW.
                      i am not aware of amd hw with either 1/64 or 1/32, but i am aware of amd hw with 1/4, 1/5 and 1/8

                      Comment

                      Working...
                      X