Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

NVIDIA have revealed the GeForce RTX 3060 Ti officially today, along with a release date of December 2 and it sounds like quite an awesome card.

Hitting performance levels (and above!) comparable to the RTX 2080 SUPER, which for the price is absolutely amazing at $399 / £369 which is far less than the 2080 SUPER. When it becomes available on December 2 this will be as custom boards including stock-clocked and factory overclocked models from various vendors as well as a Founders Edition direct from NVIDIA.

Want some specs? Here's a comparison between the models of the 3000 series:

    GEFORCE RTX
3090
GEFORCE RTX
3080
GEFORCE RTX
3070
GEFORCE RTX
3060 Ti
GPU Engine Specs: NVIDIA CUDA® Cores 10496 8704 5888 4864
  Boost Clock (GHz) 1.70 1.71 1.73 1.67
           
Memory Specs: Standard Memory Config 24 GB GDDR6X 10 GB GDDR6X 8 GB GDDR6 8 GB GDDR6
  Memory Interface Width 384-bit 320-bit 256-bit 256-bit
           
Technology Support: Ray Tracing Cores 2nd Generation 2nd Generation 2nd Generation 2nd Generation
  Tensor Cores 3rd Generation 3rd Generation 3rd Generation 3rd Generation
  NVIDIA Architecture Ampere Ampere Ampere Ampere
  PCI Express Gen 4 Yes Yes Yes Yes
  NVIDIA G-SYNC Yes Yes Yes Yes
  Vulkan RT API, OpenGL 4.6 Yes Yes Yes Yes
  HDMI 2.1 Yes Yes Yes Yes
  DisplayPort 1.4a Yes Yes Yes Yes
  NVIDIA Encoder 7th Generation 7th Generation 7th Generation 7th Generation
  NVIDIA Decoder 5th Generation 5th Generation 5th Generation 5th Generation
Display Support: Maximum Digital Resolution 7680x4320 7680x4320 7680x4320 7680x4320
  Standard Display Connectors HDMI 2.1, 3x DisplayPort 1.4a HDMI 2.1, 3x DisplayPort 1.4a HDMI 2.1, 3x DisplayPort 1.4a HDMI 2.1, 3x DisplayPort 1.4a
  Multi Monitor 4 4 4 4
  HDCP 2.3 2.3 2.3 2.3
           
Founders Edition Card Dimensions: Length 12.3" (313 mm) 11.2" (285 mm) 9.5" (242 mm) 9.5" (242 mm)
  Width 5.4" (138 mm) 4.4" (112 mm) 4.4" (112 mm) 4.4" (112 mm)
  Slot 3-Slot 2-Slot 2-Slot 2-Slot
           
Founders Edition Thermal Power Specs: Maximum GPU Temperature (in C) 93 93 93 93
  Graphics Card Power (W) 350 320 220 200
  Required System Power (W) (2) 750 750 650 600
  Supplementary Power Connectors 2x PCIe 8-pin
(adapter to 1x 12-pin included)
2x PCIe 8-pin
(adapter to 1x 12-pin included)
1x PCIe 8-pin
(adapter to 1x 12-pin included)
1x PCIe 8-pin
(adapter to 1x 12-pin included)

As long as you're not going for 4K gaming, the GeForce RTS 3060 Ti seems like a winner, and would likely be exactly what I would be going for if I was going to be building a system. At 1440p and 1080p gaming, it seems ideal. NVIDIA drivers generally have good Linux support too, and we expect NVIDIA to have a fresh driver up either today or tomorrow to formally add support for it on Linux - like they always do with a new GPU release. We're never left waiting around. 

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link

Going by Phoronix benchmarks on Linux, it seems like performance winner. I get that technology moves on quickly but even so, it still slightly amazes me just how much performance and price has come along with cards like this.

The real question is: just how fast will stock vanish this time? It may be releasing on December 2, doesn't mean many people will actually be able to get one though like the last few new GPU release.

If you do buy one, NVIDIA are throwing in one whole year of GeForce NOW Founder membership too which is open to both new and existing GFN customers to sweeten the deal. With their plans to actually support Linux with GFN in the browser, that sounds good.

Article taken from GamingOnLinux.com.
13 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
77 comments
Page: «7/8»
  Go to:

slaapliedje 4 Dec, 2020
View PC info
  • Supporter Plus
Quoting: x_wing
Quoting: slaapliedjeHow is it unsupported if I install nvidia drivers from the debian repo? Unlike Ubuntu and their Universe / Multi-verse repositories, Debian supports ALL of theirs... one of the reasons Debian is superior.

