By using this site, you agree to our Privacy Policy and our Terms of Use. Close
JEMC said:

When the new Polaris cards launched, there were a lot of games that performed better on the older Hawaii/Grenada GPUs, that happened to have 40 CUs. Now, I know that one is a x90 parts and the other is a x80 part, but we all expect newer cards to perform better than the last ones, and move the performance bar one step further. That the new 480 couldn't beat the older 390 parts put the 480 in a bad spot and disappointed a lot of people, specially considering what Nvidia had managed to do with Pascal and that Nvidia's third tier card, the 1060, was faster than it in DX 11 games.

A 40 CU Polaris, while not setting the world on fire, would have been able to avoid all of that, making the 480 clearly faster than the cards it was replacing while on par or faster than the 1060 in DX 11 games and much, much faster than it in DX 12/Vulkan games, putting AMD in a better position in front of us, the consumers.

It's interesting. I upgraded an old clients rig just last week, ditched the old AMD FX 8120 for a Ryzen 1600X.. He asked me if it was worth upgrading the old Radeon R9 390X. (He is only running at 1080P) but decided to keep it and wait for another year or two.

Doing a heap of testing... It was almost performance identical across the board with my 3930K and Radeon RX 580 with both systems at stock.
I had the newer GPU, but older CPU, he was the opposite.
Only advantage I had was with the push of a button my CPU could clock at 5ghz which will give any AM4 Ryzen chip a run for it's money.

A 40CU part would have helped Polaris a heap, but... If AMD wanted to make it a home run... A 48CU part would have been perfect in my opinion.
It would have bridged the gap between Polaris and Vega as well.
Having a 38CU part then a jump to 56 CU is a massive divide.

fatslob-:O said:

Multi-engine is defined in the D3D12 spec, not so for async compute so I don't see a contradiction there ... 

Async compute CAN be exposed with D3D12 multi-engine ... (big difference)

nVidia and AMD describe Asynchronous Compute differently anyway.
If it's exposed in Direct X 12, regardless of how extensive, it's part of the Direct X 12 spec.

fatslob-:O said:

Not really since Microsoft can (At their own whims mind you!) determine who or who doesn't support DirectX ... (Tomorrow Microsoft could easily declare X vendor does not support their gfx API anymore. Microsoft is like an individual party who holds all the legislative powers and can't be voted out whereas AMD, Intel, and Nvidia are also individual parties who can run for executive powers and hold referendums politically speaking but they don't get the final say without Microsoft giving the OK.) 

Microsoft does seek input but I'd argue it's only for figurative purposes in comparison to the Khronos Group where the core working technical members can ACTUALLY veto out any changes to the spec ...

Not really.
AMD, nVidia have contributed to the Direct X specification. There is license agreements and patents at play here.

Heck even companies like S3, Imagination Technologies, NEC, Matrox, SiS have contributed to Direct X over the years.
For example, where do you think S3 texture compression came from? ;)

Microsoft just can't say "Get out" to S3.

fatslob-:O said:
I know but AMD's solution recommends using async compute but look at how that's turning out on PC where the vast majority of AAA games currently in development aren't using DX12 or Vulkan so AMD ends up getting crushed in benchmarks anyway ... (we're waiting any day now for Activision and Ubisoft to making the transition but main engine developers like Epic, Unity and japanese developers are the more guilty parties)

It does take time to transition to new technologies. I think next generation things will get interesting on this front. Super Keen.


fatslob-:O said:

Depends if there's a vendor agnostic solution that's offered ... (maybe not for async compute but I don't think there's a vendor agnostic solution for rapid packed math in Vulkan since that requires an AMD hardware extension so far) 

The only way AMD can't have a walled garden is if Microsoft and Khronos Group chooses to expose EVERY important hardware features (since it gives AMD no reason to roll out their own driver extensions) but I doubt their doing that soon since that would kill the portability of gfx APIs so AMD is usually stuck waiting for the industry to catch up or the industry goes in a different direction altogether and thus writing in stone of AMD's failed bid for the future forever ...

Even if their competitor does catch up in official hardware feature extensions AMD can still offer their own other unique hardware extensions to compliment the official extensions through their own drivers ...

AMD and the Industry are one in the same. AMD works with Microsoft and Khronos. Heck, Vulkan was born out of AMD's development of Mantle.

fatslob-:O said:
Wouldn't you prefer it if AMD rolled out their own walled gardens to be able to compete with Nvidia ? (no use in shunning propietary technology if they can a competitive advantage in current games and the fact that it's everywhere)

Most certainly not. I hate walled gardens.

To be fair, that hasn't really been AMD's M.O. for a very long time, since the early days of Tessellation a few decades ago.

JEMC said:

The console optimizations were always a thing I had doubts with when people started claiming that AMD would benefit from consoles having AMD GPUs. Consoles use their own tweaked APIs (OpenGL for PS4, DX 12 for XOne) that are optimized for the specific characteristics of the tech inside them. Hoping that devs would use that knowledge on PC, where most of them use yet another API (DX 11) and there are hundreds of different configurations, always looked a bit optimistic.


There is more to it than that.
Developers who wish to extract even more performance from the hardware will NOT use OpenGL or Direct X at all on the consoles. If a game is using Direct X 12 on the Xbox One, then it's performance/image quality would translate pretty similarly over to the PC.

Developers will instead use the platform-specific low-level API's instead.

fatslob-:O said:

I would say AMD is benefiting from consoles having AMD GPUs ... (PC games featuring shader intrinsics/async compute/FP16) 

PS4 does not use OpenGL (it uses GNM/GNMX) and the X1 uses customized DirectX ... (Devs have a similar enough option on PC known as DX12 and if they don't want to use it they could always opt-in for driver extensions with DX11 instead so that AMD can still benefit from console programming.)

The lowest common denominators, the Xbox One, Xbox One X and Playstation 4... Aren't really FP16 powerhouses so it's use will be limited even on PC. It's only the Playstation 4 Pro and Vega that are pushing double-rate FP16, it's not enough market saturation for it to obtain wide-spread industry use anyway. Thankfully.
I thought we left lower precision rendering back in the Geforce FX and earlier periods. Haha

Captain_Yuri said:

In other news, DF released their 1600/1600x vs i5 7600k review and man, it is super interesting.

Like this is actually one of the most interesting cpu tests I have seen thus far and it continues to give me reasons to recommend a 1600 over the i5 or wait until the 6 core intel cpus come out.

One of the most crazy parts is that the stock cooler on the Ryzen 1600 was able to get a stable OC to 3.8ghz.

The 1600 is certainly the better buy overall.

But, if you are running allot of lightly threaded games/apps, then I would still opt for the i5, especially when they can clock allot higher.






www.youtube.com/@Pemalite