AMD Radeon R9 Fury X Reviews
@pharma said:
Ht4u.net Fury X review
http://ht4u.net/reviews/2015/amds_furie_radeon_r9_fury_x_im_test/
Ht4u.net Fury X review
http://ht4u.net/reviews/2015/amds_furie_radeon_r9_fury_x_im_test/
@Chalnoth said:
Naively, one might expect AMD to have a small advantage here due to their previous work with Mantle. But at the same time, nVidia is something like seven times the size of AMD in terms of market capitalization, and AMD's money is divided across many more products.
Edit: Looks like their operating expenses are pretty similar, with AMD spending something like 30-50% more per quarter, which is more reasonable. But AMD hasn't been doing nearly as well as nVidia on earnings, which is probably why the market cap is so low. So I guess it doesn't mean quite so much in terms of R&D resources, except that nVidia can pull in extra resources at will while AMD is pretty limited and may have to start cutting back soon.
It will be very interesting to see how that all shakes out.
Naively, one might expect AMD to have a small advantage here due to their previous work with Mantle. But at the same time, nVidia is something like seven times the size of AMD in terms of market capitalization, and AMD's money is divided across many more products.
Edit: Looks like their operating expenses are pretty similar, with AMD spending something like 30-50% more per quarter, which is more reasonable. But AMD hasn't been doing nearly as well as nVidia on earnings, which is probably why the market cap is so low. So I guess it doesn't mean quite so much in terms of R&D resources, except that nVidia can pull in extra resources at will while AMD is pretty limited and may have to start cutting back soon.
@gongo said:
Do you think Fury X gamble on HBM1 is a silent failure....?
Since reviews of Fury X are out, 980Ti interests and love-lust have spiked to madness levels around all forums i read. People on the fence, neutrals and even Radeon supporters are positively cheering...moving onto the green team...
Would all the resources spent to develop HBM1 be better used to optimize the graphics arch. , instead of bunkering down on more GCN1.0 radeon cores? Or will AMD early start see them benefiting with future HBM2 and the roles will switch come the next node?
Or will new drivers help push Fury X back into the eyes of gamers..?
One famous Anandtech reviewer had called 290X dead and buried in his GTX970 review http://www.anandtech.com/show/8568/the-geforce-gtx-970-review-feat-evga/17
, only for AMD to fight back with their Hawaii chips now rivaling GTX980 than GTX970.
However the 980Ti is an overcocking beast....the pure numbers boost is attractive to gamers, that 30-40% free speed-grade, even though the nature of Maxwell relies on high clock speed boosts whereby the stock reference ones already boost to higher than advertised speeds
Do you think Fury X gamble on HBM1 is a silent failure....?
Since reviews of Fury X are out, 980Ti interests and love-lust have spiked to madness levels around all forums i read. People on the fence, neutrals and even Radeon supporters are positively cheering...moving onto the green team...
Would all the resources spent to develop HBM1 be better used to optimize the graphics arch. , instead of bunkering down on more GCN1.0 radeon cores? Or will AMD early start see them benefiting with future HBM2 and the roles will switch come the next node?
Or will new drivers help push Fury X back into the eyes of gamers..?
One famous Anandtech reviewer had called 290X dead and buried in his GTX970 review http://www.anandtech.com/show/8568/the-geforce-gtx-970-review-feat-evga/17
, only for AMD to fight back with their Hawaii chips now rivaling GTX980 than GTX970.However the 980Ti is an overcocking beast....the pure numbers boost is attractive to gamers, that 30-40% free speed-grade, even though the nature of Maxwell relies on high clock speed boosts whereby the stock reference ones already boost to higher than advertised speeds
@UniversalTruth said:
No. It is a good solution and if you ask me, I would immediately buy a R9 Fury X.
Perhaps, as you mention, the reason for this total madness is the hunger for more performance which eventually might be taken off 980Ti (via overclocking ?!).
No. It is a good solution and if you ask me, I would immediately buy a R9 Fury X.
Perhaps, as you mention, the reason for this total madness is the hunger for more performance which eventually might be taken off 980Ti (via overclocking ?!).
@Kaarlisk said:
HBM on it's own has definite value for Fury X, and if it was available, it should have been used. The issue is whether prioritizing certain other investments first (perf/watt, for example) might have paid greater dividends.
This is certainly not something like RV600's 512bit bus. The next flagship will remain with HBM, unlike R600->RV670 which went 512bit->256bit and ring->crossbar.
HBM on it's own has definite value for Fury X, and if it was available, it should have been used. The issue is whether prioritizing certain other investments first (perf/watt, for example) might have paid greater dividends.
@Chalnoth said:
I think it's only a failure if you think that anything less than the Fury X showing clear performance advantages over the 980 Ti is a failure.
Yes. That's an argument I made not too far earlier on this thread. I do think that AMD didn't really make use of the best that HBM has to offer, but I do think calling the product a failure is going a bit far. It's roughly where it should be in price/performance vs. the competition, and has an incredible cooler (when it's working properly...I expect the cooler issues to disappear shortly). The power consumption isn't great, though, which is a significant negative for me.
I think it's only a failure if you think that anything less than the Fury X showing clear performance advantages over the 980 Ti is a failure.
@3dilettante said:
Saying that AMD could have just prioritized one metric over the other may imply that resources are more fungible than they really are.
In terms of money, maybe, and there could be overlap in part, but HBM started years ago, and designing and implementing a memory standard is not going to map to reconfiguring a rasterizer, rewriting a DX11 driver, or revamping CU clock gating.
This is assuming there weren't costs or obligations associated with the HBM project if it were to have things like funding or organizational support stripped from it, and since the memory standard and its 2.5D integration involved outside parties, there probably would be complications.
As far as upside for pulling staff or funding to improving 28nm GCN, it would be hurting the time to market for the delayed HBM for the sake of an end of the line product for 28nm.
If they wanted to make that kind of call, AMD had multiple GCN revisions prior to have made the attempt. Fury is a bit late to start undermining the long-term play HBM presents. AMD has spun off high-speed IO engineering already, so some level of commitment has been made in this direction.
Saying that AMD could have just prioritized one metric over the other may imply that resources are more fungible than they really are.
In terms of money, maybe, and there could be overlap in part, but HBM started years ago, and designing and implementing a memory standard is not going to map to reconfiguring a rasterizer, rewriting a DX11 driver, or revamping CU clock gating.
This is assuming there weren't costs or obligations associated with the HBM project if it were to have things like funding or organizational support stripped from it, and since the memory standard and its 2.5D integration involved outside parties, there probably would be complications.
As far as upside for pulling staff or funding to improving 28nm GCN, it would be hurting the time to market for the delayed HBM for the sake of an end of the line product for 28nm.
If they wanted to make that kind of call, AMD had multiple GCN revisions prior to have made the attempt. Fury is a bit late to start undermining the long-term play HBM presents. AMD has spun off high-speed IO engineering already, so some level of commitment has been made in this direction.
@Chalnoth said:
It's a matter of prioritization. Certainly the development of the architecture was some time in the making, which gives AMD time to adjust its development priorities. I think what this experience shows is that AMD was short on investing in power savings and rendering efficiency.
@Kaarlisk said:
It seems my previous post needs the statement inhindsightoveraverylongperiodoftime added.
I do realize that such decisions are not made overnight, and that after a certain amount of investment has been made and there isn't enough time left, of the options AMD had remaining, choosing HBM as the priority for the last 28nm product was the best one.
HBM and adaptive voltage (and any other Fury improvements) might also be more decoupled from the shrink than architectural changes would be, which would make this less of a wasted investment (as in, they don't have to invest twice, both for the 28nm node and the next one). I'm trying to agree by paraphrasing here
It seems my previous post needs the statement inhindsightoveraverylongperiodoftime added.
I do realize that such decisions are not made overnight, and that after a certain amount of investment has been made and there isn't enough time left, of the options AMD had remaining, choosing HBM as the priority for the last 28nm product was the best one.
Ayup. If they can test something early and cheaply, they should. They've derisked HBM for their next architecture. And not just HBM, for example, adaptive voltage has also been derisked.
HBM and adaptive voltage (and any other Fury improvements) might also be more decoupled from the shrink than architectural changes would be, which would make this less of a wasted investment (as in, they don't have to invest twice, both for the 28nm node and the next one). I'm trying to agree by paraphrasing here
@3dilettante said:
But what does prioritization mean?
Sending the HBM signaling engineers to the ROP group?
Having the physical testing lab rewrite the WDMA memory allocator?
Asking the HBM protocol designers to work for free or for Hynix, Amkor, and UMC to just take a breather for a year or two?
Staffing prioritization means moving people around, but what upside comes from moving a group specializing in exploratory work in one field to the engineering of another?
If the resources for HBM only have so much overlap with GCN's design, then moving X from HBM to GCN would yield limited upside or organizational disruption plus significant damage to HBM's progress. AMD traded away its high-speed IO IP and engineers, so planning on improving its GDDR5 interfaces appears to be out.
Money is fungible, but just saying AMD could defund HBM assumes there wouldn't be costs in that direction. There are manufacturing partners to consider, and a risk that the next node's products would not have a new memory interface. HBM was started long enough ago that it would have been ramping in R&D by the time it was obvious 28nm was going to overstay its welcome.
But what does prioritization mean?
Sending the HBM signaling engineers to the ROP group?
Having the physical testing lab rewrite the WDMA memory allocator?
Asking the HBM protocol designers to work for free or for Hynix, Amkor, and UMC to just take a breather for a year or two?
Staffing prioritization means moving people around, but what upside comes from moving a group specializing in exploratory work in one field to the engineering of another?
If the resources for HBM only have so much overlap with GCN's design, then moving X from HBM to GCN would yield limited upside or organizational disruption plus significant damage to HBM's progress. AMD traded away its high-speed IO IP and engineers, so planning on improving its GDDR5 interfaces appears to be out.
Money is fungible, but just saying AMD could defund HBM assumes there wouldn't be costs in that direction. There are manufacturing partners to consider, and a risk that the next node's products would not have a new memory interface. HBM was started long enough ago that it would have been ramping in R&D by the time it was obvious 28nm was going to overstay its welcome.
@Chalnoth said:
Why do you think AMD's headcount is static and unchanging? Also, it's not all that uncommon for engineers to switch to different disciplines.
@3dilettante said:
People who specialize in very different fields can move, but since this is all on a schedule it is not without opportunity cost. Or they can quit, because their skills would be in demand elsewhere and they may like what they're doing.
The needs of an interposer-based parallel signalling protocol do not mesh well with a next-gen conservative rasterizer.
Just saying AMD could trivially shift its priorities around on a spreadsheet assumes that treating an established engineering effort like legos and failing to maintain external obligations wouldn't lead to a worse outcome than what we've observed now or for the next gen.
True, AMD's headcount is not static. I laid out one example where it declined precipitously when it traded away its high-speed IO assets--IP and engineers specializing in that specific field.
People who specialize in very different fields can move, but since this is all on a schedule it is not without opportunity cost. Or they can quit, because their skills would be in demand elsewhere and they may like what they're doing.
The needs of an interposer-based parallel signalling protocol do not mesh well with a next-gen conservative rasterizer.
Just saying AMD could trivially shift its priorities around on a spreadsheet assumes that treating an established engineering effort like legos and failing to maintain external obligations wouldn't lead to a worse outcome than what we've observed now or for the next gen.
True, AMD's headcount is not static. I laid out one example where it declined precipitously when it traded away its high-speed IO assets--IP and engineers specializing in that specific field.
@Chalnoth said:
But it does seem to me to be a pretty minor error for this product cycle, and it is also possible that the experience with HBM this time around will make for much better products next time around.
I really don't know why you seem to think that anybody is claiming that this kind of decision could have been done quickly or recently. It would have had to have been a decision made right at the start of the design for the Fury.
But it does seem to me to be a pretty minor error for this product cycle, and it is also possible that the experience with HBM this time around will make for much better products next time around.
@Kaarlisk said:
Or that such a decision would have had zero value (the engineers ran out of work to do, laying them off and rehiring a year later is unwise, changing their work profile is unfeasible).
If I may, the point is that such a decision would have to be made way before beginning detailed design of the Fury.
Or that such a decision would have had zero value (the engineers ran out of work to do, laying them off and rehiring a year later is unwise, changing their work profile is unfeasible).
@3dilettante said:
I'm not saying it would be done recently. Starting at the beginning of Fiji's design would be what, 2 or so years ago? That's 3 years into HBM's cycle, since it was stated work began in 2010, with announcements of the tech the next year.
I'm asking what it means to prioritize one thing that belongs in one discipline, implementing a memory standard, versus what falls in the bucket of making GCN power-efficient. Nevermind that one of the largest single power savings known for Fury is the memory interface, and that there were things done to reduce power consumption.
There's some set of resources in a bucket being labelled prioritizingHBM and there's a bucket called prioritizingmakingGCNpower-efficient.
Both are multiyear projects with varying sets of milestones, delays, and obligations.
There's an assumption that both buckets are of comparable size, that what is in each bucket can just be poured into the other, and that enough can be poured from one into the other to make a difference versus some apparent downsides to doing so.
In the face of limited global resources, what is going to one rather than the other, what is already locked in, what gets broken, and how much difference does it make?
When it comes to divvying up the pool of interposer characterization engineers working in year 3 for HBM, I think a project centered on expanding the tessellator's throughput would be fine if they stuck with HBM and didn't leave Amkor screaming at AMD.
I'm not saying it would be done recently. Starting at the beginning of Fiji's design would be what, 2 or so years ago? That's 3 years into HBM's cycle, since it was stated work began in 2010, with announcements of the tech the next year.
I'm asking what it means to prioritize one thing that belongs in one discipline, implementing a memory standard, versus what falls in the bucket of making GCN power-efficient. Nevermind that one of the largest single power savings known for Fury is the memory interface, and that there were things done to reduce power consumption.
There's some set of resources in a bucket being labelled prioritizingHBM and there's a bucket called prioritizingmakingGCNpower-efficient.
Both are multiyear projects with varying sets of milestones, delays, and obligations.
There's an assumption that both buckets are of comparable size, that what is in each bucket can just be poured into the other, and that enough can be poured from one into the other to make a difference versus some apparent downsides to doing so.
In the face of limited global resources, what is going to one rather than the other, what is already locked in, what gets broken, and how much difference does it make?
When it comes to divvying up the pool of interposer characterization engineers working in year 3 for HBM, I think a project centered on expanding the tessellator's throughput would be fine if they stuck with HBM and didn't leave Amkor screaming at AMD.
@silent_guy said:
Everything about today's Fiji would have made sense if the competition had been 10-15% slower. IOW: Maxwell being a bit less efficient or Nvidia deciding on, say, 20 SMs with high speed DP instead of 24 SMs without.
It's totally fair to criticize AMD for Fiji's lackluster performance (and terrible introduction, and being late), but, at the time when its specs were decided, with the information then at hand, its current specs probably were the best way to go.
Everything about today's Fiji would have made sense if the competition had been 10-15% slower. IOW: Maxwell being a bit less efficient or Nvidia deciding on, say, 20 SMs with high speed DP instead of 24 SMs without.
It's totally fair to criticize AMD for Fiji's lackluster performance (and terrible introduction, and being late), but, at the time when its specs were decided, with the information then at hand, its current specs probably were the best way to go.
@Jawed said:
You could argue that AMD had no choice with Fiji, compute was the only limit it hadn't reached. Or, you could argue that these absurdly low limits, only just over the horizon when GCN was introduced with Tahiti (when compute was at the limit per shader engine) indicate severe short-sightedness. Or imply that the architecture that succeeds GCN is in trouble.
It's not as if HBM and GCN crossed paths with no forewarning.
Maybe in the future zixel rate won't matter and pixels will be bottlenecked by compute not by bandwidth, but there's little sign that's going to happen.
Perhaps we should look to console games to see whether compute has become the primary bottleneck.
Or, maybe interposers, HBM and an API with real multi-chip support will take us into a future where a card is populated by an array of smaller graphics chips formed as a mesh
Apparently GCN in its current incarnation can't go to more than 4 shader engines, more than 16 CUs per shader engine and more than 16 ROPs per shader engine.
You could argue that AMD had no choice with Fiji, compute was the only limit it hadn't reached. Or, you could argue that these absurdly low limits, only just over the horizon when GCN was introduced with Tahiti (when compute was at the limit per shader engine
) indicate severe short-sightedness. Or imply that the architecture that succeeds GCN is in trouble.It's not as if HBM and GCN crossed paths with no forewarning.
Maybe in the future zixel rate won't matter and pixels will be bottlenecked by compute not by bandwidth, but there's little sign that's going to happen.
Perhaps we should look to console games to see whether compute has become the primary bottleneck.
Or, maybe interposers, HBM and an API with real multi-chip support will take us into a future where a card is populated by an array of smaller graphics chips formed as a mesh
@gongo said:
What is worrying for AMD is interests for Fury X seems to drop off the cliff...waaay off. I have not seen recommendations or anticipation for the next batch of Fury X cards. If this keeps up, Fury X will be stacking up in warehouses.
I say, it has all to do with AMD marketing..major fail by going the Titan X route. Even when new AIBs start plastering this brands on Fury X cards...they all end up the same. AMD should have allowed customization...change the pump...change the tubing...change the radiator sizes..have a hybrid cooler...have a full water block version... have an air cooled version! Look at the 980Ti, lots of reviews of different AIB's take are popping up, that generates tons of discussions and comparisons online. 980Ti chatter is alive, Fury X is not.
Letting Fury be 'that' guy...i am not convinced...the CU cuts are heftier...Fury still cant overclock for shits...AIBs can slap on their most aggressive fansinks on Fury...but its performance still won't overcome a Fury X. It is a 49 card...AIB customization will push it up by another 0-50...too expensive too close to Fury X/980Ti pricing. Obviously dropping Fury X to 69 will kill it but it also kills AMD pockets.
IMHO the only way AMD can re-generate interest is to quickly push out a new Never Settle games bundle + Omega drivers (with +20-40% gains). I doubt enabling voltage tweaks can save Fury non-overclockability, and dropping prices is too soon too negative.
As it stands, i'm with Albuquerque, i have followed AMD GPU for their past 4 generations..but today 980Ti ticks all the boxes for me. Fury X is not bad by any means, it is just not interesting.
What is worrying for AMD is interests for Fury X seems to drop off the cliff...waaay off. I have not seen recommendations or anticipation for the next batch of Fury X cards. If this keeps up, Fury X will be stacking up in warehouses.
I say, it has all to do with AMD marketing..major fail by going the Titan X route. Even when new AIBs start plastering this brands on Fury X cards...they all end up the same. AMD should have allowed customization...change the pump...change the tubing...change the radiator sizes..have a hybrid cooler...have a full water block version... have an air cooled version! Look at the 980Ti, lots of reviews of different AIB's take are popping up, that generates tons of discussions and comparisons online. 980Ti chatter is alive, Fury X is not.
Letting Fury be 'that' guy...i am not convinced...the CU cuts are heftier...Fury still cant overclock for shits...AIBs can slap on their most aggressive fansinks on Fury...but its performance still won't overcome a Fury X. It is a 49 card...AIB customization will push it up by another 0-50...too expensive too close to Fury X/980Ti pricing. Obviously dropping Fury X to 69 will kill it but it also kills AMD pockets.
IMHO the only way AMD can re-generate interest is to quickly push out a new Never Settle games bundle + Omega drivers (with +20-40% gains). I doubt enabling voltage tweaks can save Fury non-overclockability, and dropping prices is too soon too negative.
As it stands, i'm with Albuquerque, i have followed AMD GPU for their past 4 generations..but today 980Ti ticks all the boxes for me. Fury X is not bad by any means, it is just not interesting.
