Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: A question to brigdman or airlie XD about crossfire

  1. #11
    Join Date
    Jan 2009
    Posts
    148

    Default

    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 .

  2. #12
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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.

  3. #13
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,544

    Default

    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 at 09:46 PM.

  4. #14
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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 at 09:52 PM.

  5. #15
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,544

    Default

    Quote 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

    Quote 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 at 10:10 PM.

  6. #16
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote 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...

    Quote 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 at 11:14 PM.

  7. #17
    Join Date
    Jun 2009
    Posts
    1,189

    Default

    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?

  8. #18
    Join Date
    Jun 2009
    Posts
    1,189

    Default

    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

  9. #19
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,544

    Default

    Quote 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 ?

    Quote 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 at 01:26 PM.

  10. #20
    Join Date
    Jun 2009
    Posts
    1,189

    Default

    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)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •