Reply With Quoteenduser friendly? you are kidding....Originally Posted by bridgman
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.
Senior Member
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.
Banned
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.
AMD Linux
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 07:46 PM.
Banned
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 07:52 PM.
AMD Linux
Hey, I'm not the one who wants to add multi-GPU support to the open source drivers
Like this ?
http://www.youtube.com/watch?v=33rU1axSKhQ
Last edited by bridgman; 01-22-2010 at 08:10 PM.
Banned
i know...Hey, I'm not the one who wants to add multi-GPU support to the open source drivers
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 09:14 PM.
Senior Member
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?
Senior Member
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
AMD Linux
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.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 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 ?
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 11:26 AM.
Senior Member
well i reach that far watching the crossfire connector but my point is well there are many solutions to this electronicallybeside 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