Nvidia GeForce GTX 1060 Founders Edition

[watercooled]

The part I don't get is having the same bus width on this die as the GP104? Or perhaps, and I'm completely speculating, they thought they'd be using GDDR5X across the GP104 line and that would be a differentiating factor, and either GDDR5X is too expensive/scarce or they didn't end up needing as much bandwidth as they thought? Either of those theories would fit having GDDR5 on the 1070 too?

[kalniel]

Ah right, interesting. See this is the sort of thing AMD should be shouting about then - Nvidia certainly would if they were in the same position!

Indeed. One suspects pascal drivers will be tuned to give a similar impact since pascal can do this to a limited extent (can't remember if I posted it before, but the futuremark explanation of async - as far as they implement it - on AMD/pascal is quite good:

http://www.futuremark.com/pressrelea...dmark-time-spy

)

[scaryjim]

The part I don't get is having the same bus width on this die as the GP104? ...

Or possibly, as has been speculated above, the GP106 and GP104 are pin compatible. Perhaps nvidia weren't sure if the GTX 1060 was going to be a GP104 part or a GP106 part, and so their board partners prepared for either eventuality and nvidia made sure the packaging for the GP 106 could be dropped directly into hybrid boards. Perhaps it'll still be possible to reuse the same boards for a GP 104-based GTX 1060 Ti in the future (assuming NV can disable individual SMs rather than entire GPCs, which is what they did on the GTX 1070). If they can tag the TDP at around 140W it should be easy enough for partners to reuse their existing designs.

So the GP 106 could be 192 bit naively, but the boards might also be able to take GP 104 dies and utilise the 256bit bus on that. At which point it's probably worth making a single board in bulk rather that tracing up two different designs.

[CAT-THE-FIFTH]

Indeed. One suspects pascal drivers will be tuned to give a similar impact since pascal can do this to a limited extent (can't remember if I posted it before, but the futuremark explanation of async - as far as they implement it - on AMD/pascal is quite good:

http://www.futuremark.com/pressrelea...dmark-time-spy

)

http://www.anandtech.com/show/10486/...tx12-benchmark

Under the hood, the engine only makes use of FL 11_0 features, which means it can run on video cards as far back as GeForce GTX 680 and Radeon HD 7970. At the same time it doesn't use any of the features from the newer feature levels, so while it ensures a consistent test between all cards, it doesn't push the very newest graphics features such as conservative rasterization.

That said, Futuremark has definitely set out to make full use of FL 11_0. Futuremark has published an excellent technical guide for the benchmark, which should go live at the same time as this article, so I won't recap it verbatim. But in brief, everything from asynchronous compute to resource heaps get used. In the case of async compute, Futuremark is using it to overlap rendering passes, though they do note that "the asynchronous compute workload per frame varies between 10-20%." On the work submission front, they're making full use of multi-threaded command queue submission, noting that every logical core in a system is used to submit work.

From another forum:

Yup, here's the FM dev himself saying that. Also the whole point of DX12 being so low level is to allow for separate code paths which are Needed to get the best out of the hardware, but instead FutureMark opted for a "neutral" path.


http://www.gdcvault.com/play/1023128...s-Tutorial-Day


http://forums.anandtech.com/showpost...6&postcount=82


Also the following.
http://forums.anandtech.com/showthre...2480259&page=2

But the problem is that it is not going to actually mirror any realworld DX12 game,as more of the optimisation has been pushed towards the dev.

[kalniel]

Those links back up what I was saying though right? Pascal has some kind of capability to run queues asynchronously, which is exactly what Doom is taking advantage of in the case of the 480 and texture streaming. FM are saying that it's possible to do that in a vendor neutral way - 'just' set tasks that can be run asynchronously as such and let the OS/driver decide whether to split them into separate queues or to run them serially (akin to threads). Further gains are to be found with vendor specific tailoring.

[CAT-THE-FIFTH]

The problem is no dx12 game is really going to be vendor neutral as either you will have the Xbox effect or the NV money effect.

Either way its rather strange we always hear how OK NV is with async and it's just like a politician making grandiose gestures!

Maxwell was meant to get optimisations and it never turned up and Pascal was fixed but still no optimisations have turned up.

Bethesda and iD tend to be more NV focussed IIRC so it is plain weird that Pascal does not do that great in Doom under Vulkan despite them making a big deal about it and Nvidia supposedly works closer with devs,etc.

