Announcement

Collapse
No announcement yet.

A question to brigdman or airlie XD about crossfire

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

  • #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


            • #21
              Typical GDDR5 data rates on shipping products are mid-way between PCIE 1 (2.5 Gbps per pin) and PCIE 2 (5.0 Gbps per pin), but in all cases you need an extremely wide bus to get the kind of bandwidth a modern GPU requires. An x16 or x32 bus isn't going to do the job.

              The point I'm trying to make about OpenCL vs OpenGL is that if you structure the OpenCL app (or any compute app) properly you don't have to access data in the other GPU's memory very much in the first place.

              Comment


              • #22
                Originally posted by bridgman View Post
                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 ?
                yes it make sense but now is not all the efficient it should be cuz well even if that fix the hardware ooops with the link between GPUs the developer have to be extremely careful controling the code to avoid intergpu processing with really massive loops operations or it will suffer an slowdown or crash (and that explains why cuda apps mostly arent multigpu aware or are only for really expensive software). i think a more CPU aproach should be more efficient here for both opengl and opencl aka each gpu been electronicaly aware of the other and the ability to map memory for common use

                Comment


                • #23
                  Originally posted by bridgman View Post
                  Typical GDDR5 data rates on shipping products are mid-way between PCIE 1 (2.5 Gbps per pin) and PCIE 2 (5.0 Gbps per pin), but in all cases you need an extremely wide bus to get the kind of bandwidth a modern GPU requires. An x16 or x32 bus isn't going to do the job.

                  The point I'm trying to make about OpenCL vs OpenGL is that if you structure the OpenCL app (or any compute app) properly you don't have to access data in the other GPU's memory very much in the first place.
                  well i agree too but it will help for really big operations XD and would be easier for developers XD lets wait for pcie 5.0 XD or fiber optics electronic or other cheaper superconductor

                  Comment

                  Working...
                  X