Well this just shows you don't really have much of a clue what you're talking about.
This has no effect on graphics rendering performance and is only relevant to compute if the compyte jobs are required to run synchronously with gameplay. If they are then GPGPU isn't going to be on option on the PC anyway and these jobs will likely run on the CPU or IGP.
Why is this going to slow down rendering tasks? It might make development easier but if anything, contention between CPU and GPU demands on memory will reduce performance, not improve it.
Do you even understand the point you are trying to make there? Because I certainly don't.
This is tied into your first point and as with that point has no effect on rendering. And if the compute work is done elsewhere than on the discrete GPU this is irrelevant anyway. Bare in mind high end PC CPU's (the kind paired with a 680) have 2-4x the "compute" ability of the CPU in Orbis.
Draw calls have always been an issue for PC's in comparison to consoles, it's never resulted in a doubling of the raw throughput of a console GPU though. If anything it's more of a CPU limitation.
2GB is to 8GB as 128MB is to 512MB. How many modern GPU's sport 512MB? The correct question to ask would have been how do current gen games run on 512MB cards. Still not great but lets at least construct our analogy's correctly. And yes, the memory size difference will be an issue for 2GB GPU's further down the line. It won't be apparent straight away though and if also won't make up for a 2x core performance advantage.
1 well the proof is in the pudding , just look at video
2 well i said in compute tasks
3 much quciker acces, mucz less coping and waiting for data, more options for practical use. lets write email to nvidia architects , they are wasting resourecs on unified adress space in maxwell
4"DX11+ GPUs as standard and the ability to construct draw lists over multiple threads thus making submission/draw faster meaning more draw calls and more stuff on screen and looking better.
Now, unless MS and the IHVs do something the PC is likely to still be restricted to single threaded draw calls (right now DX11's multi-threaded command list construction either slows things down on AMD hardware or effectively loses you a CPU core on NV hardware) and suddenly regardless of how fast your GPU is the consoles are blowing you out of the water draw call wise meaning the PC can't match a console in 'stuff on screen'.
We are already kinda at this point, the PC is only 'saved' by having the Mhz advantage but unless something changes that advantage will go away pretty quickly.
(Right now MS are blaming the IHVs and the IHVs are blaming MS and there is crazy talk about ditching DX and going 'to the metal' which I don't think anyone has really thought about as hard as they should have done. In short, it's a bit of a mess...)"
anything else?
5 and thats exactly why running both graphics and compute task is so slow currently
6limitation is limitation,and maybe it will exposed even more
7partialy agree, but 2GB will be limiting not even from rendering performance but simply from targeting assets etc... And in 2005 ,512Mb vram was a lot more common than 8GB in 2013...
BONUS
1 we are all know how much optimisation most pc ports have...
2 when these advanced games will ship , nvidia will have to sell next round of cards and i fell perfect excuse to leve 680 behind in performance, drivers adjusted accordingly...
That quote was in the context of DX9 and also very late into the console generation. Don't expect anything like that in the first year of a consoles launch using DX11 as the standard.
Just look to how early PS360 games performed next to comparable PC hardware in 2006 for evidence of that.
well we heard this "similar dx level "last time too, and qucickly dx10 was needed for simple ports...
bad performance of some cosnole games were effect of painfull learning of in order, mulithreded cpus and quick pc ports not gpu. And i remeber good stuff like graw and just cause too, with graphical features absent in pc versions running on hardware with more fillrate ,texrate etc (xtx1900...)