AMD Radeon RX 6800 and RX 6800 XT Review
overclock3d.net
overclock3d.net
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.
(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.)
Also some issues with hardware acceleration in Firefox, glitches in IDEA IDEs, etc. Also 3 monitors configuration sometimes end up messed up...
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.
[0] https://www.phoronix.com/scan.php?page=news_item&px=MTU4MTI
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.
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.
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.
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.
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.
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.
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.
(This is a blocker for me as well.)
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.
This is great news. I really wanted to build a virtualized AMD machine but I had _so_ many issues around this.
> Meanwhile Nvidia also removed the "error 43" limitation
Interesting - do you have a reference for this? I've been waiting on this for ages.
I need to test it on my 3090.
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).
+1 THIS!
The linux 5.10 kernel will support this new series.
Which does not mean that the cards are bad or worse! They are just not better in that category than in other categories, like 4K gaming.
On the other hand NVIDIA supports cuda on basically every gpu...
If you want to expiriment with gpu programming there is (sadly) no way around nvidia
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.
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.
Of course that's just for this year (which is ending soon), but there is also no commitment at all to ever supporting NAVI.
https://github.com/RadeonOpenCompute/ROCm/issues/1180
I think the article you mention only says tha openCL works on those cards.
> " 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 ..
https://github.com/RadeonOpenCompute/ROCm#hardware-and-softw...
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?)
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.
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.
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.
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.
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.
They don't. GOOG rents them.
https://cloud.google.com/terms/service-terms Service Specific Terms -> AI and Machine Learning.
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.
Obvious disclaimer is obvious: IANAL.
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.
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.
Provided that I'm running Linux, and I want to do ML, should I get current-gen AMD Radeon or NVidia GeForce?
UPD link to GitHub issues:
> 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.
"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."
Typically you have to wait some time after launch (e.g. 3-6 months) before AMD gets their Linux drivers into a stable state.
Colab is free. Colab Pro is $10/mo. GPU instances give you access to better hardware and don't lock up your machine for hours/days at a time.
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 ;)
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.
CPUs are not faster, in fact they are several orders of magnitude slower for these operations.
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.
If it becomes serious, rent cloud systems so you don't have to do all the maintenance.
Google doesn’t sell any hardware for ML training, but they offer Cloud TPU as a service for that.
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, ...).
Also the previous generation RX 580 cards were very stable.
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.
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.
Performance is pretty good, raytracing not good at all, and no extra features like DLSS and RTX voice etc.
Edit: A friend of mine who streams informs me that AMD's encoder/s are apparently still pretty bad
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.
Their website literally just says "contact your developer relations contact".
And then can be broken with any patch, might not work with mods or modified shaders, etc.
The point of that restriction was that RTX Voice would run on the tensor cores when gaming, not affecting gaming performance.
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.
The top end cards already cost about 5x what they used to cost some years ago.
What do you want? GPUs at 5000 USD each?
Did not get a gpu.
Currently why would anyone buy AMD for $50 cheaper? You get nothing bundled with it and AMD's tricks are shit and their software is flaky.
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.
I want to like their cards but they just don't seem to be able to balance the seesaw across all fronts
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.
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.
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.
But yeah, my next PC will prob. have the power to software-encode. Are you sure about the lower latency though?
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.
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.
[0]https://linustechtips.com/topic/1137619-motherboard-vrm-tier...
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).
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.
Now I understand why NVIDIA was so quick to rush and fumble their 3000 series card launch.
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.
Apparently the 3060 with ray-tracing on and DLSS on beats the new consoles by a landslide.
Quite unfortunate to have consoles with ray tracing hardware that you cannot really use if you want to play at a decent FPS rate.