980ti or Nano or Wait.

[FoxEye]

Got to kind of disagree with some of this. The nano handily outperforms the GTX 970. In daily use with the stock fan profile it will down clock to 900 Mhz mark or so which in benchmarks may show up as performing poorly. Notch up the fan even slightly and it will maintain a smooth 1000 Mhz which will trade blows with the Fury cards which run faster but have a cutdown Fiji core. OC the nano and your nipping at the heels of lowly clocked 980Ti's depending on the title.

But yeah I would at this stage stick with the GTX 970 or opt for the GTX 980Ti.

If you can't wait, then out of those 2x, the 980 Ti, it smacks the Nano silly, and some

Given OP's res is 1080p, I didn't think the Fiji cards put up much of a fight at that res?

So to see somebody suggesting the Nano is up there with a 980ti, is a bit of bold claim, for that res at least. Even if it's the rather unfair comparison of OC'd Nano vs stock 980ti

 

[CAT-THE-FIFTH]

I am doing an upgrade within the next three weeks, bringing mine and wife's gaming pc's up to X99 + 5820k + 950 pro ssd + 16gb DDR4

Now current graphics cards for both machines are 970's bought pretty much on day of release.

Given that we will both be sticking to 1080p for the foreseeable future my choice is 980ti (like the stryx dc3) or R9 Nano or stick with the 970 and use the £1200 budget in 2 months for Radeon or Nvidia's new offering.

Stick with what you have. AMD Polaris is being released by summer,and Nvidia will probably have something released this year too.

Plus what CPU do you use now??

 

[Simon Belmont]

Stick with what you have. AMD Polaris is being released by summer,and Nvidia will probably have something released this year too.

Plus what CPU do you use now??

This^

 

[Radox-0]

Given OP's res is 1080p, I didn't think the Fiji cards put up much of a fight at that res?

So to see somebody suggesting the Nano is up there with a 980ti, is a bit of bold claim, for that res at least. Even if it's the rather unfair comparison of OC'd Nano vs stock 980ti

I agree, the gap is slightly larger at 1080p. While I do not have the 980Ti I do have some Titan X's and a Nano in my HTPC. Messing around the Nano does get within a stone throw Titan X at stock speeds when its OC'd, I imagine the gap would be even slightly closer with a 980Ti. Not uprising as it has a full Fiji core and OC'd does notch ahead of Fury X performance (at stock)

Main point however was the post of the nano not being much better then the GTX 970. Anyway as I noted, I would opt for the GTX 980Ti if it was my main card, but at this stage wait most likely for the next round.

 

[Dave2150]

Zen is being released during Q4 of this year, so it most definitely is a 2016 product.

Last news we heard from actual AMD employees was that Zen hasn't taped out yet and that they expect revenue flow from it to begin in 2017. There's your answer right there.

 

[Calranthe]

Stick with what you have. AMD Polaris is being released by summer,and Nvidia will probably have something released this year too.

Plus what CPU do you use now??

The one I use now is a 4790k but the plan is to change platform to X99+5820k

 

[Kirby Wurm]