So, installing a new kernel from Debian testing is unsupported but installing Nvidia drivers from testing is supported?
They BACKPORT kernels from testing to stable. https://packages.debian.org/buster-backports/linux-image-5.9.0-0.bpo.2-rt-amd64-unsigned Also backports for nvidia drivers are also enabled.

What I was saying is that installing them ARE supported You just don't WANT to have to install newer kernels unless you really need something in the new kernel, that was my point. The whole 'meh, let's swap out the kernel' should be more of a 'holy shit, you're forced to get a new kernel because you want a new GPU?' It should be like any other platform, you update the driver for newer card support, you shouldn't have to update your whole kernel. Not everyone can just do that, like if they have a workstation where they are tied to a specific kernel for business case (like nessus won't accept anything but the kernel version string to certify it's not vulnerable).
Not sure why people don't take such things into account when they say 'just update the kernel'.
Quoting: slaapliedjeI'm not, what I'm implying is that distros don't support AMDGPU Pro drivers within their distribution. Whether that is because they're too hard or because AMD doesn't let them, I haven't looked into. But nvidia clearly does allow distributions to put their drivers in repositories. Simple as that. Have you seen any distribution contain repositories with the proprietary AMD driver? If so, I'd like to know about them, as I haven't seen any. I mean let's hold both companies to the same standard, do they both allow repackaging of their drivers? Or are we stuck with the three distros they support (RHEL, CentOS, Ubuntu)? Even the open source drivers require firmware blobs, so the ones who are happy about that can't be 100% happy.

This just brings up the problem I stated in my last post, neither solution is 100% great. Nvidia just happens to have better distribution support as of right now. Unless you're using a rolling release (as you said, latest kernel) then you're shit out of luck for AMD.
Quoting: x_wingIf you don't want to imply that then you should probably start saying that Nvidia is better supported in your distro and that's it. And you don't need to have a rolling release. You just have to get the latest kernel and Mesa version if and only if you have the latest hardware, something you can do without a rolling release.
That's what we're talking about here, if you are going to get the latest hardware, you basically have to upgrade kernel / mesa instead of just letting your distro packages handle it. Debian Sid apparently already has the minimum (kernel 5.9.x and Mesa 20.2+ (may have been 20.1+ that is needed). But that IS a rolling release. Yes they have backports, but you'd have to 'prep' for stable and install that stuff before you pull out your old card and put in the new.

But the way nvidia and AMD do it with their proprietary driver is more supportable, as you don't have to muck with new kernels, and they package their own OpenGL/Vulkan libraries. DKMS is the correct way to go here. If your distribution breaks DKMS, that means they didn't test kernel+dkms+driver integration, and that's ON THE DISTRIBUTION, not nvidia or AMD's fault, right?

In the past, different distributions would end up patching flgrx to work with Xorg, or they wouldn't roll out new Xorg or flgrx drivers so as to not cause breakage. Now not all distributions have a large amount of testers / developers working on them, so some hardware support is simply lacking testing, and that could easily cause your system to not boot to a gui. But at least then (if you know what you're doing) you have a chance to try to fix it. A lot of times in the past, Windows would just crash, and safe mode is a pain to try to get a video driver working again....
Shmerl 4 Dec, 2020
Quoting: slaapliedjeI have been using nvidia for years, and it has pretty much been 'just works'.

I remember Nvidia breaking more than once due to kernel updates and I remember Nvidia messing up my install to the point of frustration and wiping out the whole OS to reinstall. Not upstreaming their driver has consequences. Ditching the blob felt very good and I'm not interested in going back to that horror :)


Last edited by Shmerl on 4 December 2020 at 8:10 pm UTC
x_wing 4 Dec, 2020
Quoting: slaapliedjeThey BACKPORT kernels from testing to stable. https://packages.debian.org/buster-backports/linux-image-5.9.0-0.bpo.2-rt-amd64-unsigned Also backports for nvidia drivers are also enabled.

What I was saying is that installing them ARE supported You just don't WANT to have to install newer kernels unless you really need something in the new kernel, that was my point. The whole 'meh, let's swap out the kernel' should be more of a 'holy shit, you're forced to get a new kernel because you want a new GPU?' It should be like any other platform, you update the driver for newer card support, you shouldn't have to update your whole kernel. Not everyone can just do that, like if they have a workstation where they are tied to a specific kernel for business case (like nessus won't accept anything but the kernel version string to certify it's not vulnerable).
Not sure why people don't take such things into account when they say 'just update the kernel'.