My GTX960 runs Vulkan worse than OpenGL. Even GCN1.0 cards gain from Vulkan.

[watercooled]

What strikes me more is how 'issues', however minor, make disastrous headlines for AMD, but are swept under the carpet for Nvidia.

Exceed mobo power spec, ignored for several Nvidia cards, suddenly a disaster when AMD do it.

970 memory controller fail - go out and buy 980 instead.

Nvidia async lacking - meh.

AMD missing a couple of optional DX12 hardware features - the sky is falling!!

[kalniel]

Either way its rather strange we always hear how OK NV is with async and it's just like a politician making grandiose gestures!

I find it funnier that for ages nVidia people were saying that the only reason they don't show a gain from async was that they're already fully efficiently using their resources and that async only helps deal with inefficiencies. Low and behold suddenly pascal cards are seeing a bit of a boost from async.. are they guilty of the same thing they accused AMD of?

[DanceswithUnix]

So the GP 106 could be 192 bit naively, but the boards might also be able to take GP 104 dies and utilise the 256bit bus on that. At which point it's probably worth making a single board in bulk rather that tracing up two different designs.

Or, for the cheapskates, it could have a 256 bit bus that can talk to slower cheaper DDR4 making up for bps per pin drop with more pins.

A 256 bit 1060ti does seem more likely though.

[scaryjim]

Or, for the cheapskates, it could have a 256 bit bus that can talk to slower cheaper DDR4 making up for bps per pin drop with more pins. ....

Like it

I suppose we'll have to see if nvidia and AMD bother with GPUs below the RX 460 performance level - if they do I sincerely hope they consider switching to DDR4 instead of DDR3 for those cards - we could be looking at 128 bit 3200MHz instead of 1600Mhz, and that'd make a big difference to the performance of budget cards...

[watercooled]

With integrated GPUs as fast as they are you have to wonder what the TAM is like for the <£100 discrete GPU market now.

[scaryjim]

With integrated GPUs as fast as they are you have to wonder what the TAM is like for the <£100 discrete GPU market now.

True enough, although I've seem OEM boxes with AMD APUs coupled with a less powerful dGPU and no dual graphics

If AMD do Zen CPUs without IGPs then I guess there'll be a market, plus anyone who goes for Intel's extreme platforms for CPU performance alone, rather than gaming - HPC/workstation customers will still want GPUs and don't need ridiculous power. Workstations quite often come with low end dGPUs, so I guess there is at least some market there, if not a huge one...

[Xlucine]

Or possibly, as has been speculated above, the GP106 and GP104 are pin compatible. Perhaps nvidia weren't sure if the GTX 1060 was going to be a GP104 part or a GP106 part, and so their board partners prepared for either eventuality and nvidia made sure the packaging for the GP 106 could be dropped directly into hybrid boards. Perhaps it'll still be possible to reuse the same boards for a GP 104-based GTX 1060 Ti in the future (assuming NV can disable individual SMs rather than entire GPCs, which is what they did on the GTX 1070). If they can tag the TDP at around 140W it should be easy enough for partners to reuse their existing designs.

So the GP 106 could be 192 bit naively, but the boards might also be able to take GP 104 dies and utilise the 256bit bus on that. At which point it's probably worth making a single board in bulk rather that tracing up two different designs.

Why not just use the 1070 PCB for the 1060ti? Saves on PCB layers for the 1060, and doesn't take any new engineering.

[DanceswithUnix]

Why not just use the 1070 PCB for the 1060ti? Saves on PCB layers for the 1060, and doesn't take any new engineering.

Engineering (getting it out the door) and production engineering (making it cheap to produce) seldom get a chance to collaborate early on in a product when the time pressure is on. If it is clear that you are making a gazillion boards from the word go then you might put more effort in, but otherwise you keep your options open and design in flexibility. After all, there will probably be a rev 1.1 board once the bug reports come in.

[scaryjim]

Why not just use the 1070 PCB for the 1060ti?

It'd cost more? As you work down the product stack to cheaper cards the profit margins get increasingly tight. The 1060 Ti - if it exists - *must* be a cheaper product than the 1070, so profit margins will be tighter. Using a more expensive 1070 PCB cuts inot that margin even further; engineering the 1060 PCB so it could also be used for a 1060 Ti Probably doesn't cost much more and means you can use that PCB for more than one product line, so you get the economies of scale kicking in.

[forsakenrichy]

need sli support