I'm in a similar position now. I've had to return my second GTX 780 (an EVGA card) for which I'll be getting a full refund. My wife's system now doesn't have a card. I've decided to buy her a basic card for streaming etc and wait for Pascal and Polaris and stick with my GTX 970. The temptation to give her the 970 and go for a 980 Ti is insane but it makes more sense to wait, even if I end up getting a card of similar performance at a lower price (Ti prices haven't really changed since launch either).

 

[D.P.]

Zen is a 2017 product. Pointless waiting for that, it will probably be another Bulldozer anyway, given AMD's pathetic CPU track record over the last 10 years.

If Zen if another a bulldozer then Polaris will be the last Radeon graphics card.

I'm more optimistic about Zen, AMD need to forget doing things they way they want developers to produce software and produce a CPU that has good performance in the way developers actually write software. They got that write with the x86-64 extensions, much easier for developers and compilers but in absolute terms far inferior to Intel's brand new 64bit architecture which no one could write good software for.

What I understand of Zen is it is much more similar to Intel architecture now and will probably offer slightly less performance but AMD will under cut on price.

 

[D.P.]

AMD doesnt have crap record on cpu, they just made a mistake, of thinking that the natural evolution of the PC software would be multi-threading, and by any logic it should have been, but it turns out that microsoft had other plans and left PC standing still, weither it's just them or by under the table agreement with Intel, everyone used a crapy API for years, add to that the anti competitive practices of Intel, AMD was short on money, over estimated the bulldozer...
to be honest it's just a crossroad of bad luck when i look at it, but to say they suck at cpu, because of that is kinda innacurate

It's really got nothing to do with Microsoft. Multithreaded programming is extremely hard and requires whole new levels of knowledge and understanding. As an example one of our backend servers has a rare race condition that causes a fatal crash, we have spent over 200 engineer hours in to trying track down this bug but it still exists.

And then there are things like the entire C++ standard library is basically not thread safe, so all the programmers familiar tools just can't be used without modification. It of course provides mechanisms to make it thread safe, but this only came about through C++11 which was not even well supported by compilers until 2013 at the earliest.

Furthermore multithreaded programming is seemingly rarely taught at university. We interview loads of candidates that just don't have the slightest clues about race conditions, mutexes, atomically.


Moreover, some programming tasks simply aren't suitable for parallel programming, a lot of numerical methods, n-body problems etc.

 

[fs123]

Last news we heard from actual AMD employees was that Zen hasn't taped out yet and that they expect revenue flow from it to begin in 2017. There's your answer right there.

Any references for that? Afaik Zen Apu is scheduled for 2017 but the CPU is due this year.

 

[D.P.]

The server zen parts are 2017 but I also thought the consumer zen parts were Q4.

 

[Mauller]

Consumer zen for end q3 - q4 2016, with APU and Opteron Zen in 2017.

And as D.P said. Many tasks cannot be broken down into parallel components no matter how hard you try. The math's is too linear for it. Although you can split many tasks to different cores, some individual tasks cannot be sped-up by breaking it down into multiple components.

Graphics submissions and frame preparation is something that can be highly threaded. The main downside to the older Abstracted API's is that they only submitted to the GPU by means of a single thread. Which is why the threading in DX11 rarely helped in the majority of cases. you could unload some processing from the primary thread but you were still suck submitting down the same pipe that was limited to one thread.

 

[Rroff]

It's really got nothing to do with Microsoft. Multithreaded programming is extremely hard and requires whole new levels of knowledge and understanding. As an example one of our backend servers has a rare race condition that causes a fatal crash, we have spent over 200 engineer hours in to trying track down this bug but it still exists.

And then there are things like the entire C++ standard library is basically not thread safe, so all the programmers familiar tools just can't be used without modification. It of course provides mechanisms to make it thread safe, but this only came about through C++11 which was not even well supported by compilers until 2013 at the earliest.

Furthermore multithreaded programming is seemingly rarely taught at university. We interview loads of candidates that just don't have the slightest clues about race conditions, mutexes, atomically.


Moreover, some programming tasks simply aren't suitable for parallel programming, a lot of numerical methods, n-body problems etc.

It can be scary how much carnal knowledge of how things work at a low level is required for safe multi-threading :S as I've found before - one little slip up not paying attention to how a data type or function works behind the scenes can really bite you in the rear down the line.

I don't think its really possible to change the current single threaded environment wholesale to a thread safe one as there are just too many context specific issues - as a programmer you really have to take library functions as examples and build your own that are safe for your project - which is quite a lot of work.

IMO you really need to double up the programming workforce to do it proper - one person working on the conceptual implementation and another person than tweaking it to work properly with multi-threading rather than one person try and stay on top of all the potential things that can break and/or optimally take advantage of multi-threading. (For most companies the gains just wouldn't make it worth while).

 

[Insanties_birth]

I normally promote the nano vs the 980ti (well, can be 50/50 depending on price or performance preference anyway) but if you already have a 970 I don't think it'd be a huge upgrade, if you're okay with that then it's probably the more cost effective card but it does sound like 980ti could be better in this scenario.

nano tends to have a bigger gap against 980ti at 1080p, unless you're planning on also getting a freesynch monitor at some point (in which case the nano + freesynch is far more cost effective than 980ti + gsynch) then I'd go for the 980ti.

 

[FoxEye]

It can be scary how much carnal knowledge of how things work at a low level is required for safe multi-threading :S as I've found before - one little slip up not paying attention to how a data type or function works behind the scenes can really bite you in the rear down the line.

I don't think its really possible to change the current single threaded environment wholesale to a thread safe one as there are just too many context specific issues - as a programmer you really have to take library functions as examples and build your own that are safe for your project - which is quite a lot of work.

IMO you really need to double up the programming workforce to do it proper - one person working on the conceptual implementation and another person than tweaking it to work properly with multi-threading rather than one person try and stay on top of all the potential things that can break and/or optimally take advantage of multi-threading. (For most companies the gains just wouldn't make it worth while).

I only skimmed the surface (the most basic of first principles), and it was way too scary for me

It actually makes me wonder how well they're coping with the APUs in the XOne and the PS4. 8 low-speed cores, yet they seem to be leveraging them pretty well (from the layman's point of view).

How well are the APUs utilised in this consoles, do you know? Is it mainly the feeding of the GPU that's been spread across cores? Whilst the game logic is still pretty much run on one core? Because things like collision detection, I could not see how that could be threaded at all. But then game logic probably amounts for a tiny amount of the actual number crunching going on.

 

[theMilitant]

I'd keep the 970s for the moment and wait for either AMD's or Nvidia's new line of GPUs. 14nm should mean the jump in performance will be quite significant compared to what we've been seeing the past few years. 970s are perfectly good cards for 1080p gaming, so it's not like you'll be suffering in the meantime.

 

[AlamoX]

I'd keep the 970s for the moment and wait for either AMD's or Nvidia's new line of GPUs. 14nm should mean the jump in performance will be quite significant compared to what we've been seeing the past few years. 970s are perfectly good cards for 1080p gaming, so it's not like you'll be suffering in the meantime.

ppl always forget that the 1st generation of the line up, might not even be better perf than 980ti, because they are limited by the chip size, it's for sure more efficient, but to have that ratio of 2x performance, the process need to be much more mature than what it is now to be able to accomodate chips over 500mm² and that could be 2017/2018.
for now we should be happy if they can achieve 350mm² chip, which could be just a little bit over 980Ti.

 

[Calranthe]

If I was to go for a 980ti what would you say is the best not only performance but low noise ?

Also is there any benefit G-sync over just better looking as in does it cause a performance boost or anything.

 

[AlamoX]

If I was to go for a 980ti what would you say is the best not only performance but low noise ?

Also is there any benefit G-sync over just better looking as in does it cause a performance boost or anything.

Gigabyte G1 seem to be good, G-sync help reduce stutter/tearing for smoother gaming

 

[r7slayer]

Got to kind of disagree with some of this. The nano handily outperforms the GTX 970. In daily use with the stock fan profile it will down clock to 900 Mhz mark or so which in benchmarks may show up as performing poorly. Notch up the fan even slightly and it will maintain a smooth 1000 Mhz which will trade blows with the Fury cards which run faster but have a cutdown Fiji core. OC the nano and your nipping at the heels of lowly clocked 980Ti's depending on the title.

But yeah I would at this stage stick with the GTX 970 or opt for the GTX 980Ti.

Your entitled to disagree but like i said the nano isnt much better than a 970. So never said it wasn't faster just not by much. By all means you can OC a Nano but with the cooler it is restricted by cooling and the Fury range dosn't OC massively. You can also OC a 970 and by a bigger degree than what you can with the nano. At 1080p the Nano isn't going to appear much faster in games tbh where as a 980Ti you will notice the performance boost in games. So just as i said in my post i stand by it.