it is ridiculous to call a $750 GPU "midrange".
We’re about 1 month away from NVIDIA’s next quarterly report it will be really interesting to see how much revenue they got so far from Turing especially considering the 2060 was released only 1 month prior to the date their revenue will be reported on.
Yeah, there are higher-end XCC Intel chips or higher end NVidia chips. But by any practical measurement, things pushing 500mm^2 or bigger is downright massive.
Radeon VII is ~350mm^2, but on a very expensive 7nm process. Hard to tell what "high end" or "mid range" will be at 7nm right now, since there aren't too many chips being made to compare against.
It doesn’t change the fact that the TU104 is a mid range die as far as the Turing lineup goes doesn’t matter if it’s 500mm^2 or 5M^2.
Radeon 7 is a fairly large die for its processes on a very expensive node using the fastest memory around which barely beats the 1080ti and brings next to nothing new to the table over Vega, heck i doesn’t bring that many new things over Fiji but at least they finally have dot product support.
The simple reality is that for gaming the 2080 is still a better pick if only because of the RTX features.
For compute the 2080 might edge it depending on the workload and especially for DL/ML due to the craptastic state of AMDs ecosystem even today.
For HPC as in FP64 then the Rad 7 is worse perf/$ than the Titan V you can buy a Titan V 24GB for £2400 today and get 7 tflops of FP64.
The only case where the Radeon 7 would be better than the 2080 is likely in a small subset of GPU accelerated software that properly supports AMD GPUs e.g. blender.
I think there's a strong argument to future-proofing 4k gaming experiences. I think the 1080 Ti is a better pick, but the 1080 Ti is sold out in the US Market. The 2080's 8GB of VRAM is usable today, but I'm not entirely sure how long it will be before 4k games blow through that.
1080 Ti had 11GB of VRAM, Radeon 7 is a bit overkill at 16. But 8GB is solidly a mid-range VRAM size.
> The only case where the Radeon 7 would be better than the 2080 is likely in a small subset of GPU accelerated software that properly supports AMD GPUs e.g. blender.
FP32 performance is also used in Adobe Premier (video editors). But yo man, 3d renders (like Blender) can take hours under normal circumstances. Its a solid market to try to accelerate.
https://www.pugetsystems.com/labs/articles/Premiere-Pro-CC-2...
And 8GB is more than enough, heck if AMD memory management worked as in dev's would've used it then 4GB is enough for 4K even today, there are plenty of GDC talks about it and how some games on average only accessed 3GB of memory for a given level the biggest ones were from Doom and Witcher 3 iirc.
This is how the Xbox One X can do 4K even if it's at 30fps with only 12GB of RAM shared between the GPU and CPU and how even the PS4 pro can do 4K with 8GB and in all cases when they can't it's not a memory limitation but rather a fill rate / horsepower issue.
I'll take NVIDIA's stellar memory management and compression and tiled rendering over AMD's 1TB of memory bandwidth and 16GB of memory for 4K gaming, and 4K gaming on PCs is well meh, I'm actually regretting getting a 4K monitor and a 1080ti SLI setup something which i will remediate once the 1440P FLAD HDR Gsync monitors come out to the market.
You're right about Adobe being bad with OpenCL, but its just an example. But my overall point is that the 2d video editing community is mostly about FP32. A high end FP32 card caters towards 3d renderers, 2d video editors, and others in the professional marketplace.
Davinci Resolve users seem to get a bigger benefit out of Vega cards than 10xx series NVidia cards. So it depends on your video editor.
----------
Aside from scientific compute, I'm having issues figuring out where FP64 support is an issue. All of the applications I'm aware of are FP32. There's a clear difference in the rendering of heavy effects (Optical Flow based Resampling) or 3d editors, so a good GPU really makes a difference in those cases.
> And 8GB is more than enough, heck if AMD memory management worked as in dev's would've used it then 4GB is enough for 4K even today, there are plenty of GDC talks about it and how some games on average only accessed 3GB of memory for a given level the biggest ones were from Doom and Witcher 3 iirc.
XBox and PS4 Pro are bad examples to use. Those systems have far weaker GPUs, and the textures aren't truly 4k.
If you enter a game with 4k texture packs (or 8k texture packs, like Star Citizen), you can expect your memory usage to spike significantly. 8GB is still sufficient, but gamers are expecting better and better textures.
4k + 10-bit HDR textures take up a lot of room.
Textures are the same as v.high/high on PC the only thing that some PC games add is an uncompressed texture pack which are simply stupid to begin with.
Xbox One X is a great example of a system that can push 4K or near 4K gaming because it does so pretty darn well.
The memory capacity is really not an issue with 8GB, in fact the only cases where the 2080 really pulls a head of the 1080ti is in higher resolutions especially 4K.
>if you enter a game with 4k texture packs (or 8k texture packs, like Star Citizen), you can expect your memory usage to spike significantly. 8GB is still sufficient, but gamers are expecting better and better textures.
Most textures in a game are well beyond 4 or even 8K regardless of the resolution, heck a simple texture atlas is huge.
Star Citizen is a crap game to use as an example as both the textures are overall simply horrid and it make PUBG looks like a well optimized title.
Overall the 2080 gives you RTX which is RT + Tensor Cores which will become very important as WinML/DirectML games begin to ship since NVIDIA both assisted Microsoft in defining the spec and it's essentially tailored for their Tensor Cores, you get concurrent Int/FP execution per ALU which will give NVIDIA a huge boost as integer shaders (e.g. compute shaders with heavy bool logic) will become more common and you get a more mature ecosystem, better encode/decode and various other small QoL improvements.
For gaming specifically the Radeon 7 doesn't have anything to offer other than to those that care more about the brand than what they get for their investment.
I really miss the days of the HD4000 series or the days when the R300, and sadly I don't see AMD getting out of this cycle any time soon, Fiji was late and underwhelming, Vega was late and underwhelming, and now Radeon 7 is late and underwhelming.
If Navi is another mid range GPU will see 15%-20% improevemnt over Polaris if we're lucky, once we get closer to Feb 7th I'm pretty sure we'll see that in 1080p there is likely no difference between VEGA64 and Radeon 7 and the only place we see the difference is in 4K due to slightly higher fill rate and more bandwidth since AMD still can't get delta compression to work correctly.
It's "enough" because it has to be. Game developers need to constantly pay attention to these budgets because people who play their games have hardware with limited performance. If everyone had more of a resource then none of them would say no to that particularly now that GPU compute is becoming more popular in games.
Doom had a similar talk, resource management is a key factor in game development.
GPU compute is a completely different issue.
4k isn't that impressive for gaming with a monitor. Most people can barely tell the difference between it and 1440p, but there's a huge performance difference. For VR it does matter though.
AMD has clearly placed a lot of R&D research into that approach and it would allow Ryzen 3000 etc to share a package with a Navi GPU die.
It would also explain the mysteriously absent second 7nm die in the Ryzen announcement this past CES.
CPUs have a long-history of NUMA / multiple sockets. GPUs history of "Crossfire" and other such technologies is far weaker and has far worse support. It is less clear how software is supposed to represent asymmetric access to memory.
How do you build a GPU with a single view of memory, when each die is likely connected to its own set of RAM? Especially with latency being as big of an issue as it is already.
I'm sure AMD is working on the problem, but I don't personally expect it to be solved so soon. Yeah, AMD Infinity Fabric is a nifty 50GB/s chiplet bus. But HBM2 is 1TBps, so Infinity Fabric is simply too slow to share data between hypothetical GPU chiplets.
The EPYC Zen 2 cores have increased L3 and then communicate to RAM via the monolithic I/O core. It's very different than traditional NUMA in terms of locality but it's also likely that latencies have been increased.
A GPU with the same design would look monolithic as far as software is concerned since modern GPUs are already subdivided into hundreds of compute cores as it is.
As stated earlier: the Infinity Fabric links on EPYC (not necessarily EPYC 2... but on original EPYC 1) were like 50GB/s. Assuming EPYC2 has a similar fabric, we're still only looking at technology that can push 50GB/s to any core.
GPUs like the Vega64 have 500GB/s bandwidth, and Radeon 7 has 1000GB/s bandwidth to main memory. Not cache, but literally its main memory bandwidth. Its completely, and unfathomably huge, compared to CPU architecture.
Building a 1000GB/s crossbar between RAM and GPU compute units doesn't seem like an easy problem to me. 50GB/s Infinity fabric was done before (socket-to-socket communication), AMD just shrank the tech down to fit on chiplets.
InfinityFabric really has nothing to do with this, especially when locality has such a strong impact on possible bus-widths.
HBM is the topology btw. Each 1024-bit connection (1024 pins!!) gives 250GB/s between the chip and RAM. 4-connections to RAM to one chip leads to 1000GB/s.
With a chiplet design, you'd need 2 or more chips connected to RAM. The immediate design of 1-chip == 2 memory controllers + 1-chip == other two memory controllers (500GB/s per chip) now halves the bandwidth.
So now you have to somehow, allow the two chips communicate at 500GB/s, bidirectional btw. (500GB/s from chip0 to chip1, and 500GB/s from chip1 to chip0). Even then, this bidirectional link will have horrible latency, since it will be Chip0 -> Chip1 -> HBM2 stack.
So it just raises questions how anything would work at all. It just doesn't seem like an easy problem to solve to me. But hey, maybe I'm wrong and AMD got it figured out. All I'm saying is: no one has demonstrated a chip-to-chip bus that keeps up with HBM2 speeds.
So the idea that bandwidth "halves" with any intermediate step is clearly wrong since the bandwidth available to any compute core is already a fraction of the total available.
yes and no. in a product marketed toward consumers, the price tiers have to be at least somewhat informed by what people are willing/able to pay. a boxster isn't an entry level car just because it's the cheapest one porsche makes.