Looks like a good card. RT performance is mediocre, not that I mind much. Relying on L3$ doesn't appear to have affected tail latencies, but I'll look to more detailed reviews. Availability is a concern. The real launch is on the 25th when partners can release their cards. I'm sure they'll sell out quickly for 2 months.
Edit: I should say that I recommend Gamers Nexus for really detailed reviews, despite being mostly video these days. They are really serious about their methodology. They have detailed information about quality of life things like power draw, fan speed ramping, noise, noise-normalized thermals, etc. They go overboard with cold plate flatness and mounting pressure measurements, teardowns, and PCB VRM analysis for the electrical engineers/overclockers out there.
I'll second that Gamers' Nexus recommendation. They do insanely rigorous reviewing and take all the ethics of being a trusted review source extremely seriously. Aside from CPUs and GPUs, they're also about the only people I know of who do actual, detailed airflow etc. testing of PC cases.
In addition to all these numbers, AMD also finally fixed the GPU reset bug with 6800 cards[1], which is huge for those of us running GPU passthrough to a VM as a BACO workaround kernel patch is no longer needed. Possibly going to be more stable on Linux as well as the card can recover itself from crashes. Big Navi also has its driver upstreamed in current 5.9 kernel so no more first day disaster like Navi.
(Meanwhile Nvidia also removed the "error 43" limitation when it detected the card is being run in a VM, so VFIO scene is getting a lot more interesting in this generation.)
I think that, for my use case, it would be a good combo to put both an Nvidia card and an AMD card in the same Linux machine, using the AMD one on Linux and spinning up VM guests using the Nvidia card for Windows gaming or for ML work. This way I can use Wayland (especially the Sway window manager) for my development workflow while being able to use CUDA and stuff.
Wayland still not ready for daily use. Over last few years I tried it several times with Kubuntu and KDE Neon and every time stuck with issues latest of which was impossibility to make Virt-viewer client work properly on 85Hz.
Also some issues with hardware acceleration in Firefox, glitches in IDEA IDEs, etc. Also 3 monitors configuration sometimes end up messed up...
That's almost as much an over-generalization as saying "PC is not ready for daily use". Wayland is a protocol (or even a family of protocols), kwin is one specific compositor which implements it (and the implementation is still far from being complete from what I hear). I've been using a different compositor for about a year now, and I don't miss Xorg one bit.
Sucks to hear that I've been exclusively using a compositor that wasn't ready for the last 8 months. Sway is the best desktop computing experience I've ever had, "ready" or not.
No proper screen sharing through any mainstream videoconference application is a killer for work. (0)
chromium doesn't support wayland yet, so it is blurry in HiDPI displays with scaling (chromium-dev does, but it has so many bugs it isn't even funny). As a consequence, all electron apps end up blurry... of which there are many.
Same applies to all apps that don't support Wayland yet. For example, I spend 90% of my time using Emacs, and it is blurry on Sway if I enable HiDPI scaling.
---
So sure. If you don't have a "modern" HiDPI monitor, and if you don't need to screen share often, and if you don't need to use chromium for work, or any App that doesn't support wayland yet, like all electron apps, Emacs, etc., or your work involves ML, or you want to game, or have an nvidia graphics card, which sway does not want to support (as opposed to gnome and kde), and you don't want to buy two GFX cards, or if you have to do screen sharing, or probably another dozen other things that most users need to do occasioanlly, or even every day. Then, and only then, Sway might be for you.
But you can also use i3, where all this stuff just works.
---
(0) I've seen people creating virtual webcams using OBS studio to capture their screen and share it as their "webcam" in videoconferences, but no mainstream software really supports this "as screen sharing", so the quality is quite bad, in a meeting with 10 people everyone needs to pick the webcam because the apps don't support this huge hack, etc.
FWIW, the thing about HiDPI being blurry is partly design difference between X11 and Wayland, and partly design decision on sway part (to not support this scenario). Having X11 and Wayland applications in HiDPI means having to handle two DPI in a single screen (e.g. sway have to render Xwayland window at 1x, while other windows at 2x).
This can be quite tricky since Xwayland's DPI may not always equal to `display DPI * Wayland scale` and while DPI settings in X is global, scale settings in Wayland is per-output. GNOME for instance has HiDPI working for both Xwayland and Wayland windows but with lots of magic going on with the framebuffer. HiDPI for X window in Plasma is still in the works AFAIK.
All the things you mentioned are already fixed and most have had reasonable workarounds for a while. Some are still working their way through the distros so it's still a work in progress in places but it also has unique upsides from the Xorg experience.
> All the things you mentioned are already fixed and most have had reasonable workarounds for a while. [...] Some are still working their way through the distros [...]
Can you back this up ?
Because I can back this up that this is not the case.
* Neither Chromium nor Firefox properly support wayland yet and have a lot of bugs. Fedora ships a patched version of Firefox to workaround some of these issues, so does arch, but none of this is properly fixed. Chromium-dev + patches does not handle multiple displays with different resolution (text is in the wrong position, toolboxes are wrong), it is not able to share a full screen (shows up as black), etc.
* Emacs does not support Wayland yet. Some users have some patches no enable GTK3 wayland support, but these work badly with Wayland/Sway, not properly recognizing input devices (e.g. Delete key recognized as Backspace is the classic bug for this). Users using these have to remap their keyboards every time they start emacs.
* Point us to one Electron app with Wayland support please. Just one. Go ahead. I'll go sit down, and wait, in case you need to wait for any to be released, maybe next year, or the year after that. Whatever the "Year of Wayland" in the Linux desktop will be.
* Can you share a screen shot of the Zoom or Webex videoconferencing software (the native packages) on Sway sharing monitors ? If not, don't worry. Can you share a screen shot of using their crappy web versions through any official browser release (unpatched) sharing full monitors through screen sharing?
- I've been using Firefox as Wayland native for a long time now. It works fine, certainly better than in X. I use the version as shipped by Ubuntu with no changes. Initially there were some bugs but haven't had any that are Wayland specific in a while. Chrome has recently enabled Wayland support in the release builds. I've only briefly tried it in that mode so I don't know what bugs it may have.
- Emacs is X-only because of the way it's built, that will take a while to fix. But XWayland works fine. The blurryness with HiDPI is fixed by a workaround in XWayland. I haven't used it myself because I don't use either emacs or fractional scaling but the solution exists.
- Electron is now getting Wayland support with the new versions but it's not needed to use those apps. I use Microsoft Teams daily in a HiDPI screen even. It works fine under XWayland and even has a setting to change the size of the interface if wanted. Everything but screen sharing works.
- Screen sharing with pipewire exists and works in both Firefox and Chrome, it's still going through the channels to be available in distributions. The first workaround is sharing a tab instead of a screen in Chrome. That has always worked fine and I've used it extensively for presentations. The full workaround is that Chrome under XWayland is also able to share any other XWayland window so it's possible to create a fake output, connect to it using a VNC app running under X and share that app. Complete hack until we get proper pipewire support from Electron apps adopting newer Chromium. Don't know about Zoom and Webex but if those support X sharing the same hack works and if they're native apps they also need a pipewire patch.
If you're happy with your Xorg session then by all means stick with it. Quips about year of the Wayland desktop are actually quite appropriate as they're the same as the complaints about year of the Linux Desktop. For me the year of the Linux Desktop was over 20 years ago, and I've been taking advantage of it ever since. The year of the Wayland Desktop for me was this year, as even after dealing with the rough spots I've gotten quite a bit of value from the transition. If you use different apps or have different requirements you may want to wait more, no one is forcing you to switch. Complaining online that your use cases aren't solved to your satisfaction in open-source projects is a bit much in my opinion.
Genuine question, from a users perspective what are they?
The couple times I've used it, I ended up going back to xorg because it turned out something didn't work (intel integrated graphics) right. Its sorta become a habit now.
HiDPI displays is what I see mentioned the most. But when you then ask if fractional scaling works on Wayland, the answer is "yes, but it doesn't work for any app you actually use".
If all you want to do is download a "demo" terminal, and put it in a HiDPI display, and enable fractional scaling, to show it to your friends, then yes, this works.
If you want to get some work done on any app (a text editor, web browser, ...). Then its worse than Xorg at the moment.
Totally unrelated, but I refuse to buy an HDPI monitor until someone makes one at a resolution that can use integer scaling. Fractional scaling will _never_ look good. Even Apple, who controls their entire stack, doesn't like fractional scaling and exclusively makes monitors and displays that support 2X scaling. Everyone looking for good fractional scaling support is going to be looking for a very long time, no matter what compositor they use.
Apple does fractional scaling in all their laptops. And the reason it doesn't always look great is that everyone has decided to do integer scaling and then scale down for fractional scaling instead of just rendering at the destination resolutions. Most things you care about for sharpness are already resolution independent (fonts, images) and would just work. Both Chrome and Firefox already render the whole browser in a resolution independent way but end up being rendered at 2x and scaled down for less sharpness and performance than just asking them directly to render whatever window size and scaling factor is needed. Hopefully Wayland will end up fixing this IMHO bad decision.
To avoid all this right now it's possible to just pick 1x or 2x and tweak font sizes to get a good mid-step. For a single screen this always works, but it makes combining different ones harder.
This is false. I can and do set whatever scale factor I want for each screen in sway and all apps are scaled correctly. This includes my browser, my text editor, my terminal, word processor and spreadsheet. There's literally no app I use where I have a problem.
All apps I use have a problem. Slack, Zoom, Chrome, Emacs, LibreOffice.
The only app I use that doesn't have a problem is Alacritty, which is the terminal emulator I kind of have to use to avoid this problem. Other terminal emulators I've tried do have this problem.
Anything that's GTK and Qt based will definitely be Wayland native and thus not have the XWayland issue with fractional scaling. So Libreoffice works fine and so does gnome-terminal. I use those daily. If you have problems with those there's something else wrong.
For the other examples it's probably XWayland scaling at 1x and then being scaled up instead of 2x and down. The patches to fix that exist but I'm not sure where they're already merged in. All those apps except Emacs should go Wayland native in the next few months though.
But right now, most GTK apps are not Wayland native and look bad on Wayland. Those that are Wayland native have so many bugs on Wayland that they are still objectively significantly worse than their Xorg alternatives.
That's not what I was saying. To clarify, everything that's GTK and Qt is already Wayland native and scales just fine. It's also not true at all that everything is full of bugs and unusable. In fact I can only think of a single Wayland-specific bug in a GTK app, and it's already fixed.
The biggest for me is actual tear-free rendering. All the different hacks in Xorg have never worked completely.
The other one that people value a lot is HiDPI scaling done "well". Mixed fractional scaling in Xorg doesn't really work and it's finally possible to do it. Although there I actually think it's still a half step and Wayland made the wrong choice in how to implement it. It should have been done client side for more performance and less fuzzyness. There's a chance that will also be fixed in the future.
Other than these it's a bunch of small things that are more technical than user-visible. Security is much improved for example. Some performance gains can be had from avoiding copying buffers. Etc.
Sadly sway seems very very Linux-centric. It depends on a device-enumerator that ships w systemd, which is quite an invasive prerequisite.
I’m playing/hacking w swc[0] on NetBSD, and I’ve worked out my daily-driver, which to be clear, is actually fit for ~nobody in the grand scheme, because it’s essentially just multiplexing terminals.
Right now it's reported by Linus Tech Tips[1], but I don't think I've seen anyone in the /r/VFIO community tried it yet (partly due to availability). I'm very curious about this as well and might as well get one and try it myself...
I'm full VFIO on an RTX 2060 max q and it's actually great. Error 43 is annoying but there are already workarounds - namely, certain VFIO settings (`vendor_id` in hyperv, and -laptop only- adding an acpitable to emulate battery).
AFAIK, RX 580 is the only exception for anything newer than Hawaii that doesn't have the reset bug (and only from certain vendor, Sapphire RX 580 I believe).
The cards have a very first gen Ryzen feel. There's nothing they just clearly do better than the competition(except having more memory, which is kind of indirectly is analogous with Ryzen generally having more cores than the Intel chips in the same price tier), and still somethings they do a bit poorly in, but AMD is no longer embarrassingly behind. Of course this may not pan out the same way as Nvidia isn't up against the same kind of wall Intel was in the CPU market, so AMD might have a tougher time keeping up, but I'm hopeful that competition is back in the GPU market and will stick around.
>There's nothing they just clearly do better than the competition
As far as I can tell, they're doing better at power efficiency, open Linux drivers, performance vs price and availability (stocks instantly ran out, but their supply chain is supposedly much better).
The article pretty clearly says ROCm OpenCL. As I understand, support is not all or nothing, so it's possible it works without being officially supported. However, I think you're correct we'll have to see what Phoronix and others report about the level of support and see what works.
> " While Radeon Open eCosystem (ROCm) support wasn't a focus for the initial Radeon RX 5000 "Navi" graphics cards by AMD engineers, that is fortunately changing for both the RX 5000/6000 series moving forward. "
Rocm seems to be supported, works with PlaidML, I wonder if PyTorch works ? That's the main framework I really need ..
The best way to get Pytorch working is to use the rocm provided docker images: https://hub.docker.com/r/rocm/pytorch. Unfortunately it doesn't seem like the latest GPUs are supported (yet?)
In addition to what the sibling comment said, OpenCL runs on the ROCm stack for RDNA1/2. That means all the low-level plumbing, drivers and software should be in place.
You are right for now, but Julia already has an experimental ROCm stack. Rolling out full featured ROCm support could be a huge win for Julia user growth (and AMD).
People were (rightfully) complaining about OpenCL the most because of applications like Blender, so it's not surprising they highlighted it. Since the OpenCL implementation on question is built on ROCm, it may be that other ROCm-related stuff works as well.
My impression from the various comments left by devs on Phoronix and elsewhere is that they've just managed to right the boat on the GPU side of things and are getting enough from their enterprise/HPC offerings (which they were solely focused on, to the detriment of all us consumers) to have some bandwidth to start tackling consumer compute support. I really hope they do so, because all the ROCm ecosystem could use some major TLC. Who knows, maybe this time next year you'll be able to install PyTorch with AMD GPU support OOTB.
One big reason why I buy AMD hardware is John Bridgman who actively participate in discussions about their hardware and drivers as well as long-term vision toward open source. So I believed in AMD and supported them for years (and actually made nice profit on their shares growth).
To be honest I don't really need compute all that much other than for my own hobby projects. And for gaming I only play few games what suite my taste as well as tons of older or indie games that would work on any GPU. So why not, AMD open source drivers are decent anyway.
Unfortunately it's hard to really recommend AMD GPUs when it's come to the real world experience. Modern gamers actually want all these lock-in features even if Nvidia gonna abandon them in couple of years. Then people who need compute for their work just want their software to work and it's simply too much of mess on non-Nvidia hardware.
That's just compute shaders in DirectX. They also support compute shaders in Vulkan and OpenGL.
It's not exactly the same as Cuda and OpenCL. Especially the numerical precision requirements are way off on graphics apis. And by way off I mean they're not always even specified what they should be.
Basic fp ops like +-*/ are fine generally. It's more about the ability to prevent reodering of instructions (so that Kahan summation etc is not screwed up), and having well defined spec for the precision of things like transcendental functions. HLSL is bit better at controlling this than GLSL is.
It has also improved greatly. Using workgroup shared memory is now a thing. And also one can use subgroup ops that have been in Cuda for years.
Some of the other things like commandqueues are in Vulkan and DirectX12. But oh boy those are pain to program in compared to OpenCL or Cuda. Usability matters too.
GPUs don’t reorder, their EUs are way too simple for that. Are you certain GPU drivers reorder instructions while recompiling DXBC into their microcode?
> HLSL is bit better at controlling this than GLSL is.
BTW, if you compile acos() in HLSL and disassemble the output DXBC, you’ll see a really strange sequence of 10 instructions (mad, mad, mad, add, lt, sqrt, mul, mad, and, mad) . The precision is indeed lost that way. Still, if you really need that, you can implement full-precision stuff on top of what’s available.
> Using workgroup shared memory is now a thing
Was always there. CUDA 1.0 was released in 2007, D3D 11 in 2008.
> But oh boy those are pain to program in compared to OpenCL or Cuda.
D3D 12 is a pain to program in general, too low level. But for GPGPU, I personally never needed command queues, I’m quite happy with old-school D3D 11. Despite the API is mostly single threaded, with some care you can do stuff in parallel. Things like ID3D11DeviceContext::CopyResource are asynchronous, you can go quite far with deeply pipelined commands without doing it manually like you have to in D3D12.
Compiler does the reordering. Not the GPU itself. Even in OoO CPU’s the ordering by HW doesn’t affect FP results. As a rule of thumb shaders in graphics are compiled as if one had passed -ffast-math to the compiler. Works perfectly in most cases, but not everywhere.
Nowadays MS has actually published the spec for DX that was closed previously. See https://microsoft.github.io/DirectX-Specs/d3d/archive/D3D11_... for differences of strict IEEE behaviour. In Cuda and OpenCL one can get way closer. As an example for performance reasons one might want to flush denorms to zero. But DX mandates that. So no denormals for you. In CL and Cuda they’re usable by default.
As for the command queues. I’ve often used them in Cuda. Just to get overlap between kernel executions. In DX12 one can do that by omitting barriers. DX11 allows no such feat.
It does, but you can always disassemble the DXBC and see what happened to your HLSL code.
> DX11 allows no such feat.
ID3D11DeviceContext::Dispatch is asynchronous just like CopyResource. Dispatch multiple shaders, and unless they have data dependencies (i.e. same buffer written by one as UAV and read by the next one as SRV) they'll happily run in parallel. No need for manual shenanigans with command queues.
> It does, but you can always disassemble the DXBC and see what happened to your HLSL code.
And you can always disasm X86 code and see what -ffast-math did. Doesn't mean that everyone would be fine with just mandating it everywhere with no option to disable it.
Even then the DX functional spec gives some leeway. As an example if you write x*y+z it will compile it into mad instruction. And that's just specified as that the precision must not be worse as the worst possible ordering of separate instructions. So which it is? Depends on the vendor. This is completely fine for graphics, but not fine for all workloads.
> No need for manual shenanigans with command queues
Unless you do access same buffer from multiple places in a way that's still spec conformant, just in a way that the DX11 implementation cannot detect.
> Doesn't mean that everyone would be fine with just mandating it everywhere
Practically speaking, often I enable it everywhere even on CPU (or similar options in visual C++). When more precision is needed, FP64 is the way to go. Apart from rare edge cases, you won't be getting many useful mantissa bits in these denormals, or with better rounding order.
> So which it is? Depends on the vendor.
Yeah, but on the same nVidia GPU, I'm pretty sure mad in DXBC does precisely the same thing as fma in CUDA PTX.
> just in a way that the DX11 implementation cannot detect
It doesn't detect much. If you want to allow shaders to arbitrarily read and write the same buffer, bind that buffer as UAV and you'll be able to run many of these shaders in parallel, despite a single queue.
P.S. AFAIK the main use case for these queues is high-end graphics, to send relatively cheap GPU tasks at huge rate (like 1MHz of them), from many CPU cores in parallel. In GPU compute, at least in my experience, the tasks tend to be much larger.
NVidia's advantage is the tensor units. Not just software but also hardware.
MI100 finally brings hardware accelerated matrix-multiplication to the table (bfloat16, FP16, and even FP32 matrix multiplication).
Now that MI100 has matrix-multiplication units, now comes the part where that is distributed to the software. (Hooking up TensorFlow to use them).
--------
Without Matrix Multiplication units, there was really no point even writing software (aside from maybe preparation of the eventual rise of AMD's matrix-multiplication routines).
But 6800 XT won't have matrix-multiplication units. Only the CDNA architecture has those. So I'm not entirely sure if 6800 XT would even be an adequate competitor to deep learning applications, even if ROCm supported it entirely.
It's got nothing to do with hardware, so far NVIDIA has been the only vendor to take deep learning seriously. AMD GPUs have at times been the best on paper for DL but always lacked real software support. A low cost 16GB card could be very useful but their strategy doesn't appear to have changed so today NVIDIA is still the only option.
And get sued by Google? You aren't allowed to use them to train anything that could compete with Google's business or products as part of the usage agreement.
Citation? I did a little digging of my own, because I found this claim to be uncharacteristic of any company I've ever worked for. I did find some restrictive clauses, but I don't think they are as broad as you are suggesting.
You can't use Google's fully-trained models as a reference in order to train your own models. Lower-level uses of TPUs to train your own models from your own training data are unrelated to those restrictions.
Certainly nothing in the Acceptable Use Policy looks anti-competitive to me.
So is the only reason to buy TPUs to learn about them and go work for Google or something? Why sell them if you can't use them for anything (as Google considers anything computing to be under their domain).
Amazing how we can go from "one billion calculations per second" being an incredible marketing claim [1], to components hitting 20 teraflops...in just 20 years.
My dad was an electrical engineer and used to keep a cutout of a press release from a company. It announced the company's production of its billionth transistor.
I really wish I still had that. I don't remember the company or the date. But it's incredible that we've gone from a company's total lifetime production of an item to now selling more than that amount in every single chip.
I'm running a desktop Linux, and I'm planning to have a dabble with NLP and machine learning. I do some ML-related stuff at work, but I don't have any actual hands-on experience about neural networks or modern NLP.
Provided that I'm running Linux, and I want to do ML, should I get current-gen AMD Radeon or NVidia GeForce?
> Provided that I'm running Linux, and I want to do ML, should I get current-gen AMD Radeon or NVidia GeForce?
If you want maximum flexibility and least time wasted, go with NVIDIA. Most models, Github repos, papers, online questions - are on NVIDIA and the authors probably never bothered with any other architecture.
As posted before by other person in this topic AMD don't currently support ROCm on consumer hardware. So you won't be able to run anything that is built for CUDA on these new cards.
"One big benefit of using the packaged driver: working ROCm OpenCL compute! OpenCL compute benchmarks on the packaged driver are coming in a separate article today. The OpenCL/compute support for Radeon RX 6800 series is working and better off than the current RDNA 1 support. It's great to see things working in the limited testing thus far. Presumably for the imminent ROCm 4.0 release they will also have the Big Navi support independent of the packaged driver, but in any case great to see it coming."
> One big benefit of using the packaged driver: working ROCm OpenCL compute! OpenCL compute benchmarks on the packaged driver are coming in a separate article today. The OpenCL/compute support for Radeon RX 6800 series is working and better off than the current RDNA 1 support. It's great to see things working in the limited testing thus far.
>>> If you want to dabble; use the cloud. Colab is free
Colab notebooks are proving to be one of the most incredible resources out there right now. I liken it to the "free tier" cloud vm / app engine / heroku of a decade ago ;)
No, its not really the same - but the parent is "planning to have a dabble with NLP and machine learning" so my guess is HuggingFace/SpaCy/PyTorch/Tensorflow/FastAI are more the consideration than touching CUDA directly.
Without question, nvidia. The sad reality here is that the best performance for ML on a 5700xt is to boot into windows and use the beta for directml under WSL2 with TF1. It pains me to say that as someone who has been a linux purist for over a decade. We’re literally just waiting for AMD to release blobs, and we’ve been waiting over a year.
It's just a historical fact that GPUs originally evolved to do graphics. What to they're really good at is doing a huge amount of numerical computation in parallel, of which graphics is just a specific use case, and is exactly what you need for ML. If they were invented today, they would be called something else. They're already the specialized hardware you're describing.
> Wouldn’t it make more sense to let the CPU do it, or have specialized cards for the job. So you could have an AMD graphics card and an Nvidia ML card.
Graphics cards are the specialized cards for ML. They are several orders of magnitude faster than GP CPUs at ML because they are specifically designed for the mathematical calculations done in most ML.
We call them graphics cards because that was the first real general use-case for doing lots of linear algebra on large data sets. But long before CUDA came along, people were abusing graphics API to perform more general purpose high-performance calculations for things like video decompression or physics.
nVidia has good leadership and recognized that there would soon be a sizeable market for video cards as a cheap replacement for specialized hardware used in super computers.
Interesting tidbit, when I was in college, one of our CS professors invested in a cluster of PS3s as a cheap "super computer" as they were substantially faster at ML than anything else you could get for $600.
GPUs and also the specialized cards basically can do the same vector, matrix and tensor operations that are needed for neural network machine learning.
CPUs are not faster, in fact they are several orders of magnitude slower for these operations.
Google Coral is the name of Edge AI accelerator, which can be used only for inference meaning running already trained models to get results from inputs.
Google doesn’t sell any hardware for ML training, but they offer Cloud TPU as a service for that.
So for people who don't care about raytracing and want to play in 1440p, the 6800XT seems a good choice, my only concern is driver stability / crashes, AMD is not good at that?
I bought one after the big stability update and it was causing random hard reboots while sitting on the desktop (so not a power issue). May have been a hardware issue with the card. This was on a Windows system which previously had an Nvidia card which anecdotally seemed to cause issues, though I did run Display Driver Uninstaller in safe mode, etc. That being said it's hard to tell how many people actually had issues given how vocal people are when they do. I'd expect the vast majority of people had no issues.
Also the previous generation RX 580 cards were very stable.
I have a 5700XT, and there were driver problems on Windows where the screen would turn black while playing games and require a reboot. It could be fixed by disable FreeSync in the AMD software, but you shouldn't have to disable features for a card to work. They eventually fixed the issue with driver updates, but I think it took a few months. I also never had any issues with it on Linux.
I also have problems with 5700XT. I can't play some games without putting them at very low quality, although the specs of my machine are well within the recommended range. My computer randomly restarts if I am not at low settings. I have suspected overheating, but I have done what I can to fix it bar getting liquid cooling and I still have the issue. Very odd stuff. If anyone has suggestions, please let me know.
This sounds a lot like a problem with your power supply. When your graphics card starts working harder, it uses more power than your PSU can supply, which makes the voltage drop and causes the PC to reboot. I'd get a new PSU from a reputable manufacturer that is rated for more than the maximum combined wattage of your components. There are heaps of PSUs on the market that are advertised at a much higher rating than they can reliably supply.
> I'd get a new PSU from a reputable manufacturer that is rated for more than the maximum combined wattage of your components.
And "more" hear really should mean significantly more to have some buffer for peak power draw (which often is more than the rated power) because you are likely not forgetting some components (mainboard, connected USB devices, ...).
It's not bizarre. Driver issues with the 5000 series were widespread and widely reported. Hopefully the 6000 series doesn't have the same issues but who knows.
For whatever it’s worth it took a month or so for the 5700 XT drivers to be sorted but after that mine has been running with no troubles for over a year with a lot of different gaming and content creation workloads.
Same here. First month got daily black screens. After first update: only black screen in destiny 2. Next update. 0 issues that I’m aware of. No crashes.
For 3D video cards, I've gone from being a 3dfx diehard in the 90s, to Nvidia diehard, to AMD after they bought ATI, back to NV today. That's generally speaking, I've purchased and sold ATI cards and others in that time, and my list of GPUs is a long one. The end result? I do not have strong opinions on each brand. A hard truth is that too much changes over time to be brand loyal.
My most stable card was my Radeon 5870, I bought it on launch day and installed every single WHQL release on it that they ever produced. One game had an issue, but it also had the same issue on NV. I think I used that card daily for nearly 8 years.
I wouldn't worry about stability or crashing on a new Radeon card, but rather if the details about it meet what you need. How are you using it- CUDA, VR, 4K, etc. I still lean Nvidia but I wouldn't hesitate to purchase a 6800XT after looking into my particular needs.
Same thing applies to CPUs. You can't really go off benchmarks, you really would need to benchmark what you're doing with it to matter at all. If you can't afford to buy them all and test, then your use-case probably doesn't matter enough to even investigate, buy whatever suits you. For me, the 16GB included on these cards is very attractive but I'd need to do in-depth research on these new Radeons and their VR performance (which has tended to lean NV, but can improve over time) to make a final decision.
My take as someone who does light gaming is that the drivers are "pretty good" but not perfect.
I run Windows 10 and had my system on a Nvidia Geforce GTX 780 for roughly a year before buying an AMD Radeon RX 5600 XT this spring. During that time running the Geforce, I had no issues in or out of gaming.
Running the 5600 XT with the latest WHQL drivers, I have had one very recent game crash (StarCraft 2) but otherwise, just some issues with booting - instead of the Windows loading icon, I'd just get a white cursor in the corner of the screen indefinitely. I would have to hard reboot using the power button. Once it kept doing it and I caved and did a reset of Windows, having to reinstall programs. I've had the boot problem once since then, and the above game crash. I think it's very reasonable to believe these are driver issues.
If you're wondering, I didn't do a clean install, but used Guru3D drive cleaner between the Geforce and Radeon. And then I did do a Windows reset, and have had problems since, so I don't think it's reasonable to blame the driver issues on the switch.
I'm primary Linux user, but I run RX 580 in VM for gaming-only on Windows and in last 2 years it was really stable for me. I had much worse experience with older AMD GPUs and drivers.
I hate to say this: It's not that AMD needs a price drop, it's that nvidia needs a price hike. Clearly nvidia is not able to meet demand for their cards and so AMD is filling that gap at the same price point.
I'm not sure I agree with the price, but I agree with the sentiment.
Nvidia spent their years refining their drivers and building out a legitimately useful platform of tools that utilize their GPUs. At times AMDs base functionality in their drivers can be buggy and unreliable. Even if they can compute similarly AMD has so much ecosystem ground to try and make up.
This affects everyone who uses Steam Streaming (or Parsec) too, I don't know why reviewers don't test it regularly. Its a no-go for me then, the current H.264 encoder on AMD hardware is beyond terrible.
A lot of interest in hardware encoders collapsed with Ryzen's release in 2017. Software encoding is superior quality and latency to NVENC, and I've been using 8-thread encoding for Steam streaming since then (April '17) never to look back.
If you don't have or want to use the CPU grunt for that, Intel Quick Sync isn't bad and a good pair with a Radeon like the 6000 series. If you want hardware encoding, Intel CPU + AMD GPU is a great pair, as is AMD CPU + Nvidia GPU. Otherwise anything works well with sufficient core count, can go AMD/Intel CPU + AMD GPU.
NVENC does have lower latency than Intel Quick Sync, NVENC > Quick Sync in all regards. I'd be ok with using Intel Quick Sync though, the only one I would avoid entirely is AMD VCN. I haven't looked into or compared encoders since 2017 but the takeaway was that software offered the best in latency and IQ. Dependent of course on what software is doing the encoding. I focused on Steam.
I just dug up one of my sources for you, you'll enjoy this.[0] It may no longer be accurate but it's at least suggestive. They all have similar latency, but you'll see the in the longest delay results (my eyeballs always focus on worst-case), has the software encoder on top. I'm currently considering a 5800X (higher sustained boost clocks due to heat/VRMs) or 5900X (lower sustained boost but more cores for potentially better streaming) to upgrade my system.
Given an 8+ core system can encode so well, I'm fine with either a 6800XT or 6080. I really don't have enough information yet. For years I used to buy based on NV's OpenGL support (and after NV's Vista driver blunders, AMD), but since the Oculus Quest was released, my primary deciding factor is VR performance. NV has held the edge there historically, but 16GB VRAM for the same price is not to be dismissed outright. If NV will match AMD's 16GB at a similar MSRP I'd go that route, the GDDR6X would cut into their margins pretty good though so I'm not holding my breath. I find AMD's Infinity Cache approach so interesting that I'm leaning towards rewarding their innovation. It works so well while cutting costs means that their approach is probably the future for all GPUs.
Anyway, with this evidence you hopefully now have more hardware to choose from for your upgrade. I had a great luck with Nvidia for a long time (currently using Pascal), but zero good reason to be entirely at Nvidia's mercy these days. Radeons got a big bump in quality since AMD bought ATI and it'll continue to get better.
Hi. The results on that video do not reflect your comments; The software encoder is obviously inferior. Also those results are old.
I have also tried all the options and there is no comparison. It's a night and day difference between software encoding and nvenc. It was more than triple the latency last I tested.
I tested steam, parsec and also the best software available today for game streaming, Gamestream + Moonlight or Gamestream on the Shield TV.
Anybody would notice the difference in quality and input lag between QuickSync, libx264 and NVEnc. The difference really is very large in higher resolutions (talking about 1440p and 4k in 60/144fps).
> Hi. The results on that video do not reflect your comments; The software encoder is obviously inferior.
Well, you'd be wrong.[0] If you can provide timestamps or any sort of reference to backup your claim, as I have, that would help everyone. I'm not sure why you'd even respond if you're not going to bring any measurements or data.
>Also those results are old.
Yes, I was the first to point that out when I said they were from a few years ago, but still suggestive. The conclusion stands unless you have put together something as comprehensive for our review. I'd be happy to take a look at it since it sounds like you challenge the results. A comment on the internet is not good enough though to do that.
If you have all the hardware to test software vs QuickSync vs NVENC, put a video out there. Many would be very interested, but credibility matters and I fully trust Chris from Battle(non)sense on latency and IQ benchmarks as I've been watching his content and methods for years. Sweeping statements with no citations aren't enough to erase data. Not knowing the first thing about you, your competency or setup, my initial bet is that there's something wrong with your setup to possibly get worse results using software over NVENC. As I have also personally compared them, and my conclusions align with my Youtube source.
Thanks for the thoughtful response. I'll get an 5900X, as soon as they can actually be bought. RT and DLSS still make me lean towards Nvidia, but yeah the limited RAM is a bummer.
One more thing worth noting, research the VRMs on whatever motherboard you get.[0] Getting the wrong motherboard will hold back your 5900X. I generally buy Asus's higher end boards which is a safe bet, but my current Asus X470-i pretty much presents me with the choice between clocking higher or more cores. I'd have to get a newer board and don't want to.
I'm probably sticking to the combo you're looking at, AMD+NV. I generally prefer Intel for overall QA reasons, and I can attest that Ryzen was buggy up until today, but I still can't imagine going with an Intel system right now. My Ryzen 1800X, 1700, and 2700X systems were stable but I wouldn't call them plug and play.
I'm making my changes in January so supply should no longer be a problem. You might find it's worth waiting it out till then too, Nvidia may have a response to the 6800 series by then too. Rumor was they were increasing VRAM but cancelled the cards.
I was interested in Linus' take on the various software echo system Nvidia is building around GeForce that AMD doesn't have. In their video review today they specifically call out the quality (in a non-scientific way) of the hardware encoder. https://youtu.be/oUzCn-ITJ_o?t=561
There were 150 people waiting in line before the store opened on a weekday? Do you think they were waiting for the latest AMD GPU or that they were trying to get a new console for the holidays?
There was 100+ people in line at my local micro center, for what couldn't have been more than 20 cards total across models. No was in line for anything but the chance to buy these cards.
There's some degree of worry that 10GB on the 3080 is not enough for the high-end games of the future. NVidia made a mistake leaving a huge gaping hole between the 10GB 3080 and the 24GB 3090.
A 6800 XT fills that hole with a nice little 16GB.
Compute performance is fine. 20+ TFlops (or T-Integer ops) on 128MB L3 cache on 16GBs GDDR6. I don't think anyone can complain about the raw compute performance of these cards.
Infrastructure: yeah. Without ROCm support, its hard to recommend. You still get Windows DirectCompute, OpenCL, and Vulkan compute. But ROCm is much easier to use than those other frameworks.
---------
For compute: With 40 WGP x 4 SIMDs per WGP x 32 Threads per WGP x Occupany 4, you're probably aiming at 20,480 SIMD-threads if you're going to be using compute on this card.
Occupancy 20 is supported: 20-threads per VALU, kinda like hyperthreading although you split your registers between the threads. 20 is probably too much (too few VALUs per thread), but 1 is too few (you'll be waiting on VRAM latency). So 4 to 8 is an estimate for how much occupancy a typical program probably needs to hide memory latency.
Those 16GBs / 20kiloThreads == 780kB per thread. Sooooo... yeah. RAM goes quick... really quick... on compute applications. Compute programmers really want more VRAM.
I was able to perform a minor tweak to the installer to make RTX voice install with my GTX 1080, so I'm a bit iffy on calling it a real "feature" of Nvidia's cards when they're clearly artificially restricting it in significant ways.
I mean, there's couple different things here. There's things where Nvidia has clearly provided emulation for certain features - I for instance play Watch Dogs Legion on my 1080Ti with Ray tracing enabled and it runs absolutely fine(because the ray tracing is being emulated in CUDA and the 1080Ti is enough of a beast to do it quickly enough), or there are things like DLSS which don't have emulation - and there is no known official or unofficial way to run them on non-RTX cards. So it's not just an artificial limitation made up by Nvidia.
DLSS it is absolutely just a lock-in technology that have nothing to do with hardware itself. It's just neural networks that are trained per-game and included with the driver.
Nvidia did almost the same thing for years by replacing game built-in shaders with their own optimized for their hardware. Whatever you feel it's good idea to support Nvidia for this or not it's up to you of course.
DLSS 2.0 is not trained per game. Won’t comment on the rest of what you said but we have been public about the fact that DLSS 2.0 is not trained per game.
@SXX: They might want to QA the results on particular games even if not trained per game. And/or they may want the game publishers approval to meddle with how the game works/looks. And they possibly have royalty deals with the game publishers.
This is also possible, but problem with this QA and royalties is that it's the same PhysX situation all over again. Another lock-in tech that can only be used on Windows + Nvidia so it's barely going to be utilized.
And then can be broken with any patch, might not work with mods or modified shaders, etc.
If it wasn't trained per-game then Nvidia would just let you enable it for every game out there not just few new titles that still supported by developers.
Ugh......no, because it doesn't work without the data about temporal changes between frames being given to the driver, so no, it cannot be "just enabled for every game out there" - it does require specific support by the developer. I normally hate saying to people that they should just go and read more about it, but you should go and read more about it.
Okay I can be wrong. Do you have a good link that describe how it works? Otherwise I can't really guess what information driver could possibly need since it's already have all shaders and API calls.
Even if a bit of additional information is needed it'd be nice if this was made public and documented such that developers and modders could use it outside of those with tight nvidia deals.
Their website literally just says "contact your developer relations contact".
Very interesting to see if the 6900's will have a better value proposition than 3090 which seems to be just a waste of power with no real improvement on the 3080 (for gaming at least). Good job AMD - I'm very glad they have caught up on GPUs.
Comparing card at a particular resolution became meaningless when Control at 1080p with DLSS2.0 upscaling to 4k looks better than native rendering at 4k resolution.
I couldn't care less about being able to play games at 120 or 140 FPS, but I do care about image quality.
I wish these reviewers would compare the different cards at the same image quality at playable framerates (e.g. 60 FPS or 120 FPS).
It would then be interesting to see the performance of, e.g., a 3080 rendering Control at 1080p with ray tracing on and DLSS upsampling to 4k vs "whatever settings give the same image quality" for the RX 6800 XT.
If I wouldn't care about ray tracing or DLSS, I would probably be much better off buying a used 2080 Ti at this point. Sure, that would give me 40 FPS at Control 4k native vs 45 of the RX 6800 XT, but these 5 FPS aren't really worth 2x the price.
Unfortunately, from the reviews, it seems like those are really not well performing in ray tracing scenarios. This doesn’t bode well for these cards, but also for the consoles that use the same technologies. Console hardware doesn’t match 1:1, but it has been pretty close in the last generations’s four consoles.
Also, AMD has still to introduce a DLSS-type functionality, while nVidia’s has matured and is a great performer and looked with 2.0 and above. The advantages of being first to the market.
Edit: I should say that I recommend Gamers Nexus for really detailed reviews, despite being mostly video these days. They are really serious about their methodology. They have detailed information about quality of life things like power draw, fan speed ramping, noise, noise-normalized thermals, etc. They go overboard with cold plate flatness and mounting pressure measurements, teardowns, and PCB VRM analysis for the electrical engineers/overclockers out there.