What disturbs me is that techs now existing for so long, whatever the name, like Crossfire and SLI, still give so many hassles. BTW solving synchronization problems has been done even longer, since physical and virtual parallel machines exist, yes, the difference is that parallel GPUs have less time to do it without their main job, producing a frame, goes bad, but they also have to do a more streamlined and predictable job than generic ones done by CPUs.
SLI/Crossfire issues are majority wise a myth. Not one game have i ever had SLI issues.
Crossfire sounds so much better. I guess AMD need to start a new face to compete with Nvidea
The only time I tried this was doing a 7950/7970 cross fire set up. Benchmarks it was a bomb, but in games the gains were minimal to non existent
...not much time to post anymore, used to be awesome on here really good fond memories from VGchartz...
PSN: Skeeuk - XBL: SkeeUK - PC: Skeeuk
really miss the VGCHARTZ of 2008 - 2013...
CGI-Quality said:
Not a myth, but largely overblown. I've had very few issues with SLI, myself. But then, every machine is different. |
This.
Crossfire overall has been damn solid for me for over a decade.
There have been a few times where the ball has been dropped, but they get sorted out pretty quickly.
The main cases where Multi-GPU isses arise is usually due to brand spanking new game engines that nVidia and AMD hadn't delt with before.
********
Personally, I think AMD and nVidia should open their drivers up a little... And "Crowd Source" Multi-GPU driver profiles, let the community handle it.
--::{PC Gaming Master Race}::--
Pemalite said:
|
No, the vast majority of the community is absolutely clueless in driver engineering ... (The FOSS community struggles as it is with drivers, let alone the general community.)
fatslob-:O said:
No, the vast majority of the community is absolutely clueless in driver engineering ... (The FOSS community struggles as it is with drivers, let alone the general community.) |
Disagree.
NGO and Omega did some great work on modifying nVidia and AMD's drivers... And they were closed source.
But I think you are misinterpreting what I meant. I am not saying make the drivers completely open source and community driven.
Just the ability for people to make multi-GPU profiles so people can try and force AFR and such to get the best performance and compatability in games...
Then have a Steam-workshop-like system where you subscribe to a profile, read reviews/look at ratings and so on.
The community does and can do great things if it has the platform, support and tools to pull it off... The situation with Linux drivers is not the best example to base anything on.
--::{PC Gaming Master Race}::--
Who would of thought that people don't want to buy 2 or 3 gpus?
Pemalite said: Disagree. |
NGO and Omega aren't custom drivers compiled from the source code, they're registry tweaks with alternative installers ... (It really isn't what I would call 'work' since no new functionality was exposed before the official drivers released. It's very hard to reverse engineer a driver.)
I don't think I misunderstood you, it's a bad idea to leave mGPU profiles to the community when only the internal gfx engineers are the ones who understand the issue at hand. MGPU profiles can only improve with interaction between the game developer and the IHVs since they control everything about how the game is rendered, a magic switch in the driver options isn't going to cut it when developers HAVE to use specific vendor APIs to enable mGPU ...
Before DX12/Vulkan, how mGPU worked without a cross-vendor API is that developers would need use proprietary driver extensions offered by the vendors themselves on top gfx APIs such as DX11 ... (mGPU needed vendor specific paths to work)