We are running in circles here. I previously mentioned that if you have a the requirement of stable kernels or workstations, you must stick to the officially supported distros (i.e. RHel/Centos or Ubuntu LTS) so you can use the dynamic module (and this appliers for both Nvidia and AMD). But lets be real, this discussion is about people that mostly use their GPUs for gaming so getting the latest kernel for the latest hardware is an standard requirement for a Linux user as GPU driver is just one of the many drivers you may need.

Quoting: slaapliedjeThat's what we're talking about here, if you are going to get the latest hardware, you basically have to upgrade kernel / mesa instead of just letting your distro packages handle it. Debian Sid apparently already has the minimum (kernel 5.9.x and Mesa 20.2+ (may have been 20.1+ that is needed). But that IS a rolling release. Yes they have backports, but you'd have to 'prep' for stable and install that stuff before you pull out your old card and put in the new.

Having to get the latest kernel or an specific library version is completely related to the fact that you bought the latest hardware. If you go bleeding edge with the hardware you will have to go bleeding edge with Linux, that's the way it works in our system.

And regarding of having to install your drivers before putting the new one, that's exactly what you have to do no matter if you have AMD or Nvidia (this is probably not 100% true with AMD GPUs, though).

Quoting: slaapliedjeBut the way nvidia and AMD do it with their proprietary driver is more supportable, as you don't have to muck with new kernels, and they package their own OpenGL/Vulkan libraries. DKMS is the correct way to go here. If your distribution breaks DKMS, that means they didn't test kernel+dkms+driver integration, and that's ON THE DISTRIBUTION, not nvidia or AMD's fault, right?

DKMS is a handy option but it's far from being the ideal solution for Linux as many things can go wrong during the build of the module (dealing with those errors will be quite hard for most users), not to mention that you force the user to install a building tools. IMO, from a distro maintainer POV it's probably far better to have everything in the kernel as this helps to avoid the maintenance of the dynamic module (one less package, one less headache).
slaapliedje 5 Dec, 2020
View PC info
  • Supporter Plus
Quoting: x_wing
Quoting: slaapliedjeThey BACKPORT kernels from testing to stable. https://packages.debian.org/buster-backports/linux-image-5.9.0-0.bpo.2-rt-amd64-unsigned Also backports for nvidia drivers are also enabled.

What I was saying is that installing them ARE supported You just don't WANT to have to install newer kernels unless you really need something in the new kernel, that was my point. The whole 'meh, let's swap out the kernel' should be more of a 'holy shit, you're forced to get a new kernel because you want a new GPU?' It should be like any other platform, you update the driver for newer card support, you shouldn't have to update your whole kernel. Not everyone can just do that, like if they have a workstation where they are tied to a specific kernel for business case (like nessus won't accept anything but the kernel version string to certify it's not vulnerable).
Not sure why people don't take such things into account when they say 'just update the kernel'.

We are running in circles here. I previously mentioned that if you have a the requirement of stable kernels or workstations, you must stick to the officially supported distros (i.e. RHel/Centos or Ubuntu LTS) so you can use the dynamic module (and this appliers for both Nvidia and AMD). But lets be real, this discussion is about people that mostly use their GPUs for gaming so getting the latest kernel for the latest hardware is an standard requirement for a Linux user as GPU driver is just one of the many drivers you may need.

Quoting: slaapliedjeThat's what we're talking about here, if you are going to get the latest hardware, you basically have to upgrade kernel / mesa instead of just letting your distro packages handle it. Debian Sid apparently already has the minimum (kernel 5.9.x and Mesa 20.2+ (may have been 20.1+ that is needed). But that IS a rolling release. Yes they have backports, but you'd have to 'prep' for stable and install that stuff before you pull out your old card and put in the new.

Having to get the latest kernel or an specific library version is completely related to the fact that you bought the latest hardware. If you go bleeding edge with the hardware you will have to go bleeding edge with Linux, that's the way it works in our system.

And regarding of having to install your drivers before putting the new one, that's exactly what you have to do no matter if you have AMD or Nvidia (this is probably not 100% true with AMD GPUs, though).

Quoting: slaapliedjeBut the way nvidia and AMD do it with their proprietary driver is more supportable, as you don't have to muck with new kernels, and they package their own OpenGL/Vulkan libraries. DKMS is the correct way to go here. If your distribution breaks DKMS, that means they didn't test kernel+dkms+driver integration, and that's ON THE DISTRIBUTION, not nvidia or AMD's fault, right?

DKMS is a handy option but it's far from being the ideal solution for Linux as many things can go wrong during the build of the module (dealing with those errors will be quite hard for most users), not to mention that you force the user to install a building tools. IMO, from a distro maintainer POV it's probably far better to have everything in the kernel as this helps to avoid the maintenance of the dynamic module (one less package, one less headache).
Thing is, and my point being, yku should NOT HAVE to go bleeding edge just to get a graphics card to work. With nvidia you do not, as most distributions package the drivers themselves. With AMD you will always be chasing the latest mesa libs or kernel, because distrubutions don't chase AMD. The proprietary drivers for AMD have been a mess for a long time and so distributions gave up on packaging them. The open source ones tsnd to not perform as well, as noted earlier in this thread. So being forced to use the proprietary driver for either 'team' to get the full benefits out of your hardware makes me think both of them only give us as much as they think we deserve.
I usually backed Matrox back in the day as everything just worked out of the box. But then the Parhelia came out and the driver install was much like nvidia's and it sucked.
Funny thing is, now Matrox hardware is supported in the nvidia driver, go figure.
So let's all admit, both have their advantages and disadvantages. Neither is 'evil' they both compete for different audiences for the most part. Truth is, for any of the things like DLSS and Raytracing, nvidia still is going to trounce AMD this time around. They got a jump on the tech. AMD was trying so hard to catch up, this is their first gen on ray tracing, so performs similar to the the 2080 from what I have seen, where the rest of stuff is about at 3080 speeds.
The ONLY reasons I would switch to AMD is for better Wayland support and Async Reprojection in VR (which may be pointless with the new cards).
With a new 3080 upgrade... I take the 2080 out of my machine and put in the 3080, done. For switching I will have to reconfigure 3 OSs...
slaapliedje 5 Dec, 2020
View PC info
  • Supporter Plus
Quoting: Shmerl
Quoting: slaapliedjeI have been using nvidia for years, and it has pretty much been 'just works'.

I remember Nvidia breaking more than once due to kernel updates and I remember Nvidia messing up my install to the point of frustration and wiping out the whole OS to reinstall. Not upstreaming their driver has consequences. Ditching the blob felt very good and I'm not interested in going back to that horror :)
See, I have had the exact opposite experience. The Radeon laptop that I have, it worked mistly with the fglrx driver, but would break all the time as it wouldn't work either with a newer kernel, or xorg. Then there was a point in time where it fit in that tiny slit of not being supported by the open source driver OR fglrx, and I basically had to switch to Windows...
Cybolic 5 Dec, 2020
Quoting: slaapliedje
Quoting: Shmerl
Quoting: slaapliedjeI have been using nvidia for years, and it has pretty much been 'just works'.

I remember Nvidia breaking more than once due to kernel updates and I remember Nvidia messing up my install to the point of frustration and wiping out the whole OS to reinstall. Not upstreaming their driver has consequences. Ditching the blob felt very good and I'm not interested in going back to that horror :)
See, I have had the exact opposite experience. The Radeon laptop that I have, it worked mistly with the fglrx driver, but would break all the time as it wouldn't work either with a newer kernel, or xorg. Then there was a point in time where it fit in that tiny slit of not being supported by the open source driver OR fglrx, and I basically had to switch to Windows...
My experience has been that:
  • My ATI Rage 128 took forever to get support but eventually worked (this was back in 2000/2001, so not much point in comparing further)

  • My Radeon (some mid-2000s laptop model, sorry can't remember more) worked wonderfully in Linux but had shoddy 3D performance (it was fine, but not great - laptop though), great experience otherwise, solid hardware and fantastic TV output (yes, it was that long ago)

  • my GeForce 680, 980 and 1080 Ti all worked well in games, but the 980 and 1080 Ti both had weird things happening: lots of kernel incompatibilities, system freezes were common (better now, but still happen, especially with VT switching, CUDA, NVdec or VDPAU - basically anything that's supposed to give NVIDIA an advantage) and OpenGL texture corruption and/or texture sync (don't ask, I'm still not sure what it it precisely, but any desktop compositor will go out of sync with actual framebuffers eventually and require a restart - still happens with compton, picom, Mutter and KWin).

Of course, my main gripe with NVIDIA is still the missing VR reprojection on Linux, but now you have a bit of background on how well things have been working in general as well.

Honestly I think the driver installation situation is about equal for NVIDIA and AMD (though the built-in AMD driver gives a slight win there for general usage). For gaming I think the issue for AMD is distribution support for the driver options and for NVIDIA, well, it's NVIDIA :P


Last edited by Cybolic on 5 December 2020 at 11:30 am UTC
tuubi 5 Dec, 2020
Quoting: slaapliedjeWith AMD you will always be chasing the latest mesa libs or kernel, because distrubutions don't chase AMD.
That sounds so dramatic, until you realise that on many popular distributions "chasing" means adding a repo and letting your update manager handle the rest. On rolling distros like Arch you're already running the latest and greatest so you're pretty much good to go. I'm on Mint, but I certainly don't spend any more time "chasing libs" than I spent chasing new Nvidia drivers back when I owned their hardware.

Quoting: slaapliedjeThe open source ones tsnd to not perform as well, as noted earlier in this thread.
That's not generally true for AMD these days, according to benchmarks. There are exceptions of course, but gamers are usually better off with Mesa.


Personally I switched from AMD/ATI to Nvidia about 15 years ago, when fglrx was making my life miserable. But I don't see a reason to pick a camp and stick with it. No hardware vendor has earned my undying loyalty.

I've had less issues since I switched back to AMD after a few Nvidia GPUs that mostly just worked and that's enough to keep me here for now. Being dependent on one less proprietary piece of software is also nice.
x_wing 5 Dec, 2020
Quoting: slaapliedjeThing is, and my point being, yku should NOT HAVE to go bleeding edge just to get a graphics card to work. With nvidia you do not, as most distributions package the drivers themselves.

Installing the latest driver for Nvidia is not going bleeding edge? As I said, having to update your kernel to the latest stable version is not isolated to AMD hardware.

Quoting: slaapliedjeWith AMD you will always be chasing the latest mesa libs or kernel, because distrubutions don't chase AMD. The proprietary drivers for AMD have been a mess for a long time and so distributions gave up on packaging them. The open source ones tsnd to not perform as well, as noted earlier in this thread. So being forced to use the proprietary driver for either 'team' to get the full benefits out of your hardware makes me think both of them only give us as much as they think we deserve.

Once you have a kernel that supports your hardware there is no need to keep updating it (unless there are some driver level bugs that requires fixing, of course). And "chasing" the latest Stable Mesa drivers is fairly trivial in any distro but, once you have support of your hardware you only have to do that if you want to get the new fixes or features of Mesa.

Who told you that "The proprietary drivers for AMD have been a mess for a long time and so distributions gave up on packaging them"? Did you ever take a look on how AMDGPU-PRO is packaged? And I can ask the same regarding the driver performance you mention. I think that you have a big bias regarding many things of the open source drivers.

Quoting: slaapliedjeSo let's all admit, both have their advantages and disadvantages. Neither is 'evil' they both compete for different audiences for the most part. Truth is, for any of the things like DLSS and Raytracing, nvidia still is going to trounce AMD this time around. They got a jump on the tech. AMD was trying so hard to catch up, this is their first gen on ray tracing, so performs similar to the the 2080 from what I have seen, where the rest of stuff is about at 3080 speeds.

How many games I can play with DLSS or RT on Linux? Truth is that we are on Linux and those are pointless features for now. IMO, right now this technologies have the same weight as Physx had in the past.


Last edited by x_wing on 5 December 2020 at 2:52 pm UTC
3zekiel 5 Dec, 2020
Quoting: x_wingHow many games I can play with DLSS or RT on Linux? Truth is that we are on Linux and those are pointless features for now. IMO, right now this technologies have the same weight as Physx had in the past.

For RT, it is most likely coming soon, see the movements from Khronos on vulkan RT API (which is literally tailored for dxvk/vkd3d use). So RT definitely matters, unless you are completely against proton of course.

For DLSS, who knows ... Hope it comes, maybe yes, maybe no. Nvidia did release the headers for some of that but not all, the sdk itself is under NDA. Guess it's in Valve's hands to unlock the situation now, I don't see what anyone else can do. Unless Stadia goes Nvidia for next round, that would help a lot.
slaapliedje 5 Dec, 2020
View PC info
  • Supporter Plus
Fuck it. I had a nice rant going about this subject, but then my mobile fennec crashed on me, and I don't give enough of a shit to try and convince peopls that updating your entire kernel so that you can get your video card working is an unsustainable msthod of doing it.
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.