Announcement

Collapse
No announcement yet.

A question to brigdman or airlie XD about crossfire

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

  • #11
    You should keep your code "in the card itself" as much as possible, I think. Like Bridgman says: accessing extern memory is always a bad idea, when you don't have to.

    Edit: I should refresh the page more often. agd5f beat me .

    Comment


    • #12
      Originally posted by bridgman View Post
      Gimme an "A" !
      Gimme an "F" !
      Gimme an "R" !
      Whaddya got ?

      Seriously, if you combine the hardware issues above with ever-growing amounts of post-processing and the fact that current graphics APIs don't do a good job of identifying dependencies between operations (which is why you end up with the draw/flush/draw/flush model) AFR is still the most user- and developer-friendly approach.
      enduser friendly? you are kidding....

      AFR=micro-stottering

      you need up to 30-40% more FPS on AFR because 30fps stottering your brain away! 40-50fps on AFR is like 30fps on 1GPU.

      Comment


      • #13
        Trust me, the alternatives are worse. Microstuttering was a big deal a couple of years ago before the drivers were tweaked to hide the time required to flip images between the cards, but all indications are that the contribution of AFR to micro-stuttering went away at least a year ago. The incidents I'm seeing these days seem to fall into one of two categories :

        - interference from a third party utility, typically an overclocking or fan speed tweeker

        - games running at a sufficiently slow refresh rate that some frames take 2 display refreshes and others take 3

        Both of these "micro-stuttering" problems are being seen with single GPU systems, not just AFR.

        I'm not saying micro-stuttering is a complete non-issue, just that AFR's contribution to micro-stuttering seems to have been significantly reduced to the point where it seems like #3 or #4 on the list of causes.

        That said, "user friendly" probably wasn't the best choice of words. What I was trying to get across was that any approach other than AFR is generally not going to run the apps that users want. Nearly all of the high eye-candy games with spiffy effects tend to use a lot of post-processing on the rendered frames, and generally AFR is the only model which will handle post-processing without introducing artifacts.

        Anyways, I'm not saying the original poster *has* to implement AFR, just giving them a heads-up about the different approaches and their pros / cons. Micro-stuttering is definitely something worth mentioning, because it does take some work to make sure that an AFR implementation does not contribute to micro-stuttering.
        Last edited by bridgman; 01-22-2010, 08:46 PM.

        Comment


        • #14
          Originally posted by bridgman View Post
          Trust me, the alternatives are worse.
          you are right but i tell you something about user friendly buying.

          Buy a 5870 2GB vram over-clock it to 1,x ghz.....

          and then wait wait wait wait long time to R900 in deep 2011!

          the Dual-GPU bullshit is not user-friendly its anti-user-stuff!

          multi-gpu= how to milk users in the max.... for less

          the alternativ on dev side is simple: drop OpenGL and DirectX completly and force openCL to the new standart and go Raytracing only rendering!
          Last edited by Qaridarium; 01-22-2010, 08:52 PM.

          Comment


          • #15
            Originally posted by Qaridarium View Post
            you are right but i tell you something about user friendly buying.

            Buy a 5870 2GB vram over-clock it to 1,x ghz.....

            and then wait wait wait wait long time to R900 in deep 2011!

            the Dual-GPU bullshit is not user-friendly its anti-user-stuff!

            multi-gpu= how to milk users in the max.... for less
            Hey, I'm not the one who wants to add multi-GPU support to the open source drivers

            Originally posted by Qaridarium View Post
            the alternativ on dev side is simple: drop OpenGL and DirectX completly and force openCL to the new standart and go Raytracing only rendering!
            Like this ?

            http://www.youtube.com/watch?v=33rU1axSKhQ
            Last edited by bridgman; 01-22-2010, 09:10 PM.

            Comment


            • #16
              Originally posted by bridgman View Post
              Hey, I'm not the one who wants to add multi-GPU support to the open source drivers
              i know...

              Originally posted by bridgman View Post
              wow nice thank you very much for this video...

              very very very nice... this will make openGL/directX obsolete!

              i think R900 should focus on this way to go.

              Raytracing and bulledphysiks just impressive°!

              this video is copencl grafic to on an cpu http://www.youtube.com/watch?v=7PAiCinmP9Y

              very nice :-)
              Last edited by Qaridarium; 01-22-2010, 10:14 PM.

              Comment


              • #17
                well my bet here due that the issues is very slow bandwith in the crossfire connector is that OpenCL will suffer from the same thing that opengl in multiGPU systems when you need to work with big textures cuz at code only level crossfire bandwith must be enough. based on this i seriously doubt you can do extremely detailed things in OpenCL with HD textures without any other tech brougth from hell like AFR in OpenGL/directx

                now the genius that added GDDR5 to all highend cards never thougth about crossfire link bandwith lol?

                Comment


                • #18
                  now for me to implement AFR well i dont see it easy at all, expecially get rid of the stuttering :* but ill try maybe i got lucky

                  Comment


                  • #19
                    Originally posted by jrch2k8 View Post
                    well my bet here due that the issues is very slow bandwith in the crossfire connector is that OpenCL will suffer from the same thing that opengl in multiGPU systems when you need to work with big textures cuz at code only level crossfire bandwith must be enough. based on this i seriously doubt you can do extremely detailed things in OpenCL with HD textures without any other tech brougth from hell like AFR in OpenGL/directx
                    The challenge with graphics is that OpenGL implements a "single processor" API, so the multi-GPU driver support needs to work without assistance (or even hints) from the application.

                    The OpenCL API takes a different approach -- it makes multiple processors directly visible to the app, so the application can decide how to split work between them. This generally means partitioning the data between processors and having each processor do "all the work" for the data it receives, which avoids the need to push data between processors, rather than running all of the data through all of the processors. Does that make any sense ?

                    Originally posted by jrch2k8 View Post
                    now the genius that added GDDR5 to all highend cards never thougth about crossfire link bandwith lol?
                    The primary limitation of the inter-card links is width, not speed. The 48xx and 58xx GPUs use a 256-bit memory interface, which is *much* wider than the inter-GPU links. The link bandwidth is more a function of package pincount and board layout issues than the speed of the individual pins.
                    Last edited by bridgman; 01-25-2010, 12:26 PM.

                    Comment


                    • #20
                      well i reach that far watching the crossfire connector but my point is well there are many solutions to this electronically beside wouldnt be smarter to keep the crossfire connector only like control device (like for example behave like a framebuffer memory mapper) and added the actual link between the cards through the PCIE 2.0 or 3.0 specification, i read several articles that claims that even pcie 1.0 still have enough bandwith to go nasty with anything and that pcie 2.0 is a marketing scam XD (not so sure about that cuz well you know forums, and well i know some electronics but well mobo are too complex nowdays to say anything for sure).

                      in the case of OpenCL is the same issue, i just have more control about when switch GPUs than with opengl but i still can't freely process texture or complex objects in the others GPUs memory due the bandwith limitation (not sure if tesla cards remove this limitations, cuz from what i,ve seen those babies handle and awesome lvl of load but true they are really more expensive)

                      Comment

                      Working...
                      X