They aren't going to win anything until they fix their laughably bad drivers and keep them fixed. I have several Ryzens, but there's no way I'd go anywhere near their graphics cards.
Same with a 580. Linux, many monitors, work, light gaming. Drivers are the first time I've ever not had issues with Linux graphics.
Three years in I'm still waiting for the other shoe to drop. Where are the driver issues? I'm certain it was like a law of physics in Linux, but somehow, not this time, not for me?
I have 2x 24" monitors on Ubuntu 18.04.03 with a Radeon RX 580
I can't watch a video on Youtube without substantial tearing on Firefox or Chrome. I've followed close to 20 guides and tried a number of drivers which all fail provide any benefit.
Running glxgears will run at 7400FPS, with minor tearing. My monitors don't have FreeSync or whatever it's called since they're pretty old (over 10 years).
Since most guides are as helpful as "type this into a console" - I haven't learnt anything while trying these fixes.
edit: I tried to install the newest drivers (19.50), and they fail to install with build errors
since I had to uninstall the old ones (19.20) I'm now running Polaris10? drivers by accident, and the tearing issue seems to have disappeared. I have no idea if these are less performant, but they are sufficient for my needs.
Tearing issues tend to be problems of the application, compositor, or Xorg. Nothing the driver can do much about, unfortunately. Xorg in particular is pretty bad at tearing with multi-monitor setups.
Some DDX drivers handle tearing (implementing vsync). Tearing is basically not a problem at all on Wayland compositors since the spec addresses it directly (from what I understand)
My condolences. On Nvidia there is a Full Composition Pipeline option in Nvidia driver settings which gets rid of vsync issues. It's odd it's not on by default.
Nvidia X Server Settings app -> X Server Display Configuration -> Advanced... -> Force Full Composition Pipeline
Note, it is not saved during a reboot unless you click 'Save to X Configuration File' and then save to /etc/X11/xorg.conf for most distros.
Also, many distros have partial v-sync of some sort on. For most it isn't noticeable, but for many desktops it causes the screen to run at an effective 59 instead of 60fps (or that is what it looks like to me, non-scientific here), so it can be beneficial to look up how to turn off vsync on your distro. Eg, I'm on Mint so for me it's General Settings -> VSync method -> None. For most people, this is not a noticeable change.
I have a 580. Have you tried turning on the in-driver vsync option? AMD's implementation of it seems the best to me out of cards I've tried. You can turn it on while X is running easily using xrandr to see if it helps:
Switch to Wayland or just enable TearFree on Xorg, something like:
`xrandr --output DisplayPort-0 --set TearFree on`
of course you have to adjust to your output (`xrandr --props`).
I bought an out-of-date RX570 after the RX5000 series was released, because I wanted mature Linux drivers (and reduced price as vendors cleared out their obsolete stock). It's the first AMD card I've owned that's been completely trouble-free.
My move happened few months ago. I used Linux for years (and still use it in VMs/servers), however after changing GPU it was a compatibility nightmare. I chose AMD partly because I heard that drivers are good on Linux. Not sure how many hours I spend on it.
Are you really saying that AMD is worse than Nvidia on Linux???
I have a Nvidia GPU (on my laptop), and I've had a truly horrible experience on Linux with Nvidia proprietary drivers. I was actually considering ditching my laptop, and buying a new one with AMD chipsets, due to the issues I've had on Linux due to the presence of the Nvidia graphics card. I occasionally play games on my Linux laptop, using Proton (a Steam derivative of Wine), as well as native Linux games. So I do want a GPU. (Although, at this point I've even considered getting a laptop with no GPU and only integrated Intel graphics, since I want to at least be able to do business/work without problems.)
I am not saying that. I just had terrible experience on a laptop with AMD GPU + Linux (rip battery) and on a desktop with discrete AMD GPU (suspend and whatnot errors) + Linux. Friends and coworkers with NVIDIA didn't seem to have those problems
AMD GPUs with new architecture need around half a year on Linux to reach stability. At least that was my experience with Navi. But once they reach it, it's rock solid. I wouldn't touch Nvidia at all.
For machine learning, Nvidias driver situation is indeed terrible, but AMDs is worse in this sense: If you get the wrong kernel version, driver version or somehow mismatch the cuda version due to a pinned dependency, you're up the creek. However, everything downstream will work. With AMD, you will get the drivers on your machine no problem but heaven help you if you try to do anything with them (there are regressions and memory leaks, etc.)
I have a fair number of machines and I /typically/ buy laptop/desktops with intels' graphics which works wonderfully under linux.
On the occasion I use a descreet graphics card (Quatro M1200, GTX 670) it' usually nvidia, and it works pretty good if you have the proprietary driver installed. (even on FreeBSD).
I did, however, recently build a full AMD machine that I intended to use for linux gaming, I did the most "happy path" thing and installed Ubuntu.
It was a Ryzen 1700x with an AMD R9 390 (old at this point, but it was built when Ryzen just came out) and I genuinely couldn't get 3d Accel working at all.
Games ran like absolute garbage. I ended up installing all kinds of "amd" "amd-pro" and "radeon" drivers which came with various warnings about being out of date or proprietary.. or "this should be in the kernel as FOSS".. but it never worked.
I ended up selling the machine 2 years later.
Contrastly my laptop has hybrid graphics with Nvidia and is still working fine. :(
Υes they are, I am still waiting for the day that the Brazos APU will be properly supported in the open source driver, while fxglr was doing just fine.
Problem is, takes to non-existing driver ABI newer kernels don't take fxglr anymore, and proper Brazos support is most likely on no one's agenda.
I agree. On laptops I usually have an nVidia hybrid GPU but I always switch it off as I don't need it and use only the embedded Intel GPU.
Actually getting the nVidia GPU "really" switched off has often been a bit of a challenge.
Currently on a Lenovo P71 what I do is to have the nVidia-module not loaded (blacklisted or not even installed), load the "bbswitch" module and then execute "tee /proc/acpi/bbswitch <<<OFF" (and check with "cat /proc/acpi/bbswitch" if it returns "OFF"). Without doing this I noticed that the internal temperature when idle was a bit higher than what I thought it should be, so I must assume that otherwise the nVidia kind-of-GPU still consumes some watts even if the module is not even loaded/present.
> It might not be able to do anything else, but it should at least do that. LOL... :)
Thx - I never even took into consideration Nouveau.
Sorry, I have 0 experience with desktop & suspend (I have 2 desktops, both of them using nVidia, but they're basically servers running databases so I have never made them go to sleep).
We bought a few Ryzens with Vega8 for our devs on linux and it was a mistake. Unfortunately integrated graphics glitched horribly and it required us to find right set of kernel flags and features to disable. After encountering bug with amdgpu module randomly giving up, we just used discrete gpu.
I don't feel comfortable relying on their gpus after this experience but cpus are undeniably good.
Hard agree. I'm an "AMD fanboy" of sorts, and I abandoned their graphics cards for desktop use after a terrible experience with the drivers. Of course at the time I was using Crossfire. But even without Crossfire trying to use AMD on Linux or BSD is much harder than nVidia. Windows or Linux, simple or complex, the AMD drivers are just bad.
OpenCL is all you need, and for the sake of a healthy (read: non-monopoly) GPU computing ecosystem you must insist on good OpenCL support! Having an additional CUDA backend is fine if you want, but AMD GPUs are often really strong in a level playing field, which is exactly what you want as a consumer. Basically no consumer ever benefitted from a monopoly, and GPU computing is very important.
I've developed (as lead GPU dev in a 3-man team) two successful rendering applications with OpenCL on all 3 desktop platforms, it's not some kind of impossible task. More developers just have to stick their necks out and do it.
It's not, though. The blas and fft libraries are not only much slower (less efficient for the claimed peak of the cards), but they're missing features. For example, gemms don't work on complex half precision in any opencl library I've seen. Batched modes are missing for some types, etc. For basic operations, they're sufficient. But it's hard to get behind libraries that AMD doesn't really control.
The ship has sailed on opencl for Nvidia. It's not going to happen, and it's not worth holding out hope. At this point, cuda has improved at a much faster rate, and the support is much higher. It's just not worth building a new scientific computing product around opencl, since it's as portable as cuda at this point if Nvidia doesn't support it.
In principle there's nothing stopping people from developing similarly great libraries for OpenCL, which I would on the one hand expect to happen eventually, but on the other hand it's impossible to deny the existing achievements of Nvidia's software team.
What I'm hoping is that people in a similar position to mine, where I could easily choose OpenCL since I was coding everything from scratch in basically C, choose OpenCL instead of CUDA.
It's completely possible in many cases, and I'm not the world's greatest developer or anything; twice I chose OpenCL over CUDA and both turned out great. Particularly the JIT model is very useful. Judge for yourself:
Agreed! I posted this link here because I thought it was laughable, too. We do GPGPU programming (signal processing) and there's really no choice but Nvidia. I'd love there to be some competition, but AMDs developer tools and support are nothing compared to Nvidia. Plus Nvidia architecture is more "general purpose" than AMDs is for general computation
They had some good GPUs when they were well-funded; once AMD started to use RTG's revenue to keep their CPU business alive, they vanished from the high end.
Latest Ampere datacenter rumors are 70% speedup compared to V100, meaning 25TFlops in FP32, whereas AMD in theory could to 15Tflops and in practice only 8Tflops due to their software. They would have to improve speed 3x just to match NVidia's next generation GPUs; I am not sure upcoming Big Navi would be sufficient.
It's not comparable in efficiency but AMD is already shipping Vega II modules in the Mac Pro that claim "up to 28.3
FP32 TFLOPS".
And regardless, the article is about 4K gaming. I don't doubt Nvidia will have some 7nm monster but there might be a time period before it launches where AMD briefly regains the crown.
Yes, thanks for the correction. I should also add that the reason it's not fair to compare these kinds of cards is the inter-processor link is usually extremely slow. Because of that, performance with that kind of card is roughly equivalent to just having two cards in the machine as opposed to having the chips on the same card.
I've seen those A100 rumors, but I think they should be taken with a grain of salt. They did not specify where the 70% speedup will be, and it's highly likely it will not be fp32 increasing by that much.
You’re being downvoted but it’s true. People don’t realize that the data center is now driving the GPU market volume, and AMD is not yet seriously competing in this space.
And when that day comes, I will buy it. But for now I will go with nVidia. Also I badly need same CUDA codebase/documentation on AMD part as well to make such a move. ML is such a breeze when you throw CUDA at it these days.
I am stiiiill mostly reading/researching but I'm pretty sure that CUDA is crucial and OpenCL just won't cut it for ML.
That said, AMD had a CUDA clone/conversion system a while back. I'm not sure where that's gone.
The ideal would be to leapfrog CUDA and present something more usable and straightforward, especially something where the memory and threading model is really clear. CUDA already seem pretty good but there's always room for improvement.
AMD has something called HIP which is a portable version of CUDA (compiles to either nvidia or amd hardware). They made a tool called HIPPIFY which can auto translate CUDA source to HIP. Haven't used it myself so I can't comment on it's effectiveness.
AMD's rather old Radeon VII can really smash a 2080 Ti if you're doing relatively simple streaming computation, like say video processing. That 1TB/s HBM is no joke, and there's 16GB of it, at ~half the price of the 2080 Ti with 11GB.
Nvidia's memory compression is very impressive and allows them to do better with a narrower memory bus in many situations (such as games), however if your data is not so compressible (often the case in GPGPU) this advantage disappears.
Really all I care about is a good OpenCL driver implementation, especially OpenCL 2.2 support would be extremely attractive.
AMD's rather old Radeon VII can really smash a 2080 Ti if you're doing relatively simple streaming computation, like say video processing. That 1TB/s HBM is no joke, and there's 16GB of it, at ~half the price of the 2080 Ti with 11GB.
The Radeon VII is also pretty fast in training transformer networks. In some models that I trained, it was only ~25% slower than our Quadro RTX 5000s.
I hear that, I had a laptop some years ago with an Nvidia Optimus card in it. It was quite the frustrating experience. I got it to work well enough with bumblebee on Ubuntu but it never felt solid. I had hoped maybe the experience had gotten better but I guess not. I'll continue steering clear.
> Nvidia has traditionally been very easy to use with Linux...
Unless you want to do some cutting edge stuff with it. We're begging nVidia to fix their DPMS implementation over DisplayPort for years now.
Oh, I forgot that nVidia drivers do not make enabling VSync easy for video/compositing overlays for ~6 years? I have to disable all optimizations and lose 50% performance to enable VSync in a compositing or video layer.
Yes, most of it works but some annoying parts do not work, and nVidia doesn't make anything easier.
This is on a GTX680 card. It was king of the hill when I first bought it.
Nvidia used to be the less bad option, but AMD's transition to AMDGPU leapfrogged that a long time ago.
They're still focused on their proprietary drivers, and naturally that means that they're way behind on supporting modern kernels. That's an issue if you have other hardware that only had support added recently. Their integration with X11's autoconfig also tends to have.. problems.
Nouveau basically doesn't work for their modern GPUs. My work laptop has a 1660Ti, and X11/Nouveau still can't render anything with it. Wayland/Gnome/Nouveau kinda sorta works, but I'd rather not have to use Wayland if I can avoid it.
Nvidia's support for PRIME is lacking. Their official stance was that you should restart your X11 session every time you wanted to swap. Bumblebee kind of worked, but was very slow and unstable. It looks like they finally implemented support for dynamic PRIME now, but of course they had to name their trigger environment variable something else, so that existing scripts for AMD PRIME wouldn't work.
In my experience Nvidia on Linux is fine… as long as you have a typical/common setup. The moment you step outside the norm, the experience falls apart rapidly and Intel/AMD become vastly more pleasant to work with.
As one of the other replies to this comment mentioned, this is one of the pain points that the company System76 has spent some time working on. I think it's because it addresses a core part of their target market: professional developers or other users who might need access to the GPU for programming, but don't have the time or motivation to learn how to play around with a CUDA installation from scratch (I'm making the assumption that's probably a large part of your problem, as it has been mine).
Their Ubuntu-based distro, Pop!_OS, does a lot of good in this regard, and is really pretty plug and play for an Intel/NVIDIA combo set-up. The driver that they use to manage their CUDA install is also available for plain Ubuntu[1], and I've had good experience with using that to manage my own set-up running an Intel Xeon/NVIDIA P-series (if I'm remembering correctly). I haven't given it a shot on Debian, and if you're using something like Arch, there's a decent chance you'll be out of luck.
Note: I'm not affiliated with System76 in any way, just have slammed my head into this problem on multiple occasions and found this to be my go-to way of managing it.
I'm working in ML with NVIDIA, T4, v100, P100 GPUs, taking advantage of the integration with TensorFlow, specifically mixed precision, TensorCores and TensorRT, would like to see those levels of integration with AMD to start considering in our Infrastructure
The big problem right now is that ROCm, AMD's equivalent to Cuda for deep learning, is not supported for the consumer Radeon Navi cards. I had hoped it would be supported in ROCm 3.0 when that was released - but there has been no official word, which is worrying. If AMD are to compete in the GPU/DeepLearning space, it will be because they have hardware that is competitive (not even as good as Nvidia), low cost, and doesn't have the same EULA licensing restrictions as Nvidia. Could you imagine taking your TensorFlow program on AWS and just running the same code on a AMD GPU, but costing 25% of a V100 (with 80% of the performance)? That is where they should be. And the "run unchanged TensorFlow program" is not actually a problem - ROCm has been upstreamed into TensorFlow. It is support for their own Navi GPUs that is the software problem right now!
I agree that the lack of (official) Navi support is just bad strategy on AMD's part, but I disagree with your numbers.
Their goal needs to be performance parity or dominance, and then perhaps offer a slight discount. That's how they're succeeding with Zen on CPUs. Offering the kind of steep discount you write about is just bad business.
At the high-end (V100), Nvidia are price gouging, so there is room for a profitable strategy here where AMD significantly undercut Nvidia. My reasoning comes from my belief that AMD will not reach performance parity in the next generation - for deep learning, at least. If the new Arcturus GPU is competitive with Nvidia's new Ampere chip, that would be great. But they won't sell if they are not significantly cheaper. But they won't be significantly cheaper (Arcturus will be the "Enterprise" GPU). However, Big Navi will be much cheaper and can be used in a data center for deep learning without the legal problems that using a 3080Ti would have. I see this as the same "war" between Enterprise hard-disks from 10-15 years ago. Google came out and built their infrastructure on cheap commodity disks. But Dell, HPE and other vendors would not let you use them - they said they were inferior, etc. Commodity GPUs could "democratize" deep learning - ordinary servers could just include a couple of GPUs as a cheap add-on.
From a consumer perspective Ryzen certainly feels like a steep discount. Was there a comparable price/perf to 3900X/3950X in the Intel world? Last I looked it seemed like you had to hop ship to Xeon with more expensive boards and really expensive CPUs to get something similar on paper.
It looks like the 10980XE is the best answer. But in fairness, I believe it and its pricing was exactly an answer to Ryzen 9.
x86 CPUs arrive in a software marketplace with tons of compatible software available for them. AMD GPUs are at an enormous disadvantage without support for Cuda or some equivalent, or even some hint to developers about what they should be programming to (is it still OpenCL?)
They necessarily have to sell at a huge discount or datacenter providers won’t even pick up the phone when they call.
AMD has no chance until there's broad support for Cuda. Cuda is so deeply entrenched at this point that trying to fragment the space and compete against it is a non-starter.
The consumer/gaming market is nothing compared to the GPGPU market today.
Cuda is a proprietary Nvidia framework. You don't need cuda support to train deep learning models on TensorFlow. ROCm also works - and is built by AMD and is open-source.
Tensorflow is only a small subset of the massive engineering investment that has been done into cuda by various orgs and open source projects. We have GPU databases, GPU accelerated analytics packages, GPU accelerated DSP, etc. All with hand-written cuda kernels.
Unless AMD can provide a toolchain which takes cuda code and generates whatever it takes to run it with performance parity to Nvidia cards, it'll never take off.
ROCm is a decade too late to simply coexist with cuda and battle for market/mind share. Unless they can offer a massive perf/cost advantage, there is no incentive for anyone to invest in porting their code.
> Unless AMD can provide a toolchain which takes cuda code and generates whatever it takes to run it with performance parity to Nvidia cards, it'll never take off.
Of course not, and some things would never be ported. But if they had a massive cost advantage for a year or two in data centers, a lot of things would get ported, quickly.
Does HIP support all the programming languages that are able to target CUDA, like Julia, Numba, .NET, Java, Haskell, Fortran, C++?
Khronos did a big mistake to keep pushing C as the only compute language for so long, and it remains to be seen how much adoption SPIR-V is able to actually take from PTX.
So unless HIP actually matches PTX, it is a non-starter.
In theory HIP is a modified LLVM, but as far as I know Julia uses a modified LLVM as well, so unless they are upstreamed, we can't use them together :(
I guess I'm staying with NVIDIA with developer laptops for a long time, and maybe using AMD for ultrabook.
Have you tried installing rocm? Last I checked two months ago you had to run a Ubuntu 16.04 container on Ubuntu 18.04 because the amd drivers were only compiled for bionic and the rocm software was only compiled for xenial.
I've been running rocm directly on Ubuntu 19.04 for a while now. I didn't have to build from source either. It's odd that they haven't updated their docs about this yet.
The last time we purchased GPUs, we bought two Radeon VIIs besides RTX 5000s. For training transformers in Tensorflow and PyTorch, they were a steal, because the training is only marginally slower than the RTXes at a fraction of the price.
For LSTMs, we have found performance regressions compared to NVIDIA, but it's largely because it was hard to hit the optimized MIOpen code paths.
We're in the age of serverside GPGPU on the cloud.
"Looking at the GPU segment, the revenues have almost doubled over the past two years. This can primarily be attributed to Nvidia’s foray into data centers, expanding in both High Performance Computing and the cloud. The data center revenues were up a solid 133% in 2017, led by continued growth in its CUDA platform, and increased acceptance of its Volta architecture. "
The peak of bitcoin was when GPU marker were at their highest revenue. May be the word mining should not have been there. Given they are mostly gone to ASIC.
Doubling GPGPU market from 2017 -2018 doesn't mean "he consumer/gaming market is nothing compared to the GPGPU market today" And even they managed to grow in 2019 again, it is still no where near close.
Nvidia's revenue has been consistent over the years that their Gaming revenue is still the most important source of income and over 50% [1] of their revenue source.
Did they mention it will ever be supported on Navi?
It seems to be AMD is on its way to have specialise Architecture for each segment. Navi and Navi Refresh and Gaming GPU without Ray Tracing, so basically low end to middle segment. Navi 2 support Ray Tracing and aiming at higher quality possible.
Arcturus; the uArch name for Vega successor ( also known as Vega 30 ), was suppose to be double the size of VEAG VII, with all the power optimisation they learned from Zen 2. ( As in the current variant shown in Ryzen Mobile ). It seems AMD want to separate the GPGPU market from the rest. Which makes sense because 90% of the gamers dont do anything GPGPU based.
It doesn’t make sense at all. An enormous number of people who work on GPGPU will develop on consumer hardware before they move up to cloud computing or a Quadro or something. Trying to segment the market like this is based on a misunderstanding of developer needs and preferences. Which is pretty typical of ATI/AMD unfortunately.
AMD cards also work with hackintosh builds. Some of the cards work seamlessly, others take minor config, but much better than the nVidia support these days.
They do, but it's hard to get a replacement for my 1070ti. :( The rx580s are reasonably priced and have a good rep for being reliable! But compared to a 1070ti they are less capable. A vega 56/64 would be perfect, but they're hard to find new now. The 5700xts seem to be a disaster.
Yeah, running Catalina with Sapphire 5700XT Nitro+ in my hack tower and it’s buttery smooth. Way less pain than with Nvidia web drivers in High Sierra.
AMD is blocked by being not versatile enough. Their consumer cards support neither AI nor do they have good Linux drivers.
Of course, the average gamer doesn't care, but developers do. And as the result, almost all the video games - their core sales driver - are not as thoroughly optimized and tested on AMD as they are on the (likely overpriced) NVIDIA cards that developers use in their own home rigs.
I don't think there's much overlap between AI developers/Linux users and game developers. Of course the former market matters too, but I really doubt it has an effect on the gaming market.
Since some studios use Linux data processing pipelines or dabble with deep learning for procedural content generation, I don't see how they could buy anything except for NVIDIA for their staff at the moment.
I chose an AMD card specifically because of their great Linux drivers. Building a system on top of proprietary drivers is a non starter for me. Being heavily dependent on a vendor to support your platform has bitten me multiple times and it's especially frustrating when a proprietary software company uses something like electron but never ships a Linux release. Running these applications in wine is a complete pain in the ass and doesn't even work 90% of the time.
AMD cards don't yet have any raytracing support, right? I know it's a young technology, but they shouldn't be dragging their feet on it if they want to make a serious push for the top.
Please see my comments at the bottom (lol) about implementing a commercial GPU renderer from scratch with OpenCL (i.e. Nvidia, AMD and Intel, on Win Mac and Linux).
It's definitely possible to do it yourself in many cases, and while Nvidia have their amazing RTX technology now, for the sake of not having a GPU computing monopoly it's important to push for open standards support. There is DXR supporting multiple vendors, which is sort of one step forwards and two steps back (Windows-only)...
I’d like a card that is a 2080 but instead used all the extra transistors compared to a 1080 for traditional rendering, not raytracing. Raytracing might be a thing in the future but now it’s just a gimmick that uses silicon that could have churned out more frames instead.
The RT hardware takes up a small fraction of die area based on some articles I read a year ago. Furthermore, RT isn’t a gimmick: it’s literally the holy grail of graphics. Ask yourself why AMD, Intel, and consoles are all moving to it this year.
It is the holy grail, but in current games it’s mostly a high cost effect that offers very little. In many games you pay a huge fps penalty for something you basically need circled in screenshots to notice.
I don’t doubt it will be fantastic once it’s actually usable in the sense that people will choose to enable it. I fear next gen consoles, like current top end PCs, will have settings where you choose 4K/60fps/raytracing and you can enable two of them, or possibly just one. In priority order, raytracing is a distant third of those.
I think they are all moving to it because they know they need to get there eventually, and they need consumers to pay for it all the way.
Regarding the holy grail point, I like to exagerrate and say that rasterization is based on glorified sprite rotoscalers. It is not used because it models how light works, it is used because it allows fast hardware implementations. On the software side, it's lots of hacks until it looks mostly believable.
Real time ray tracing hardware is in a funny place right now.
Firstly, it's not really as impressive as it sounds. You aren't going to be playing a game where you explore a house of mirrors any time soon. Control is a really good implementation, and it's so good it makes it really clear how quickly it falls over.
Better than not ray tracing, but nowhere near non-real time traditional ray tracing.
Secondly, at least with the current generation of RTX, the performance hit you take is criminal. We're talking 40%. If you're most people, who buy a graphics card to a budget based on your requirements (say 1440p/60, or 1080p/144, or whatever), supporting ray tracing means you either need to massively over spend (in my calculations about 6 months ago, I would have had to double my budget), or drop your quality presumptions in resolution and framerate drastically.
Which brings us to third: support. RTX has been out for over a year, and there is really only 2-3 games where RTX makes any kind of interesting visual difference, and really only 1 (Control) that you're actually going to actively notice after playing for more than 5 minutes.
AFAICT then, RTX is useful as a fun demo to play around with for a few minutes, before disabling it and getting your framerate back so you can actually play the game, and for absurdly rich people (which is convenient for nVidia, because absurdly rich streamers have normalised 1080p gaming on 2080tis for awhile now).
I am looking forward to seeing the shape real time ray tracing takes on consoles, because I presume that will determine the true shape for the next decade or so.
>Secondly, at least with the current generation of RTX, the performance hit you take is criminal. We're talking 40%.
I never really understood this argument. If you really need tons of frames for a competitive game, just turn it off. Otherwise, the games that implement it correctly show a marked visual improvement, that can't be computed any faster as far as we know. It's like saying 4k renders 4x slower than 1080p, so it's not worth it unless you can get the same frames. You can, it's just a premium technology and you'll need to budget accordingly.
(this ignores the games that half-ass their raytracing and make almost no perceptible improvement, which to be fair is most of them)
I do agree though, that Control (and Metro Exodus) are the best examples. Every other RTX title just uses it for reflections, which are neat but not as much of a categorical upgrade as RTGI, imo.
People who spend serious chunks of time gaming (but who also remember what reality looks like...) will increasingly notice the inaccuracy or lack of ambient occlusion and shading overall.
This time last year, RTX, in popular discussion, was a joke. I'm seeing more and more people who've looked into it, can see the objective improvement, and are ready to adopt it once as it enters their budget range. It would definitely be a sore sport if Navi had even worse raytracing performance than the RTX series, or none at all. As the hardware proliferates, there will be more and more reason to developers to look into implementing it at its best.
Crazy idea: Maybe we could train a neural network on before/after images of raytraced scenes and implement it with a constant, minimal penalty, like DLSS, or maybe that requires too large of a network or maybe it results in a trippy mess.
> I never really understood this argument. If you really need tons of frames for a competitive game, just turn it off.
I think "if you need tons of frames" may be where your misunderstanding is coming from: most of us don't have tons of frames to give (especially in brand new AAA games that are the only ones implementing this technology).
For most people (and you can see this in sales data and hardware surveys), if they are looking to buy a new graphics card they are going to be buying one that they think will fit their needs for the next few years, not massively overshoot it. If you play games at lower than your monitors resolution, they look bad. If you play games at lower than your monitors refresh rates, you either get bad looking tearing, or lose a much larger proportion of frames than you need to.
To use myself as an example: I recently upgraded my computer that runs on a 3440x1440/60 monitor. My goal was to play games at 1440p60 for the next 3 years (ie until the new console generation settles and we know where things are going). I bought a 5700XT because it provided the best bang for buck, hit 1440p60 in most games benched, and it seemed reasonable that I could drop setting here or there and maintain good frame rates until I was done with it.
The nVidia option was a 2060S / 2070, which would have given me slightly more frames at 1440p, but for $50 more. If I wanted 1440p60 and RTX, I would have had to go all the way up to the 2080ti, which was roughly double the price.
> most of us don't have tons of frames to give (especially in brand new AAA games that are the only ones implementing this technology).
Especially because it's probably first person and over-the-shoulder games that probably get the best benefit from RTX, but those are the same games where a high frame rate improves playability the most. Not 'tons' of frames to be 'competitive', but 144Hz to be able to perform the actions you intend to perform without frustration. So at that framerate, in a pretty game, maybe you could run RTX at 720p? But resolution is pretty nice too, so the performance hit really is a big deal.
The kind of game where you'd get 300Hz and can burn frames on a whim isn't the kind of game that uses RTX, at least so far. Or you'd have to drop the other settings to low, which kind of defeats the point of improved visuals.
Since both next-gen consoles have realtime ray tracing support my guess is that adoption of ray tracing will massively increase in games next year. In fact I'd bet that at some point in the first couple years of this next generation we will see a game where ray tracing is used to make lighting a game mechanic in itself as opposed to merely eye candy.
The "problem" with AMD GPUs was always the lack of software 'compute' libraries, poorly optimized drivers, etc.
AMD could really gain a huge advantage(both in enterprise and in more consumer spheres, like gaming/media production) by opening up the development of drivers and software libraries to the interested folk.
So far they have done this (arguably) very well on Linux(by comparison to nvidia),yet the ecosystem of nvidia is still very big by comparison.
While it's true nvidia has invested hugely in their development ecosystem, AMD could gain some territory by integrating their software compute libraries(like RocM) in programming languages like C/C++/Python and libraries like Tensorflow,pytorch,etc. could gain them a huge advantage in multiple industries.(I personally would argue this should be done firstly for their very successful and potent CPUs)
OpenCL has been truly great and it still a go-to when you talk about massive heterogenous systems, but they should abuse the fact that gaming cards could accelerate similar compute workloads.
I don't know where they make their money, but if the hope is to compete in compute, I'd suggest that they do not "play the game" at all in GPUs and instead put together something 7nm and TPU-like. If I were them, I'd be working on that right now. 1TFLOPs/W would be a good goal, 100TFLOPs in 100W, using bfloat 16. Sidestep the GPU bullshit entirely, print money in a niche instead.
I wouldn't consider TPU/NPU/NNPUs a niche. It's inevitable at this point that you'll need machine learning accelerators just for running inferencing on edge devices.
Even if done only on the cloud I can see more could providers investing in their own TPU-like hardware for their clusters.
Well "vehicle" in this case is unambiguous - there's no confusion between a passenger and a vehicle in the scenario you described. For many there's not such a clear distinction between "cores" and "compute units" so I can see where the confusion arises.
Each compute unit handles 2560 hardware threads (64 per clock tick per compute unit).
AMDs GCN architecture runs 4 threads over 4 clock ticks natively. I forget if it was vertical SIMD or horizontal SIMD or whatever the proper terminology was. But this 4 threads over 4 clock ticks avoids the register stall issue. (RDNA performs 1 thread per clock tick and schedules around the stalls)
The other threads come from an SMT-like / hyperthread-like feature, allowing 10 hardware threads per slot.
All together, a compute unit supports 16 way SIMD per vALU x 4 vALUs per CU x 4 threads over 4 clock ticks x 10 'hyperthread-like' = 2560 hardware threads (over 4 clock ticks)
16 SIMD x 4 clock ticks gives your 64 sized wavefronts / warps that the programmer works with. The majority of the 'threads' are for latency hiding: work the GPU can do while waiting for RAM to respond. (In contrast to a CPU, which will search ~200 instructions out of order for work while waiting on RAM)
Even if everything the article says is true, and the AMD software environment was also improved to compete with Nvidia, it's probably still not enough to beat Nvidia.
The best they are claiming with Big Navi is 30% faster than a 2080 Ti. Sounds great, but they are comparing a card that won't be available for a year with a card that has been on the market for over a year already. Nvidia will have been working on faster stuff, and the best case for AMD is that they force Nvidia to release their next generation of products faster than they originally planned.
This isn't the same case as Intel which had been struggling with their 10nm process and security issues, which meant their current chips actually slowed down and they didn't have any new answers ready when AMD came out with Zen 2. We have seen that Nvidia has an answer for everything that AMD has done so far (price drops and Super variants to make the Nvidia cards remain the best choice at every level), and likely has an answer for their next few steps. I think the best that AMD can hope for is to achieve parity, they certainly won't be dethroning Nvidia.
I agree, the author makes a vague point about the 3080 not being released yet, but AMD also hasn't released their new chip yet.
What I think will be great for consumers is AMD releasing a good competing offer in a similar timeframe as Nvidia releasing their next generation. That may limit the Nvidia price increases, because over the past few generations they have gone up a lot for their top offering. And even a year after release they're still high. That can't stay like that if the next gen mid range AMD has higher performance.
Not an AMD fault, but I'm bummed that the only model of RX 5700 with ITX form factor is available exclusively in Japan, cause a I would love to assemble a full AMD 5 liters PC (without selling a kidney for importing the GPU...) T__T
159 comments
[ 3.3 ms ] story [ 216 ms ] threadThree years in I'm still waiting for the other shoe to drop. Where are the driver issues? I'm certain it was like a law of physics in Linux, but somehow, not this time, not for me?
I can't watch a video on Youtube without substantial tearing on Firefox or Chrome. I've followed close to 20 guides and tried a number of drivers which all fail provide any benefit.
Running glxgears will run at 7400FPS, with minor tearing. My monitors don't have FreeSync or whatever it's called since they're pretty old (over 10 years).
Since most guides are as helpful as "type this into a console" - I haven't learnt anything while trying these fixes.
edit: I tried to install the newest drivers (19.50), and they fail to install with build errors
since I had to uninstall the old ones (19.20) I'm now running Polaris10? drivers by accident, and the tearing issue seems to have disappeared. I have no idea if these are less performant, but they are sufficient for my needs.
(I don't see an option for it in the Nvidia X Server Settings app.)
Note, it is not saved during a reboot unless you click 'Save to X Configuration File' and then save to /etc/X11/xorg.conf for most distros.
Also, many distros have partial v-sync of some sort on. For most it isn't noticeable, but for many desktops it causes the screen to run at an effective 59 instead of 60fps (or that is what it looks like to me, non-scientific here), so it can be beneficial to look up how to turn off vsync on your distro. Eg, I'm on Mint so for me it's General Settings -> VSync method -> None. For most people, this is not a noticeable change.
https://wiki.archlinux.org/index.php/AMDGPU#Tear_free_render...
I have a Nvidia GPU (on my laptop), and I've had a truly horrible experience on Linux with Nvidia proprietary drivers. I was actually considering ditching my laptop, and buying a new one with AMD chipsets, due to the issues I've had on Linux due to the presence of the Nvidia graphics card. I occasionally play games on my Linux laptop, using Proton (a Steam derivative of Wine), as well as native Linux games. So I do want a GPU. (Although, at this point I've even considered getting a laptop with no GPU and only integrated Intel graphics, since I want to at least be able to do business/work without problems.)
I have a fair number of machines and I /typically/ buy laptop/desktops with intels' graphics which works wonderfully under linux.
On the occasion I use a descreet graphics card (Quatro M1200, GTX 670) it' usually nvidia, and it works pretty good if you have the proprietary driver installed. (even on FreeBSD).
I did, however, recently build a full AMD machine that I intended to use for linux gaming, I did the most "happy path" thing and installed Ubuntu.
It was a Ryzen 1700x with an AMD R9 390 (old at this point, but it was built when Ryzen just came out) and I genuinely couldn't get 3d Accel working at all. Games ran like absolute garbage. I ended up installing all kinds of "amd" "amd-pro" and "radeon" drivers which came with various warnings about being out of date or proprietary.. or "this should be in the kernel as FOSS".. but it never worked.
I ended up selling the machine 2 years later.
Contrastly my laptop has hybrid graphics with Nvidia and is still working fine. :(
Problem is, takes to non-existing driver ABI newer kernels don't take fxglr anymore, and proper Brazos support is most likely on no one's agenda.
On desktop NVidia is good. On laptops I like Intel graphics. because I don't want to muck around with getting working drivers.
Actually getting the nVidia GPU "really" switched off has often been a bit of a challenge.
Currently on a Lenovo P71 what I do is to have the nVidia-module not loaded (blacklisted or not even installed), load the "bbswitch" module and then execute "tee /proc/acpi/bbswitch <<<OFF" (and check with "cat /proc/acpi/bbswitch" if it returns "OFF"). Without doing this I noticed that the internal temperature when idle was a bit higher than what I thought it should be, so I must assume that otherwise the nVidia kind-of-GPU still consumes some watts even if the module is not even loaded/present.
NVidia on desktop "works" for me, but suspend/resume is a fiasco - one cycle and the graphics are never right again, flickering and crap everywhere.
Thx - I never even took into consideration Nouveau.
Sorry, I have 0 experience with desktop & suspend (I have 2 desktops, both of them using nVidia, but they're basically servers running databases so I have never made them go to sleep).
I am writing this comment in a laptop with Radeon Vega 8 graphics and Ryzen 5 CPU running Ubuntu 19.10.
I am playing Audiosurf2 in the second workspace.
But my experience with AMD cards on Windows and Linux has been overall pretty great.
I've developed (as lead GPU dev in a 3-man team) two successful rendering applications with OpenCL on all 3 desktop platforms, it's not some kind of impossible task. More developers just have to stick their necks out and do it.
The ship has sailed on opencl for Nvidia. It's not going to happen, and it's not worth holding out hope. At this point, cuda has improved at a much faster rate, and the support is much higher. It's just not worth building a new scientific computing product around opencl, since it's as portable as cuda at this point if Nvidia doesn't support it.
What I'm hoping is that people in a similar position to mine, where I could easily choose OpenCL since I was coding everything from scratch in basically C, choose OpenCL instead of CUDA.
It's completely possible in many cases, and I'm not the world's greatest developer or anything; twice I chose OpenCL over CUDA and both turned out great. Particularly the JIT model is very useful. Judge for yourself:
https://indigorenderer.com
https://chaoticafractals.com
It's also very useful for cross-vendor GPU benchmarking, see https://www.indigorenderer.com/benchmark-results?filter=sing...
iOS never went beyond OpenCL 1.0, and eventually Apple moved into Metal.
Android never supported OpenCL, as Google preferred to push their C99 based dialect, Renderscript.
Not true. They're gone as of a year or two ago. Ironically, they're at Intel.
And regardless, the article is about 4K gaming. I don't doubt Nvidia will have some 7nm monster but there might be a time period before it launches where AMD briefly regains the crown.
That said, AMD had a CUDA clone/conversion system a while back. I'm not sure where that's gone.
The ideal would be to leapfrog CUDA and present something more usable and straightforward, especially something where the memory and threading model is really clear. CUDA already seem pretty good but there's always room for improvement.
Nvidia's memory compression is very impressive and allows them to do better with a narrower memory bus in many situations (such as games), however if your data is not so compressible (often the case in GPGPU) this advantage disappears.
Really all I care about is a good OpenCL driver implementation, especially OpenCL 2.2 support would be extremely attractive.
https://www.sisoftware.co.uk/2019/08/01/amd-vega2-gpgpu/ BW test over there shows 627GB/s of actual BW.
I got 704 GB/s on my machine[1] using their test.
[1] https://imgur.com/a/tq3nEz5
The Radeon VII is also pretty fast in training transformer networks. In some models that I trained, it was only ~25% slower than our Quadro RTX 5000s.
As a Linux user, I’ll never buy a laptop with an Nvidia GPU again (if I can help it). What a pain.
A nice piece of hardware with relatively pathetic software to drive it.
Unless you want to do some cutting edge stuff with it. We're begging nVidia to fix their DPMS implementation over DisplayPort for years now.
Oh, I forgot that nVidia drivers do not make enabling VSync easy for video/compositing overlays for ~6 years? I have to disable all optimizations and lose 50% performance to enable VSync in a compositing or video layer.
Yes, most of it works but some annoying parts do not work, and nVidia doesn't make anything easier.
This is on a GTX680 card. It was king of the hill when I first bought it.
They're still focused on their proprietary drivers, and naturally that means that they're way behind on supporting modern kernels. That's an issue if you have other hardware that only had support added recently. Their integration with X11's autoconfig also tends to have.. problems.
Nouveau basically doesn't work for their modern GPUs. My work laptop has a 1660Ti, and X11/Nouveau still can't render anything with it. Wayland/Gnome/Nouveau kinda sorta works, but I'd rather not have to use Wayland if I can avoid it.
Nvidia's support for PRIME is lacking. Their official stance was that you should restart your X11 session every time you wanted to swap. Bumblebee kind of worked, but was very slow and unstable. It looks like they finally implemented support for dynamic PRIME now, but of course they had to name their trigger environment variable something else, so that existing scripts for AMD PRIME wouldn't work.
Their Ubuntu-based distro, Pop!_OS, does a lot of good in this regard, and is really pretty plug and play for an Intel/NVIDIA combo set-up. The driver that they use to manage their CUDA install is also available for plain Ubuntu[1], and I've had good experience with using that to manage my own set-up running an Intel Xeon/NVIDIA P-series (if I'm remembering correctly). I haven't given it a shot on Debian, and if you're using something like Arch, there's a decent chance you'll be out of luck.
Note: I'm not affiliated with System76 in any way, just have slammed my head into this problem on multiple occasions and found this to be my go-to way of managing it.
[1] https://support.system76.com/articles/cuda/
nVidia seem to still only support OpenCL 1.1.
Presumably this is a conscious decision - they'd rather invest in CUDA.
I have no idea what AMD is up to regarding OpenCL. Have they just quietly dropped all support? [0][1]
Intel seem to be doing better, with support for OpenCL 2.1, with support for both CPU and GPU targets. [2]
[0] https://community.amd.com/thread/232600
[1] https://community.amd.com/thread/233197
[2] https://software.intel.com/en-us/articles/opencl-drivers
This hasn't been true for quite some time now. They support 1.2.
[0] https://developer.nvidia.com/opencl
[1] https://stackoverflow.com/a/29607373/
Their goal needs to be performance parity or dominance, and then perhaps offer a slight discount. That's how they're succeeding with Zen on CPUs. Offering the kind of steep discount you write about is just bad business.
It looks like the 10980XE is the best answer. But in fairness, I believe it and its pricing was exactly an answer to Ryzen 9.
They necessarily have to sell at a huge discount or datacenter providers won’t even pick up the phone when they call.
The consumer/gaming market is nothing compared to the GPGPU market today.
Unless AMD can provide a toolchain which takes cuda code and generates whatever it takes to run it with performance parity to Nvidia cards, it'll never take off.
ROCm is a decade too late to simply coexist with cuda and battle for market/mind share. Unless they can offer a massive perf/cost advantage, there is no incentive for anyone to invest in porting their code.
They have this. It's called HIP.
"HIP is designed to ease the porting of existing CUDA code into the HIP environment."
Not even close an drop-in swappable alternative.
Khronos did a big mistake to keep pushing C as the only compute language for so long, and it remains to be seen how much adoption SPIR-V is able to actually take from PTX.
So unless HIP actually matches PTX, it is a non-starter.
I guess I'm staying with NVIDIA with developer laptops for a long time, and maybe using AMD for ultrabook.
So if HIP will only work with LLVM, that is also a non-starter.
https://github.com/nixos-rocm/nixos-rocm
The last time we purchased GPUs, we bought two Radeon VIIs besides RTX 5000s. For training transformers in Tensorflow and PyTorch, they were a steal, because the training is only marginally slower than the RTXes at a fraction of the price.
For LSTMs, we have found performance regressions compared to NVIDIA, but it's largely because it was hard to hit the optimized MIOpen code paths.
Even at the peak of Bitcoin mining, Gaming GPU is still by far the largest source of revenue for GPU market.
We're in the age of serverside GPGPU on the cloud.
"Looking at the GPU segment, the revenues have almost doubled over the past two years. This can primarily be attributed to Nvidia’s foray into data centers, expanding in both High Performance Computing and the cloud. The data center revenues were up a solid 133% in 2017, led by continued growth in its CUDA platform, and increased acceptance of its Volta architecture. "
https://www.forbes.com/sites/greatspeculations/2018/06/27/wh...
Doubling GPGPU market from 2017 -2018 doesn't mean "he consumer/gaming market is nothing compared to the GPGPU market today" And even they managed to grow in 2019 again, it is still no where near close.
Nvidia's revenue has been consistent over the years that their Gaming revenue is still the most important source of income and over 50% [1] of their revenue source.
[1] https://www.anandtech.com/show/15111/nvidia-announces-q3-fy-...
It seems to be AMD is on its way to have specialise Architecture for each segment. Navi and Navi Refresh and Gaming GPU without Ray Tracing, so basically low end to middle segment. Navi 2 support Ray Tracing and aiming at higher quality possible.
Arcturus; the uArch name for Vega successor ( also known as Vega 30 ), was suppose to be double the size of VEAG VII, with all the power optimisation they learned from Zen 2. ( As in the current variant shown in Ryzen Mobile ). It seems AMD want to separate the GPGPU market from the rest. Which makes sense because 90% of the gamers dont do anything GPGPU based.
r/hackintosh guide https://hackintosh.gitbook.io/-r-hackintosh-vanilla-desktop-...
OpenCore (most recent) https://khronokernel-2.gitbook.io/opencore-vanilla-desktop-g...
A year or so ago, the discussion seemed much more clear that AMD wasn't in the game at all.
Of course, the average gamer doesn't care, but developers do. And as the result, almost all the video games - their core sales driver - are not as thoroughly optimized and tested on AMD as they are on the (likely overpriced) NVIDIA cards that developers use in their own home rigs.
It's definitely possible to do it yourself in many cases, and while Nvidia have their amazing RTX technology now, for the sake of not having a GPU computing monopoly it's important to push for open standards support. There is DXR supporting multiple vendors, which is sort of one step forwards and two steps back (Windows-only)...
I don’t doubt it will be fantastic once it’s actually usable in the sense that people will choose to enable it. I fear next gen consoles, like current top end PCs, will have settings where you choose 4K/60fps/raytracing and you can enable two of them, or possibly just one. In priority order, raytracing is a distant third of those.
I think they are all moving to it because they know they need to get there eventually, and they need consumers to pay for it all the way.
Firstly, it's not really as impressive as it sounds. You aren't going to be playing a game where you explore a house of mirrors any time soon. Control is a really good implementation, and it's so good it makes it really clear how quickly it falls over.
Better than not ray tracing, but nowhere near non-real time traditional ray tracing.
Secondly, at least with the current generation of RTX, the performance hit you take is criminal. We're talking 40%. If you're most people, who buy a graphics card to a budget based on your requirements (say 1440p/60, or 1080p/144, or whatever), supporting ray tracing means you either need to massively over spend (in my calculations about 6 months ago, I would have had to double my budget), or drop your quality presumptions in resolution and framerate drastically.
Which brings us to third: support. RTX has been out for over a year, and there is really only 2-3 games where RTX makes any kind of interesting visual difference, and really only 1 (Control) that you're actually going to actively notice after playing for more than 5 minutes.
AFAICT then, RTX is useful as a fun demo to play around with for a few minutes, before disabling it and getting your framerate back so you can actually play the game, and for absurdly rich people (which is convenient for nVidia, because absurdly rich streamers have normalised 1080p gaming on 2080tis for awhile now).
I am looking forward to seeing the shape real time ray tracing takes on consoles, because I presume that will determine the true shape for the next decade or so.
I never really understood this argument. If you really need tons of frames for a competitive game, just turn it off. Otherwise, the games that implement it correctly show a marked visual improvement, that can't be computed any faster as far as we know. It's like saying 4k renders 4x slower than 1080p, so it's not worth it unless you can get the same frames. You can, it's just a premium technology and you'll need to budget accordingly.
(this ignores the games that half-ass their raytracing and make almost no perceptible improvement, which to be fair is most of them)
I do agree though, that Control (and Metro Exodus) are the best examples. Every other RTX title just uses it for reflections, which are neat but not as much of a categorical upgrade as RTGI, imo.
People who spend serious chunks of time gaming (but who also remember what reality looks like...) will increasingly notice the inaccuracy or lack of ambient occlusion and shading overall.
This time last year, RTX, in popular discussion, was a joke. I'm seeing more and more people who've looked into it, can see the objective improvement, and are ready to adopt it once as it enters their budget range. It would definitely be a sore sport if Navi had even worse raytracing performance than the RTX series, or none at all. As the hardware proliferates, there will be more and more reason to developers to look into implementing it at its best.
Crazy idea: Maybe we could train a neural network on before/after images of raytraced scenes and implement it with a constant, minimal penalty, like DLSS, or maybe that requires too large of a network or maybe it results in a trippy mess.
I think "if you need tons of frames" may be where your misunderstanding is coming from: most of us don't have tons of frames to give (especially in brand new AAA games that are the only ones implementing this technology).
For most people (and you can see this in sales data and hardware surveys), if they are looking to buy a new graphics card they are going to be buying one that they think will fit their needs for the next few years, not massively overshoot it. If you play games at lower than your monitors resolution, they look bad. If you play games at lower than your monitors refresh rates, you either get bad looking tearing, or lose a much larger proportion of frames than you need to.
To use myself as an example: I recently upgraded my computer that runs on a 3440x1440/60 monitor. My goal was to play games at 1440p60 for the next 3 years (ie until the new console generation settles and we know where things are going). I bought a 5700XT because it provided the best bang for buck, hit 1440p60 in most games benched, and it seemed reasonable that I could drop setting here or there and maintain good frame rates until I was done with it.
The nVidia option was a 2060S / 2070, which would have given me slightly more frames at 1440p, but for $50 more. If I wanted 1440p60 and RTX, I would have had to go all the way up to the 2080ti, which was roughly double the price.
Especially because it's probably first person and over-the-shoulder games that probably get the best benefit from RTX, but those are the same games where a high frame rate improves playability the most. Not 'tons' of frames to be 'competitive', but 144Hz to be able to perform the actions you intend to perform without frustration. So at that framerate, in a pretty game, maybe you could run RTX at 720p? But resolution is pretty nice too, so the performance hit really is a big deal.
The kind of game where you'd get 300Hz and can burn frames on a whim isn't the kind of game that uses RTX, at least so far. Or you'd have to drop the other settings to low, which kind of defeats the point of improved visuals.
AMD could really gain a huge advantage(both in enterprise and in more consumer spheres, like gaming/media production) by opening up the development of drivers and software libraries to the interested folk.
So far they have done this (arguably) very well on Linux(by comparison to nvidia),yet the ecosystem of nvidia is still very big by comparison.
While it's true nvidia has invested hugely in their development ecosystem, AMD could gain some territory by integrating their software compute libraries(like RocM) in programming languages like C/C++/Python and libraries like Tensorflow,pytorch,etc. could gain them a huge advantage in multiple industries.(I personally would argue this should be done firstly for their very successful and potent CPUs)
OpenCL has been truly great and it still a go-to when you talk about massive heterogenous systems, but they should abuse the fact that gaming cards could accelerate similar compute workloads.
Even if done only on the cloud I can see more could providers investing in their own TPU-like hardware for their clusters.
So if AMD’s there in two years or so the software caught up at roughly the same time.
I thought modern GPUs had hundreds of cores, or is a compute unit something different?
AMDs GCN architecture runs 4 threads over 4 clock ticks natively. I forget if it was vertical SIMD or horizontal SIMD or whatever the proper terminology was. But this 4 threads over 4 clock ticks avoids the register stall issue. (RDNA performs 1 thread per clock tick and schedules around the stalls)
The other threads come from an SMT-like / hyperthread-like feature, allowing 10 hardware threads per slot.
All together, a compute unit supports 16 way SIMD per vALU x 4 vALUs per CU x 4 threads over 4 clock ticks x 10 'hyperthread-like' = 2560 hardware threads (over 4 clock ticks)
16 SIMD x 4 clock ticks gives your 64 sized wavefronts / warps that the programmer works with. The majority of the 'threads' are for latency hiding: work the GPU can do while waiting for RAM to respond. (In contrast to a CPU, which will search ~200 instructions out of order for work while waiting on RAM)
The best they are claiming with Big Navi is 30% faster than a 2080 Ti. Sounds great, but they are comparing a card that won't be available for a year with a card that has been on the market for over a year already. Nvidia will have been working on faster stuff, and the best case for AMD is that they force Nvidia to release their next generation of products faster than they originally planned.
This isn't the same case as Intel which had been struggling with their 10nm process and security issues, which meant their current chips actually slowed down and they didn't have any new answers ready when AMD came out with Zen 2. We have seen that Nvidia has an answer for everything that AMD has done so far (price drops and Super variants to make the Nvidia cards remain the best choice at every level), and likely has an answer for their next few steps. I think the best that AMD can hope for is to achieve parity, they certainly won't be dethroning Nvidia.
What I think will be great for consumers is AMD releasing a good competing offer in a similar timeframe as Nvidia releasing their next generation. That may limit the Nvidia price increases, because over the past few generations they have gone up a lot for their top offering. And even a year after release they're still high. That can't stay like that if the next gen mid range AMD has higher performance.
PlaidML got acquired by intel, but looks like amd support is still included.
I wonder if I can convince our hpc people to buy some Mac Pro racs
I guess mini ITX is a niche market.