https://wiki.archlinux.org/api.php?action=feedcontributions&user=Strikemybread&feedformat=atomArchWiki - User contributions [en]2024-03-29T00:47:06ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:AMDGPU&diff=648636Talk:AMDGPU2021-01-10T15:15:53Z<p>Strikemybread: /* Navi power consumption addition: Idle power consumption & memory clocks with Navi 10 and multiple monitors */ Solved</p>
<hr />
<div>== Supported Hardware ==<br />
I just crawled the product names "Radeon xyz" of VI/CI GPUs together and was going to go on for professional products "FirePro xzy", too.<br />
<br />
Afaik, there is no such complete listing on the web. There is a lot of confusion about the code and product names, due to AMD repeatedly rebranding their products and even change code names for same GPUs (Tonga = Antigua, Hawaii = Grenada, Carrizo = Bristol Ridge?, ...)<br />
<br />
When I started using gnu/linux, the arch wiki was a great help and there are still a lot of people struggling with graphics drivers. Now I know it is not hard to understand, but it is still confusing for beginners, coming from windows and just being used to install one software suite (not a drm driver, libdrm, mesa, gallium, etc.), supporting all the current hardware.<br />
<br />
now everyone has to go through all of this every time to determine 1) which hardware is really in their product and 2) which driver suits their hardware<br />
<br />
<br />
tl;dr I think maintaining such a list would be really useful for beginners, maybe not here but in a separate article?<br />
[[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 09:27, 16 February 2016 (UTC)<br />
<br />
:Well, [https://wiki.gentoo.org/wiki/Amdgpu#Feature_support Gentoo wiki] has a simple two-line summary. If it's still not sufficiently clear or the list is already much larger, I guess we could have a separate subpage to not clutter the main page... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:20, 16 February 2016 (UTC)<br />
<br />
:: yes, in the meantime I also found this table. It looks good but it is not complete. And completing the list would blow up the table cells a lot. I guess we should wait until vulkan and the new OpenCL driver has been released. Until then, there is no real reason for owners of pre-VI hardware to switch over to amdgpu. All vi and post-vi will be covered, so there is no need to list those separately. For the others I could create a subpage when switching to amdgpu gives you the opportunity for opencl 2.1 and vulkan -- [[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 10:50, 16 February 2016 (UTC)<br />
<br />
== Enable amdgpu for Sea Islands Cards ==<br />
testing my Hawaii card w/ amdgpu last week, sound did not work, even though 6 pcm/hdmi audio devices were listed. Might be added as an issue (as I think this is important deciding between radeon and amdgpu), but needs further investigation/confirmation from other testers.<br />
[[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 09:53, 16 February 2016 (UTC)<br />
:Please remember the AMDGPU is still in beta, and there's still info and knowledge/experience missing (e.g. most users use the Radeon driver).<br />
:AMD isn't that great in providing info and so far a lot of users are confused about their hardware support in use with amdgpu.<br />
:Remember there are flags like {{ic|exp_hw_support}}. More info need to be added, but it will take some time.<br />
:[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 13:14, 16 February 2016 (UTC)<br />
: It does indeed seem like that was no CI issue. Audio over hdmi is not supported by amdgpu atm, respectively only with the (upcoming) DAL changes[http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/853189-audio-over-hdmi-tonga-and-amdgpu], although it is listed as 'done' [http://xorg.freedesktop.org/wiki/RadeonFeature/ here]. [[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 15:59, 22 February 2016 (UTC)<br />
<br />
== Sea Islands cards not working with 4.5.x? ==<br />
I stumbled across this wiki page in hopes of getting more performance after seeing Michael from Phoronix get his 290 working with this. Following through all the instructions, menuconfiging and compiling new kernels, in the end all I get is a blank screen with my r9 390. No errors on Xorg.0.log. Can anyone confirm that it isn't just me?<br />
[[User:Katorisenko|Katorisenko]] ([[User talk:Katorisenko|talk]]) 07:46, 24 April 2016 (UTC)<br />
<br />
== AMDGPU and HDMI Audio ==<br />
<br />
According to [https://bugzilla.freedesktop.org/show_bug.cgi?id=92827#c2 this Freedesktop.org bug comment], HDMI audio support in AMDGPU requires DAL which is "not upstream yet", and won't be anytime soon according to [http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-DRM-No this Phoronix article]. I'm currently struggling to make my HDMI audio work with my AMD Radeon R9 380; if this happens to be impossible with AMDGPU, should we mention it in the "Troubleshooting" section of this page? --[[User:Hellpe|Hellpe]] ([[User talk:Hellpe|talk]]) 23:26, 3 January 2017 (UTC)<br />
<br />
:I am in favor of adding the information notice to the troubleshooting section. I think users who do not keep up with the news will be confused when Pulseaudio seems to add the HDMI audio devices, despite them being non-functional until the DAL code is refactored and accepted upstream then pushed to regular users. I know it was not immediately clear to me when I upgraded from my radeonsi card to an RX series amdgpu card until I did some reading. I "think" currently the only way to get HDMI audio is to use the AMDGPU-PRO driver for the time being. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 15:48, 4 January 2017 (UTC)<br />
<br />
::I have it working with an R9 380 under Xorg. I did nothing special, simply disabled the built-in audio and enabled the HDMI audio. It does not work under Wayland however. Pavucontrol shows unavailable. [[User:Unit73e|Unit73e]] ([[User talk:Unit73e|talk]]) 12:22, 2 December 2017 (UTC)<br />
<br />
== Some experiments with integrated AMD graphics ==<br />
<br />
Some results after playing with "radeon" and "amdgpu" drivers and gnome (for AMD A10 7850K):<br />
<br />
- Having both drivers loaded causes systemd to hang at system shutdown (xorg). Using amdgpu and blacklisting radeon or using radeon and blacklisting amdgpu both fix this problem.<br />
<br />
- Having amdgpu driver without mkinitcpio.conf entry causes<br />
1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11"<br />
2. HDMI sound output is shown only in rare cases<br />
<br />
- Having amdgpu driver with mkinitcpio.conf entry causes<br />
1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland"<br />
2. HDMI sound is always disabled<br />
<br />
- Having radeon driver without mkinitcpio.conf entry causes<br />
1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11"<br />
2. HDMI sound is always correctly detected and working<br />
<br />
- Having radeon driver with mkinitcpio.conf entry<br />
1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland"<br />
2. HDMI sound is always correctly detected and working<br />
<br />
[[User:Beoldhin|Beoldhin]] ([[User talk:Beoldhin|talk]]) 19:07, 23 May 2017 (UTC)<br />
<br />
Update: with kernel 4.11.2-1: HDMI sound output is now working with "amdgpu" but only in as "Gnome in xorg" login option (still no sound with Wayland). There are still some graphical glitches when running Wayland with the radeon driver: external screen doesn't turn off after timeout, windows can't be maximized with the "wmctrl" command and updating text in terminal causes some text updating problems (these don't exist with xorg, amdgpu and radeon both work fine). So in summary: I can now select either amdgpu or radeon driver but Wayland is still unstable.<br />
<br />
[[User:Beoldhin|Beoldhin]] ([[User talk:Beoldhin|talk]]) 19:07, 23 May 2017 (UTC)<br />
<br />
== Vega Changes for Wiki ==<br />
<br />
With Vega releasing around the end of the month, the DC/DAL is still not it the kernel. Should we just put a note for users to use the AMDGPU-PRO drivers if they have VEGA cards? We could possibly add a note saying that in the AUR, there is an alternate kernel built from their repos with the DC/DAL code. <br />
Alternate kernel--> {{AUR|linux-amd-staging-git}} [[User:Sesese9|Sesese9]] ([[User talk:Sesese9|talk]]) 00:40, 10 July 2017 (UTC)<br />
<br />
== Moving "Enable GPU display scaling" to xrandr ==<br />
<br />
I thought about it to put this under xrandr directly, but for example for my integrated Intel 6th gen GPU I don't have the "scaling mode" option, and I don't know about NVIDIA.<br />
And even if the "scaling mode" option exists for other vendors and or cards, I don't know if the possible values for "scaling mode" are the same everywhere, as far as I remember there are not.<br />
That was the reason I did put it here. [[User:Bertl|Bertl]] ([[User talk:Bertl|talk]]) 16:01, 18 February 2018 (UTC)<br />
:Ok, looks like [[Intel_graphics#Setting_scaling_mode|Intel]] uses the same settings, but it's only available for internal (LVDS, eDP) ports, but at least according to https://bugs.freedesktop.org/show_bug.cgi?id=90989 it also uses "None, Full, Center, Full aspect".<br />
:I know that radeonsi uses the same commands, but still don't know about NVIDIA.<br />
:But yea, now I also think that it should be moved and the [[Intel_graphics#Setting_scaling_mode|Intel]] section should be merged into it. [[User:Bertl|Bertl]] ([[User talk:Bertl|talk]]) 18:37, 18 February 2018 (UTC)<br />
<br />
== Update on kernel parameters ==<br />
<br />
this part does not seems to be required on 4.17:<br />
<br />
>> Also, since kernel 4.13, adding the amdgpu.si_support=1 radeon.si_support=0 or amdgpu.cik_support=1 radeon.cik_support=0 kernel parameter is required. Otherwise, AMDGPU will not start and you will end up with either radeon being used instead or the display being frozen during the boot.<br />
<br />
{{unsigned|12:10, 22 April 2018|Lesto}}<br />
<br />
== Renaming AMDGPU-PRO to Radeon Software for Linux? ==<br />
<br />
So AMD basically changed the name of their AMDGPU-PRO driver as simply Radeon™ Software for Linux, see [https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx 17.40], [https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-for-Linux-Release-Notes.aspx 18.10] and [https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-for-Linux-18.20-Early-Preview-Release-Notes.aspx 18.20 preview] release notes. With that in mind, should the names on wiki be slowly changed, or the alternative name/note being added somewhere? I'm not sure if AMDGPU-PRO is still used by AMD officially and whether AMDGPU (without PRO) term is being used as well, but the name sure definitely stuck among community – any ideas? [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 17:33, 11 May 2018 (UTC)<br />
<br />
EDIT: Probably worth noticing is the similar situation happened between [[Fglrx]] and [[AMD Catalyst]] naming back then. [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 17:38, 11 May 2018 (UTC)<br />
<br />
== Vulkan support for FreeSync on Mesa 19.1 ==<br />
<br />
Mesa 19.1 recently came out and it supposedly has FreeSync support for Vulkan. I can't test it right now but I was running the freesync patch before 19.1 and it worked for me. Anyone can confirm it is working on 19.1 and edit the FreeSync part about "only OpenGL is supported"<br />
<br />
[[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 08:56, 5 July 2019 (UTC)<br />
<br />
== Move Variable Refresh Rate to New Page ==<br />
<br />
NVIDIA has supported freesync for a while now as well as having their own variable refresh rate technology (Gsync). I think it would make more sense to make a separate page for it.<br />
[[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 17:00, 2 August 2019 (UTC)<br />
<br />
:I have started writing the article on my [[User:Cknight70#Variable_refresh_rate|personal page]]. Please feel free to make edits, I will create the new page in a couple of days if there are no objections. [[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 18:58, 3 August 2019 (UTC)<br />
<br />
::Check out [[Variable Refresh Rate]] [[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 15:49, 9 August 2019 (UTC)<br />
<br />
== OpenCL implementation? ==<br />
<br />
I've just spent the past day finding out how to get OpenCL to work with AMDGPU and I just found the answer on the [[Blender]] page by using {{AUR|opencl-amd}}. I don't really know if it would fit in with the page (as I could of solved this much sooner by searching up OpenCL and just looking at [[GPGPU]]) but I was still confused by people saying that only AMDGPU-PRO has OpenCL 2 support, so if it was mentioned somehow on the page I think it would be very helpful.<br />
[[User:Polygonerror|Polygonerror]] ([[User talk:Polygonerror|talk]]) 15:45, 20 December 2019 (UTC)<br />
<br />
== Navi power consumption addition: Idle power consumption & memory clocks with Navi 10 and multiple monitors ==<br />
<br />
Using a Gigabyte 5700 XT Gaming OC and 2 Monitors (LG OLED 55" and Dell 25") connected, the GPU won't throttle down and uses around 30W in idle.<br />
Xorg.conf and xrandr etc. don't help.<br />
A workaround is to suspend and resume, using the following as an systemd user job.<br />
<br />
.config/systemd/user/xrandr.service<br />
[Unit]<br />
Description=xrandr<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=oneshot<br />
Environment=DISPLAY=:0<br />
ExecStart=/usr/bin/xrandr -s 2560x1440 --dpi 117 --output DisplayPort-2 --mode 2560x1440 --primary --output HDMI-A-0 --same-as DisplayPort-2 --scale-from 2560x1440 --mode 1920x1080 --rate 60 --dpi 96<br />
ExecStart=/usr/bin/xrandr --output HDMI-A-0 --off<br />
<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
<br />
Change ports and resolutions and enable with<br />
<br />
systemctl --user enable xrandr<br />
<br />
Setting --rate of the LG OLED to 120 will not reduce power consumption as much, because the GPU needs to clock the memory higher.<br />
<br />
Everything works as expected after resuming. Power1 from amdgpu is around 9-10W in idle.<br />
<br />
Is there anything official to fix this that I didn't find?<br />
<br />
The problem is still present in 5.5.15-1-ck and 5.6rc7-1.<br />
<br />
Is it OK to include this in the troubleshooting section ?<br />
<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]]) 11:29, 7 April 2020 (UTC)<br />
<br />
: still present in 5.7-mainline [[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]])<br />
: OK, using a modeline _without_ reduced blanking gives proper power usage right after boot (cvt 2560 1440 60). More than the max. reported pixel clock of the monitor(connection). Power reading is now ~10 W, with workaround above ~ 8 W. And, workaround doesn't work anymore with > 5.9.14. [[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]])<br />
<br />
== Adding suggestion to install `xf86-video-amdgpu` when using southern islands gpu? ==<br />
<br />
In my case it wasn't possible to create `/etc/X11/xorg.conf.d/20-amdgpu.conf` and restart pc without crash. (for tearfree option)<br />
<br />
{{unsigned|18:53, 18 June 2020|Shfil}}<br />
<br />
== amdvlk inclusion ==<br />
<br />
I've noticed that amdvlk isn't properly explained or listed as an option, nor is there a clear explanation about how amd gpu drivers can be installed along side each-other and switched between; this is particularly relevant when you consider how trivial it is to switch between divers when amd gpus are compared to nvidia gpus. The wiki could be more clear, complete, and comprehensive if it included such information.<br />
<br />
Additionally there is a comment under the AOC compiler section which flatly states mesa with the AOC compiler preforms better than amdvlk, unfortunately that is inaccurate. There are still applications/games which require or preform much better under amdvlk. Also because the drivers in question are still very much "moving targets" its unlikely for one driver to be definitively better than the other for quite sometime.<br />
<br />
[[User:Desulate|Desulate]] ([[User talk:Desulate|talk]]) 22:27, 28 November 2020 (UTC)<br />
<br />
== Enable Southern Islands (SI) and Sea Islands (CIK) support ==<br />
<br />
This chapter is entirely obsolete, at least for Navi GPUs (Radeon Pro W5700 in my case).<br />
<br />
No {{ic|{cik,si}_support}} module parameters are needed and things work fine with {{ic|amdgpu}} out-of-the-box. There is no need for {{ic|radeon}} anywhere in this context; it can be just blacklisted (or not; it doesn't matter). (Also, there is a separate Wiki [[ATI|page]] for {{ic|radeon}} and legacy GPUs; {{ic|radeon}} should be mentioned (only) there.) [[User:Andrej|Andrej]] ([[User talk:Andrej|talk]]) 19:25, 15 December 2020 (UTC)<br />
<br />
: You are missing the purpose of these parameters. On some old gpus the radeon driver is loaded by default, but they could work with amdgpu also. These parameters are for activating amdgpu driver for them. [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 19:38, 15 December 2020 (UTC)</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:NFS&diff=621566Talk:NFS2020-06-23T07:22:11Z<p>Strikemybread: /* Mount using /etc/fstab with systemd */ Talk page comment</p>
<hr />
<div>== Are the following services still valid and what do they do? ==<br />
<br />
The following services seem to be provided by {{pkg|nfs-utils}}: {{ic|nfs-idmapd.service}}, {{ic|nfs-mountd.service}} and {{ic|nfs-utils.service}}. Can someone please provide details why these services are shipped and their usage?<br />
<br />
Thanks.<br />
<br />
[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 19:05, 10 June 2018 (UTC)<br />
<br />
== NetworkManager-wait-online ==<br />
<br />
I think that {{ic|/etc/systemd/system/auto_share.service}} should contain the following line after {{ic|Description}}:<br />
<br />
After=NetworkManager-wait-online.service<br />
Before=systemd-user-sessions.service<br />
<br />
The rationale for this is that you need to wait for the network to be up and running before attempting an NFS connect from client-side. You also need to perform the NFS mountings before making user sessions available, because the latter may be dependent on the former. For example, my bash profile is stored on a remote server, so I need NFS drives mounted before I even attempt a login. On some systems, maybe the whole {{ic|home}} directory is on a different computer (as would be the case for thin clients), meaning that they should definitely be mounted before users can log in.<br />
<br />
You need to enable {{ic|NetworkManager-wait-online.service}} like so:<br />
<br />
# systemctl enable NetworkManager-wait-online<br />
<br />
I can't help thinking that this is a bit of a kludge in any event, and is a scenario that should be handled automatically by {{ic|systemd}}.<br />
<br />
{{ic|/etc/systemd/system/auto_share.service}} is a bad place to create the file. Instead, do it in the standard way by creating it as {{ic|/lib/systemd/system/auto_share.service}} and re-enabling it using the command<br />
# systemctl reenable auto_share.service<br />
<br />
--[[User:Blippy|Blippy]] ([[User talk:Blippy|talk]]) 20:24, 8 September 2013 (UTC)<br />
<br />
== ARM mount options 1 ==<br />
<br />
<snip><br />
<br />
3. Courtesy this recent thread:<br />
<br />
[http://www.gossamer-threads.com/lists/gentoo/user/297428?page=last New default behavior in nfs-utils (1.3.2-r1)]<br />
<br />
and in particular this comment:<br />
<br />
[http://www.gossamer-threads.com/lists/gentoo/user/297452#297452 explanation by Neil Bothwick]<br />
<br />
<code><br />
The problem is that the mount command fails however you run it, from <br />
either init system or from a shell. It fails with "invalid mount options" <br />
because it now defaults to NFS V4.2 even if it is not enabled in <br />
the kernel. You need to either enable 4.2 or specifically set nfsver=4 to <br />
work around this. <br />
</code><br />
<br />
Put differently, for '''''[[ARM]]''''' nfs-utils 1.3.2-4 and later this fails:<br />
<br />
<code><br />
sudo mount -v server:/music /mntpoint<br />
</code><br />
<br />
with the all-purpose error message:<br />
<br />
<code><br />
mount.nfs: an incorrect mount option was specified<br />
</code><br />
<br />
while this:<br />
<br />
<code><br />
sudo mount.nfs4 -v -o nfsvers=4 server:/music /mntpoint<br />
</code><br />
<br />
works.<br />
<br />
<snip><br />
<br />
[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 22:54, 24 February 2015 (UTC)<br />
<br />
::=== Points 1 and 2 ===<br />
::Good points, edited. I used the systemd syntax recommended. You can make the edits I think for the v4.2 stuff.<br />
::[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 23:44, 24 February 2015 (UTC)<br />
<br />
:::Will do. The change affects the fstab entry as well, so I should craft an fstab entry and verify it before editing the wiki page. I'm busy for the next couple of days, so not until the weekend.<br />
:::[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 17:05, 25 February 2015 (UTC)<br />
<br />
<snip><br />
<br />
... the following fstab entry enables automounts on an '''''[[ARM]]''''' client running nfs-utils 1.3.2-4 and later:<br />
<br />
<code><br />
server:/music /MOUNT/POINT nfs4 nfsvers=4,users,noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,noatime 0 0<br />
</code><br />
<br />
I had to reboot to get the fstab entry to take.<br />
<br />
<snip><br />
<br />
<br />
--[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 13:50, 3 March 2015 (UTC)<br />
<br />
== ARM mount options 2 ==<br />
<br />
Did you write your recent edits based on an Arch ARM box? See this thread where an Arch user failed to get mounts working with your new advice. Am I OK reverting your edits? I cannot get them to work on my x86_64 boxes either.<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=194400<br />
<br />
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 00:42, 4 March 2015 (UTC)<br />
<br />
<snip><br />
<br />
(Forgot the sig)<br />
--[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 14:36, 4 March 2015 (UTC)<br />
<br />
<snip><br />
________________________<br />
<br />
One odd point: I can't reproduce the error you and the user saw. I set up five NFS clients and two NFS servers (one x86_64, one ARM), and they all Just Work with -t nfs4 and -o nfsvers=4 (once I corrected the stale IP in /etc/hosts).<br />
<br />
But if x86_64 works without -t nfs4 and -o nfsvers=4, well ... who cares? Just use -t nfs.<br />
<br />
--[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 16:20, 4 March 2015 (UTC)<br />
<br />
: Go ahead and revert your edits. Thanks for clearing it up.<br />
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 21:12, 4 March 2015 (UTC)<br />
<br />
Done.<br />
<br />
Under "Mount using /etc/fstab", shouldn't the fstab entry be "nfs" rather than "nfs4"? I don't think that's one of my edits.<br />
<br />
I deleted most of the text, just leaving recipes on the discussion page should an ARM user come looking for patches.<br />
<br />
(Re-editing to add sig) --[[User:Jhsnyder|Jhsnyder]] ([[User talk:Jhsnyder|talk]]) 01:14, 5 March 2015 (UTC)<br />
<br />
: Thanks, I moved the general note up to the top of the page and removed the replicates in the article. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 08:07, 5 March 2015 (UTC)<br />
<br />
I have removed the note, since there have been some changes since version 2.x.x. Can anyone confirm if the issue is still there? [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 11:25, 17 March 2017 (UTC)<br />
<br />
== Bad config file for server? ==<br />
From https://wiki.archlinux.org/index.php/NFS#Starting_the_server I edited /etc/conf.d/nfs-server.conf to disable v2 and v3, but that didn't seem to work. Looking at the service file, I noticed this:<br />
<br />
[Service] <br />
EnvironmentFile=-/run/sysconfig/nfs-utils <br />
<br />
Type=oneshot <br />
RemainAfterExit=yes <br />
ExecStartPre=/usr/sbin/exportfs -r <br />
ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS<br />
<br />
So I added the options in $RPCNFSDARGS in /run/sysconfig/nfs-utils instead and that worked as expected. Did I do something wrong, or should we update the wiki?<br />
<br />
{{Unsigned|2015-10-08|Lacrymology}}<br />
<br />
== Client section confusion ==<br />
<br />
The client section states: "Start '''rpcbind.service''' ... and enable...". However, the server section states that rpcbind.service is only required for older (V2, V3) NFS versions. See ''Starting the server'': The rpcbind.service is ... needed for older V2 and V3 exports. <br />
<br />
Question: Is rcpbind.service still required on the client? For all NFS versions? Only for older versions?<br />
<br />
{{Unsigned|2016-06-25|MountainX}}<br />
<br />
== Mount using /etc/fstab with systemd ==<br />
<br />
Is there a reason to have timeo=14 when using x-systemd.automount? At one time the man page showed a sample fstab entry using timeo=14, but it wasn't relevant to anything. I can't seem to find any reason why it is beneficial for this purpose as indicated on the wiki.<br />
<br />
servername:/home /mountpoint/on/client nfs _netdev,noauto,x-systemd.automount,x-systemd.mount-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0<br />
[[User:Matthew02|Matthew02]] ([[User talk:Matthew02|talk]]) 02:53, 15 February 2020 (UTC)<br />
<br />
:I also tried to find out what timeo is for. According to the nfs-manpage, changing the default timeo value really just seems relevant if you use nfs over TCP, because the default timeout would be 60s, increasing to 600s. For UDP, the default would be 1.1 s, the examples increases this to 1.4 s, and timeo is only used for "infrequent" request types (others than read and write). But, if for whatever reason, you use NFS over TCP, the example should reduce the time the system hangs in case of connection problems (from 60s to 1.4s for the first failed request). Maybe someone using NFS over TCP can test this ? <br />
:[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]]) 07:22, 23 June 2020 (UTC)<br />
<br />
== NFS Mounts on armv7h ==<br />
<br />
This is just FYI because I'm sure the number of people this affects is very small, however my odroid plug stopped behaving with NFS a few months back. It would autofs, let's say /data/dir1 fine, but CDing into dir1 would yield an error that the directory does not exist. Mounting by hand gave me a protocol error, after much tweaking the NFS server and client, Arch configs, reinstalling, and about a zillion other things, off and on over the past few months, I finally tracked it back to LSM not knowing about AppArmor (after some combing through packet dumps). My solution was to append "security=apparmor" to the kernel boot. At least I think that's what fixed it. I do Linux sysadmining for a living (but not much Arch, love it for the Odroid, however). I think I covered my bases with NFS3 vs. NFS4, and various other things that can go wrong. At any rate, don't know if it merits a mention somewhere, but it was driving me nuts. :) I used a fairly generic Arm image from the website to bootstrap the plug. <br />
<br />
[[User:NoSuchPerson|NoSuchPerson]] ([[User talk:NoSuchPerson|talk]]) 03:16, 19 February 2020 (UTC)</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:ZFS/Virtual_disks&diff=620389Talk:ZFS/Virtual disks2020-06-16T16:06:19Z<p>Strikemybread: Wrong example?</p>
<hr />
<div>== Linear Span ==<br />
Is there a reason why the example in [[ZFS/Virtual_disks#Linear_Span|Linear Span]] points to sdX instead of virtual disks?<br />
Having "...they are free to experiment without fear of actual data loss" in the beginning could make you feel safe and pasting that accidentally.<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]]) 16:06, 16 June 2020 (UTC)</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=User:Strikemybread&diff=618291User:Strikemybread2020-06-04T20:34:47Z<p>Strikemybread: Oops, left category in.</p>
<hr />
<div><br />
This page describes additional steps and other hints for the ASUS X470 PRIME mainboard.<br />
<br />
<br />
==UEFI Temperature Sensors==<br />
'''Warning:''' This board uses the ITE IT8665E super I/O chip, which is buggy and can lead to fans stopping or spinning at 100% (ASUS cannot or won't fix the BIOS)<br />
<br />
See [[lm_sensors#Installation]] and [[Lm_sensors#Asus_B450/X399/X470/A320M-K/A320M-K-BR_motherboards_with_AM4_Socket]] if needed, then install {{AUR|asus-wmi-sensors-dkms-git}}. <br />
<br />
Load the module afterwards:<br />
<br />
# modprobe asus_wmi_sensors<br />
<br />
{{hc|$ lsmod {{!}} grep wmi_sens|<br />
asus_wmi_sensors 20480 0<br />
wmi 36864 4 asus_wmi_sensors,asus_wmi,wmi_bmof,mxm_wmi<br />
}}<br />
<br />
Check if it's working:<br />
<br />
{{hc|$ sensors|<br />
asuswmisensors-isa-0000<br />
Adapter: ISA adapter<br />
CPU Core Voltage: 1.31 V <br />
+12V Voltage: 11.97 V <br />
+5V Voltage: 4.99 V <br />
3VSB Voltage: 3.29 V <br />
CPU Fan: 1194 RPM<br />
Chassis Fan 1: 618 RPM<br />
Chassis Fan 2: 838 RPM<br />
Chassis Fan 3: 832 RPM<br />
AIO Pump: 0 RPM<br />
Water Pump: 0 RPM<br />
CPU OPT: 0 RPM<br />
CPU Temperature: +72.0°C <br />
Motherboard Temperature: +36.0°C <br />
Chipset Temperature: +0.0°C <br />
Tsensor 1 Temperature: +0.0°C <br />
}}<br />
<br />
Depending on BIOS version, some temperatures are missing (Chipset works with 5202).<br />
<br />
Reading out those sensors too often or in quick succession can make the fans stop randomly or run them at 100%.<br />
<br />
Other modules like it87 can sometimes read out, but the chance of fan failure is much lower with {{AUR|asus-wmi-sensors-dkms-git}}.<br />
<br />
==Max CPU temperature 75 °C or cpu fans at 100%==<br />
<br />
In the Prime X470 UEFI, CPU alarm temperature threshold can't be higher than 75 °C (which is much, much too low for Ryzen),<br />
and lets your CPU fan spin at 100% when crossing that threshold.<br />
You can cap the CPU at 74°C in the UEFI, eliminating the fan issue, but limiting the power of the cpu slightly as well (go benchmark).<br />
<br />
It's also possible to bind the chassis fans to the "Motherboard Temperature", which can be an acceptable workaround for this issue.<br />
<br />
<br />
<br />
==Resources==<br />
https://github.com/electrified/asus-wmi-sensors<br />
<br />
https://rog.asus.com/forum/showthread.php?102138-CPU-and-case-fans-mysteriously-stopping-on-the-ASUS-Prime-X470-Pro<br />
<br />
https://rog.asus.com/forum/showthread.php?95288-75-Degrees-threshold-100-fan}</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=User:Strikemybread&diff=618287User:Strikemybread2020-06-04T20:29:54Z<p>Strikemybread: Adding ASUS Prime X470 Mainboard to the Wiki - test</p>
<hr />
<div>[[Category:Mainboards and BIOS]]<br />
This page describes additional steps and other hints for the ASUS X470 PRIME mainboard.<br />
<br />
<br />
==UEFI Temperature Sensors==<br />
'''Warning:''' This board uses the ITE IT8665E super I/O chip, which is buggy and can lead to fans stopping or spinning at 100% (ASUS cannot or won't fix the BIOS)<br />
<br />
See [[lm_sensors#Installation]] if needed, then install {{AUR|asus-wmi-sensors-dkms-git}}.<br />
<br />
Load the module afterwards:<br />
<br />
# modprobe asus_wmi_sensors<br />
<br />
{{hc|$ lsmod {{!}} grep wmi_sens|<br />
asus_wmi_sensors 20480 0<br />
wmi 36864 4 asus_wmi_sensors,asus_wmi,wmi_bmof,mxm_wmi<br />
}}<br />
<br />
Check if it's working:<br />
<br />
{{hc|$ sensors|<br />
asuswmisensors-isa-0000<br />
Adapter: ISA adapter<br />
CPU Core Voltage: 1.31 V <br />
+12V Voltage: 11.97 V <br />
+5V Voltage: 4.99 V <br />
3VSB Voltage: 3.29 V <br />
CPU Fan: 1194 RPM<br />
Chassis Fan 1: 618 RPM<br />
Chassis Fan 2: 838 RPM<br />
Chassis Fan 3: 832 RPM<br />
AIO Pump: 0 RPM<br />
Water Pump: 0 RPM<br />
CPU OPT: 0 RPM<br />
CPU Temperature: +72.0°C <br />
Motherboard Temperature: +36.0°C <br />
Chipset Temperature: +0.0°C <br />
Tsensor 1 Temperature: +0.0°C <br />
}}<br />
<br />
Depending on BIOS version, some temperatures are missing (Chipset works with 5202).<br />
<br />
Reading out those sensors too often or in quick succession can make the fans stop randomly or run them at 100%.<br />
<br />
Other modules like it87 can sometimes read out, but the chance of fan failure is much lower with {{AUR|asus-wmi-sensors-dkms-git}}.<br />
<br />
==Max CPU temperature 75 °C or cpu fans at 100%==<br />
<br />
In the Prime X470 UEFI, CPU alarm temperature threshold can't be higher than 75 °C (which is much, much too low for Ryzen),<br />
and lets your CPU fan spin at 100% when crossing that threshold.<br />
You can cap the CPU at 74°C in the UEFI, eliminating the fan issue, but limiting the power of the cpu slightly as well (go benchmark).<br />
<br />
It's also possible to bind the chassis fans to the "Motherboard Temperature", which can be an acceptable workaround for this issue.<br />
<br />
<br />
<br />
==Resources==<br />
https://github.com/electrified/asus-wmi-sensors<br />
<br />
https://rog.asus.com/forum/showthread.php?102138-CPU-and-case-fans-mysteriously-stopping-on-the-ASUS-Prime-X470-Pro<br />
<br />
https://rog.asus.com/forum/showthread.php?95288-75-Degrees-threshold-100-fan}</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:Nftables&diff=618280Talk:Nftables2020-06-04T19:01:41Z<p>Strikemybread: /* add CUPS to example */ strike out</p>
<hr />
<div>==Bad practice and redundant code==<br />
Sitting beside the nftables maintainer, asking for feedback.<br />
<br />
This page's sample rulesets could use a good cleanup. I'll do that soon.<br />
<br />
TCP flag checks are not necessary, because you can just check for whether the packet is in an invalid state, or just not whitelist:<br />
<pre>/* table of valid flag combinations - PUSH, ECE and CWR are always valid */<br />
static const u8 tcp_valid_flags[(TCPHDR_FIN|TCPHDR_SYN|TCPHDR_RST|TCPHDR_ACK|<br />
TCPHDR_URG) + 1] =<br />
{<br />
[TCPHDR_SYN] = 1,<br />
[TCPHDR_SYN|TCPHDR_URG] = 1,<br />
[TCPHDR_SYN|TCPHDR_ACK] = 1,<br />
[TCPHDR_RST] = 1,<br />
[TCPHDR_RST|TCPHDR_ACK] = 1,<br />
[TCPHDR_FIN|TCPHDR_ACK] = 1,<br />
[TCPHDR_FIN|TCPHDR_ACK|TCPHDR_URG] = 1,<br />
[TCPHDR_ACK] = 1,<br />
[TCPHDR_ACK|TCPHDR_URG] = 1,<br />
};<br />
</pre><br />
<br />
ICMPv6 rate limiting like in the example is just stupid, for it breaks neighbour discovery (IPv6 ARP), ICMP isn't expensive to process, and it's not ICMP in of itself that is the problem. Anyhow, QoS is the job of the traffic control subsystem.<br />
<br />
We probably should make not of kernel requirements for rulesets (e.g., 3.18+, so won't work with 3.14 linux-lts).<br />
<br />
Maybe we should also provide guidance for getting upstream documentation, and troubleshooting. Attendance to netdev01 confirmed that it is in quite active development, and lots of usability features and fixes are in the pipeline.<br />
<br />
Allowing all ICMP is not necessary, and is already handled by conntrack RELATED,ESTABLISHED.<br />
-- alp (2015-02-17<br />
<br />
== syntax improvements ==<br />
<br />
I noticed there is a request to add '' italics for pseudo variables''. I am planning on doing that.<br />
<br />
However, I would also want to rename some of those variables to make it even more apparent that they can be changed to whatever you want. For example, {{ic|table inet filter}} I would change to {{ic|table inet ''my_filter''}}. Any objections?<br />
<br />
[[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 01:41, 18 January 2020 (UTC)<br />
<br />
: No, absolutely no objections. Though, my personal preference would be to stick to ''filter'' respectively something which can be copy pasted without having to adapt it. In other words, a name which a sysadmin might reasonably choose on his or her system. IMHO this makes it easier for users who want to do exactly the thing that is described in the article and spares them from having to rename ''my_filter'' to something sensible. [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 08:24, 18 January 2020 (UTC)<br />
<br />
:I have no opinion on {{ic|filter}} vs {{ic|my_filter}}. My main concern is that pseudo-variables should not match the nft syntax keywords (see examples in the style template in [[nftables#top]]). -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:09, 18 January 2020 (UTC)<br />
<br />
: Exactly. '''filter''' is actually keyword in some statements. '''my_filter''' is not and probably never will be. [[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 20:36, 18 January 2020 (UTC)<br />
<br />
:: Ok. I went over the page. Psedo variables are should be ''*_name'' or ''*_type''. The examples use my_* naming scheme for non key word arguments. [[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 23:37, 18 January 2020 (UTC)<br />
<br />
::: For those wondering, like myself: this section probably related to [[special:diff/603849]]. Which is probably related to [[special:diff/595487]]. I think the section here should now be deleted, since it was resolved. Other than {{ic|filterName}} vs {{ic|my_filter}}, aren't all comments in agreement? As an aside, other then differently emphasizing the keyword and the name, I think {{man|8|nft}} is using exactly what claimed here to be confusing. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 12:42, 3 April 2020 (UTC)<br />
<br />
== Imperative vs Declarative syntax. ==<br />
<br />
nftables supports two types of syntax.<br />
<br />
Imperative. Used in {{ic|nft}} command, interactive mode and scripts:<br />
<br />
{{ic|nft add table family_type table_name}}<br />
<br />
can also be in the file with shebang<br />
<br />
{{hc|somefile|<br />
#/usr/bin/nft -f<br />
add table ''family_type'' ''table_name''}}<br />
<br />
Declerative. Only used in configuration:<br />
<br />
{{bc|<br />
...<br />
table ''family_type'' ''table_name'' <nowiki>{</nowiki><br />
...<br />
<nowiki>}</nowiki>}}<br />
<br />
Right now the '''Configuration''' section only gives examples in the imperative syntax, however, '''Example''' section only show declarative syntax. What do you think about showing how to use declarative syntax in configuration alongside the nft commands? At the top of Configuration section will be the explanation when each syntax is used.<br />
<br />
So the '''Create table''' section would look like this:<br />
<br />
==== Create table ====<br />
<br />
The following adds a new table at run-time:<br />
<br />
# nft add table ''family_type'' ''table_name''<br />
<br />
Declaring table in configuration file:<br />
<br />
{{bc|<br />
...<br />
table ''family_type'' ''table_name'' <nowiki>{</nowiki><br />
...<br />
<nowiki>}</nowiki>}}<br />
<br />
<br />
I also added some Accuracy templates in the areas I thought the examples in the article were not accurate. Tell me what you think of accuracy of those sections.<br />
<br />
: I agree, declarative syntax is much easier to understand, and translates directly to imperative syntax. I plan on writing a subsection on configuration explaining the differences and use cases of each before touching on the already existing subsections, but the configuration section needs some improvements for clarity as well. [[User:Ivanmlerner|Ivanmlerner]] ([[User talk:Ivanmlerner|talk]]) 17:28, 18 April 2020 (UTC)<br />
<br />
<s>== add CUPS to example ==</s><br />
<br />
Since there is not much more information about cups and (nft)firewall rules than [https://www.cups.org/doc/firewalls.html CUPS Wiki], I added this to nftables.conf :<br />
<br />
tcp dport 53 accept<br />
udp dport 53 accept<br />
<br />
tcp dport 631 accept<br />
<br />
udp dport 5353 accept<br />
<br />
Missing those, CUPS cannot find network printers with nftable service started. Maybe this can be simplified by using "ipp" instead of port numbers, but I didn't test yet.<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]])<br />
<br />
:To discover network printers it should be enough to allow mDNS (UDP 5353), which already is in [[nftables#Examples]]. Also make note of the "Direction" in CUPS docs, you do not want to allow port 53 on an input chain.<br />
:The proper place to list the needed ports would be in articles of the software that requires those ports to be open. [[CUPS#Network]] says that it needs mDNS, thus UDP 5353, so there's no need to reiterate that. [[CUPS/Printer sharing]] does not state which ports should be opened, so that can be improved; since there are many options, the upstream doc could be linked from that page.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:08, 3 June 2020 (UTC)<br />
<br />
:Actually, adding 631 to [[nftables#Server]] should not be an issue, since the "server" could be a print server. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:11, 3 June 2020 (UTC)<br />
<br />
::In my initial test, 5353 wasn't enough, maybe I didn't wait long enough. Thanks for pointing that out, the printer can be used with only one extra port open. It's still strange that even in the nftables wiki, you don't find CUPS nor printer. [[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]])<br />
<br />
:::Feel free to add an example to [[nftables#Server]]. You can also use {{ic|ipp}} instead of {{ic|631}} in the nftables rule file. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 04:26, 4 June 2020 (UTC)<br />
<br />
::::: Done. [[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]])</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Nftables&diff=618279Nftables2020-06-04T18:56:34Z<p>Strikemybread: /* Server */ Added example for ipp/ port 631 as suggested in Talk:Nftables</p>
<hr />
<div>{{DISPLAYTITLE:nftables}}<br />
[[Category:Firewalls]]<br />
[[es:Nftables]]<br />
[[ja:Nftables]]<br />
[[ru:Nftables]]<br />
[[zh-hans:Nftables]]<br />
{{Related articles start}}<br />
{{Related|iptables}}<br />
{{Related articles end}}<br />
[https://netfilter.org/projects/nftables/ nftables] is a netfilter project that aims to replace the existing {ip,ip6,arp,eb}tables framework. It provides a new packet filtering framework, a new user-space utility (nft), and a compatibility layer for {ip,ip6}tables. It uses the existing hooks, connection tracking system, user-space queueing component, and logging subsystem of netfilter.<br />
<br />
It consists of three main components: a kernel implementation, the libnl [[Wikipedia:Netlink|netlink]] communication and the nftables user-space front-end.<br />
The kernel provides a netlink configuration interface, as well as run-time rule-set evaluation, libnl contains the low-level functions for communicating with the kernel, and the nftables front-end is what the user interacts with via nft.<br />
<br />
You can also visit the [https://wiki.nftables.org/wiki-nftables/index.php/Main_Page official nftables wiki page] for more information.<br />
<br />
== Installation ==<br />
<br />
{{Expansion|Mention {{Pkg|iptables-nft}}.[https://www.redhat.com/en/blog/using-iptables-nft-hybrid-linux-firewall]}}<br />
<br />
[[Install]] the userspace utilities package {{Pkg|nftables}} or the git version {{AUR|nftables-git}}.<br />
<br />
{{Tip|Most [[iptables#Front-ends|iptables front-ends]] feature no direct or indirect support of nftables, but may introduce it.[https://www.spinics.net/lists/netfilter/msg58215.html] One graphical front-end that supports both, nftables and iptables, is [[firewalld]].[https://firewalld.org/2018/07/nftables-backend]}}<br />
<br />
== Usage ==<br />
<br />
'''nftables''' makes '''no''' distinction between temporary rules made in the command line and permanent ones loaded from or saved to a file.<br />
<br />
All rules have to be created or loaded using {{ic|nft}} command line utility.<br />
<br />
Refer to [[#Configuration]] section on how to use.<br />
<br />
Current ruleset can be printed with:<br />
<br />
# nft list ruleset<br />
<br />
=== Simple firewall ===<br />
<br />
{{Pkg|nftables}} comes with simple and secure firewall configuration stored in {{ic|/etc/nftables.conf}} file.<br />
<br />
The {{ic|nftables.service}} will load rules from that file when [[start/enable|started or enabled]].<br />
<br />
== Configuration ==<br />
<br />
nftables user-space utility {{ic|nft}} performs most of the rule-set evaluation before handing rule-sets to the kernel. Rules are stored in chains, which in turn are stored in tables. The following sections indicate how to create and modify these constructs.<br />
<br />
To read input from a file use the {{ic|-f}}/{{ic|--file}} option:<br />
<br />
# nft --file ''filename''<br />
<br />
Note that any rules already loaded are '''not''' automatically flushed.<br />
<br />
See {{man|8|nft}} for a complete list of all commands.<br />
<br />
=== Tables ===<br />
<br />
Tables hold [[#Chains]]. Unlike tables in iptables, there are no built-in tables in nftables. The number of tables and their names is up to the user. However, each table only has one address family and only applies to packets of this family. Tables can have one of five families specified:<br />
<br />
{| class="wikitable"<br />
! nftables family || iptables utility<br />
|-<br />
| ip || iptables<br />
|-<br />
| ip6 || ip6tables<br />
|- <br />
| inet || iptables and ip6tables<br />
|-<br />
| arp || arptables<br />
|-<br />
| bridge || ebtables<br />
|-<br />
|}<br />
<br />
{{ic|ip}} (i.e. IPv4) is the default family and will be used if family is not specified.<br />
<br />
To create one rule that applies to both IPv4 and IPv6, use {{ic|inet}}. {{ic|inet}} allows for the unification of the {{ic|ip}} and {{ic|ip6}} families to make defining rules for both easier.<br />
<br />
See {{man|8|nft|ADDRESS FAMILIES}} for a complete description of address families.<br />
<br />
In all of the following, {{ic|''family_type''}} is optional, and if not specified is set to {{ic|ip}}.<br />
<br />
==== Create table ====<br />
<br />
The following adds a new table:<br />
<br />
# nft add table ''family_type'' ''table_name''<br />
<br />
==== List tables ====<br />
<br />
To list all tables:<br />
<br />
# nft list tables<br />
<br />
==== List chains and rules in a table ====<br />
<br />
To list all chains and rules of a specified table do:<br />
<br />
# nft list table ''family_type'' ''table_name''<br />
<br />
For example, to list all the rules of the {{ic|my_table}} table of the {{ic|inet}} family:<br />
<br />
# nft list table inet my_table<br />
<br />
==== Delete table ====<br />
<br />
To delete a table do:<br />
<br />
# nft delete table ''family_type'' ''table_name''<br />
<br />
This will destroy all chains in the table.<br />
<br />
==== Flush table ====<br />
<br />
To flush all rules from a table do:<br />
<br />
# nft flush table ''family_type'' ''table_name''<br />
<br />
=== Chains ===<br />
<br />
The purpose of chains is to hold [[#Rules]]. Unlike chains in iptables, there are no built-in chains in nftables. This means that if no chain uses any types or hooks in the netfilter framework, packets that would flow through those chains will not be touched by nftables, unlike iptables.<br />
<br />
Chains have two types. A ''base'' chain is an entry point for packets from the networking stack, where a hook value is specified. A ''regular'' chain may be used as a jump target for better organization.<br />
<br />
In all of the following {{ic|''family_type''}} is optional, and if not specified is set to {{ic|ip}}.<br />
<br />
==== Create chain ====<br />
<br />
===== Regular chain =====<br />
<br />
The following adds a regular chain named {{ic|''chain_name''}} to the table named {{ic|''table_name''}}:<br />
<br />
# nft add chain ''family_type'' ''table_name'' ''chain_name''<br />
<br />
For example, to add a regular chain named {{ic|my_tcp_chain}} to the {{ic|my_table}} table of the {{ic|inet}} address family do:<br />
<br />
# nft add chain inet my_table my_tcp_chain<br />
<br />
===== Base chain =====<br />
<br />
To add a base chain specify hook and priority values:<br />
<br />
# nft add chain ''family_type'' ''table_name'' ''chain_name'' '{ type ''chain_type'' hook ''hook_type'' priority ''priority_value'' ; }'<br />
<br />
{{ic|''chain_type''}} can be {{ic|filter}}, {{ic|route}}, or {{ic|nat}}.<br />
<br />
For IPv4/IPv6/Inet address families {{ic|''hook_type''}} can be {{ic|prerouting}}, {{ic|input}}, {{ic|forward}}, {{ic|output}}, or {{ic|postrouting}}. See {{man|8|nft|ADDRESS FAMILIES}} for a list of hooks for other families.<br />
<br />
{{ic|''priority_value''}} takes either a priority name or an its integer value. See {{man|8|nft|CHAINS}} for a list of standard priority names and values. Chains with lower numbers are processed first and can be negative. [https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_types]<br />
<br />
For example, to add a base chain that filters input packets:<br />
<br />
# nft add chain inet my_table my_chain '{ type filter hook input priority 0; }'<br />
<br />
Replace {{ic|add}} with {{ic|create}} in any of the above to add a new chain but return an error if the chain already exists.<br />
<br />
==== List rules ====<br />
<br />
The following lists all rules of a chain:<br />
<br />
# nft list chain ''family_type'' ''table_name'' ''chain_name''<br />
<br />
For example, the following lists the rules of the chain named {{ic|my_output}} in the {{ic|inet}} table named {{ic|my_table}}:<br />
<br />
# nft list chain inet my_table my_output<br />
<br />
==== Edit a chain ====<br />
<br />
To edit a chain, simply call it by its name and define the rules you want to change.<br />
<br />
# nft chain ''family_type table_name chain_name'' '{ [ type ''chain_type'' hook ''hook_type'' device ''device_name'' priority ''priority_value'' ; policy ''policy_type'' ; ] }'<br />
<br />
For example, to change the {{ic|my_input}} chain policy of the default table from {{ic|accept}} to {{ic|drop}}<br />
<br />
# nft chain inet my_table my_input '{ policy drop ; }'<br />
<br />
==== Delete a chain ====<br />
<br />
To delete a chain do:<br />
<br />
# nft delete chain ''family_type'' ''table_name'' ''chain_name''<br />
<br />
The chain must not contain any rules or be a jump target.<br />
<br />
==== Flush rules from a chain ====<br />
<br />
To flush rules from a chain do:<br />
<br />
# nft flush chain ''family_type'' ''table_name'' ''chain_name''<br />
<br />
=== Rules ===<br />
<br />
Rules are either constructed from expressions or statements and are contained within chains.<br />
<br />
==== Add rule ====<br />
<br />
{{Tip|The ''iptables-translate'' utility translates [[iptables]] rules to nftables format.}}<br />
<br />
To add a rule to a chain do:<br />
<br />
# nft add rule ''family_type'' ''table_name'' ''chain_name'' handle ''handle_value'' ''statement''<br />
<br />
The rule is appended at {{ic|''my_handle''}}, which is optional. If not specified, the rule is appended to the end of the chain.<br />
<br />
To prepend the rule to the position do:<br />
<br />
# nft insert rule ''family_type'' ''table_name'' ''chain_name'' handle ''handle_value'' ''statement''<br />
<br />
If {{ic|''handle_value''}} is not specified, the rule is prepended to the chain.<br />
<br />
===== Expressions =====<br />
<br />
Typically a {{ic|''statement''}} includes some expression to be matched and then a verdict statement. Verdict statements include {{ic|accept}}, {{ic|drop}}, {{ic|queue}}, {{ic|continue}}, {{ic|return}}, {{ic|jump ''chain_name''}}, and {{ic|goto ''chain_name''}}. Other statements than verdict statements are possible. See {{man|8|nft}} for more information.<br />
<br />
There are various expressions available in nftables and, for the most part, coincide with their iptables counterparts. The most noticeable difference is that there are no generic or implicit matches. A generic match was one that was always available, such as {{ic|--protocol}} or {{ic|--source}}. Implicit matches were protocol-specific, such as {{ic|--sport}} when a packet was determined to be TCP.<br />
<br />
The following is an incomplete list of the matches available:<br />
<br />
* meta (meta properties, e.g. interfaces)<br />
* icmp (ICMP protocol)<br />
* icmpv6 (ICMPv6 protocol)<br />
* ip (IP protocol)<br />
* ip6 (IPv6 protocol)<br />
* tcp (TCP protocol)<br />
* udp (UDP protocol)<br />
* sctp (SCTP protocol)<br />
* ct (connection tracking)<br />
<br />
The following is an incomplete list of match arguments (for a more complete list, see {{man|8|nft}}):<br />
<br />
{{bc|<nowiki><br />
meta:<br />
oif <output interface INDEX><br />
iif <input interface INDEX><br />
oifname <output interface NAME><br />
iifname <input interface NAME><br />
<br />
(oif and iif accept string arguments and are converted to interface indexes)<br />
(oifname and iifname are more dynamic, but slower because of string matching)<br />
<br />
icmp:<br />
type <icmp type><br />
<br />
icmpv6:<br />
type <icmpv6 type><br />
<br />
ip:<br />
protocol <protocol><br />
daddr <destination address><br />
saddr <source address><br />
<br />
ip6:<br />
daddr <destination address><br />
saddr <source address><br />
<br />
tcp:<br />
dport <destination port><br />
sport <source port><br />
<br />
udp:<br />
dport <destination port><br />
sport <source port><br />
<br />
sctp:<br />
dport <destination port><br />
sport <source port><br />
<br />
ct:<br />
state <new | established | related | invalid><br />
</nowiki>}}<br />
<br />
==== Deletion ====<br />
<br />
Individual rules can only be deleted by their handles. The {{ic|nft --handle list}} command must be used to determine rule handles. Note the {{ic|--handle}} switch, which tells {{ic|nft}} to list handles in its output.<br />
<br />
The following determines the handle for a rule and then deletes it. The {{ic|--numeric}} argument is useful for viewing some numeric output, like unresolved IP addresses.<br />
<br />
{{hc|# nft --handle --numeric list chain inet my_table my_input|2=<nowiki><br />
table inet my_table {<br />
chain input {<br />
type filter hook input priority 0;<br />
ip saddr 127.0.0.1 accept # handle 10<br />
}<br />
}<br />
</nowiki>}}<br />
<br />
# nft delete rule inet my_table my_input handle 10<br />
<br />
All the chains in a table can be flushed with the {{ic|nft flush table}} command. Individual chains can be flushed using either the {{ic|nft flush chain}} or {{ic|nft delete rule}} commands.<br />
<br />
# nft flush table ''table_name''<br />
# nft flush chain ''family_type'' ''table_name'' ''chain_name''<br />
# nft delete rule ''family_type'' ''table_name'' ''chain_name''<br />
<br />
The first command flushes all of the chains in the ip {{ic|''table_name''}} table. The second flushes the {{ic|''chain_name''}} chain in the ip {{ic|foo}} table. The third deletes all of the rules in {{ic|''chain_name''}} chain in the {{ic|''family_type''}} {{ic|''table_name''}} table.<br />
<br />
=== Atomic reloading ===<br />
<br />
Flush the current ruleset:<br />
<br />
# echo "flush ruleset" > /tmp/nftables <br />
<br />
Dump the current ruleset:<br />
<br />
# nft -s list ruleset >> /tmp/nftables<br />
<br />
Now you can edit /tmp/nftables and apply your changes with:<br />
<br />
# nft -f /tmp/nftables<br />
<br />
== Examples ==<br />
<br />
=== Workstation ===<br />
<br />
{{hc|/etc/nftables.conf|2=<nowiki><br />
flush ruleset<br />
<br />
table inet my_table {<br />
chain my_input {<br />
type filter hook input priority 0; policy drop;<br />
<br />
iif lo accept comment "Accept any localhost traffic"<br />
ct state invalid drop comment "Drop invalid connections"<br />
ct state established,related accept comment "Accept traffic originated from us"<br />
<br />
meta l4proto ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, mld-listener-query, mld-listener-report, mld-listener-reduction, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report } accept comment "Accept ICMPv6"<br />
meta l4proto icmp icmp type { destination-unreachable, router-solicitation, router-advertisement, time-exceeded, parameter-problem } accept comment "Accept ICMP"<br />
ip protocol igmp accept comment "Accept IGMP"<br />
<br />
udp dport mdns ip6 daddr ff02::fb accept comment "Accept mDNS"<br />
udp dport mdns ip daddr 224.0.0.251 accept comment "Accept mDNS"<br />
<br />
udp sport 1900 udp dport >= 1024 ip6 saddr { fd00::/8, fe80::/10 } meta pkttype unicast limit rate 4/second burst 20 packets accept comment "Accept UPnP IGD port mapping reply"<br />
udp sport 1900 udp dport >= 1024 ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } meta pkttype unicast limit rate 4/second burst 20 packets accept comment "Accept UPnP IGD port mapping reply"<br />
<br />
udp sport netbios-ns udp dport >= 1024 meta pkttype unicast ip6 saddr { fd00::/8, fe80::/10 } accept comment "Accept Samba Workgroup browsing replies"<br />
udp sport netbios-ns udp dport >= 1024 meta pkttype unicast ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } accept comment "Accept Samba Workgroup browsing replies"<br />
<br />
counter comment "Count any other traffic"<br />
}<br />
<br />
chain my_forward {<br />
type filter hook forward priority 0; policy drop;<br />
# Drop everything forwarded to us. We do not forward. That is routers job.<br />
}<br />
<br />
chain my_output {<br />
type filter hook output priority 0; policy accept;<br />
# Accept every outbound connection<br />
}<br />
<br />
}<br />
</nowiki>}}<br />
<br />
=== Server ===<br />
<br />
{{hc|/etc/nftables.conf|2=<nowiki><br />
flush ruleset<br />
<br />
table inet my_table {<br />
chain my_input {<br />
type filter hook input priority 0; policy drop;<br />
<br />
iif lo accept comment "Accept any localhost traffic"<br />
ct state invalid drop comment "Drop invalid connections"<br />
ct state established,related accept comment "Accept traffic originated from us"<br />
<br />
meta l4proto ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, mld-listener-query, mld-listener-report, mld-listener-reduction, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report } accept comment "Accept ICMPv6"<br />
meta l4proto icmp icmp type { destination-unreachable, router-solicitation, router-advertisement, time-exceeded, parameter-problem } accept comment "Accept ICMP"<br />
ip protocol igmp accept comment "Accept IGMP"<br />
<br />
udp dport mdns ip6 daddr ff02::fb accept comment "Accept mDNS"<br />
udp dport mdns ip daddr 224.0.0.251 accept comment "Accept mDNS"<br />
<br />
tcp dport ssh accept comment "Accept SSH on port 22"<br />
<br />
tcp dport ipp accept comment "Accept IPP/IPPS on port 631"<br />
<br />
tcp dport { http, https, 8008, 8080 } accept comment "Accept HTTP (ports 80, 443, 8008, 8080)"<br />
<br />
meta l4proto { tcp, udp } th dport 2049 ip6 saddr { fd00::/8, fe80::/10 } accept comment "Accept NFS"<br />
meta l4proto { tcp, udp } th dport 2049 ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } accept comment "Accept NFS"<br />
<br />
udp dport netbios-ns ip6 saddr { fd00::/8, fe80::/10 } accept comment "Accept NetBIOS Name Service (nmbd)"<br />
udp dport netbios-ns ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } accept comment "Accept NetBIOS Name Service (nmbd)"<br />
udp dport netbios-dgm ip6 saddr { fd00::/8, fe80::/10 } accept comment "Accept NetBIOS Datagram Service (nmbd)"<br />
udp dport netbios-dgm ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } accept comment "Accept NetBIOS Datagram Service (nmbd)"<br />
tcp dport netbios-ssn ip6 saddr { fd00::/8, fe80::/10 } accept comment "Accept NetBIOS Session Service (smbd)"<br />
tcp dport netbios-ssn ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } accept comment "Accept NetBIOS Session Service (smbd)"<br />
tcp dport microsoft-ds ip6 saddr { fd00::/8, fe80::/10 } accept comment "Accept Microsoft Directory Service (smbd)"<br />
tcp dport microsoft-ds ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } accept comment "Accept Microsoft Directory Service (smbd)"<br />
<br />
udp sport bootpc udp dport bootps ip saddr 0.0.0.0 ip daddr 255.255.255.255 accept comment "Accept DHCPDISCOVER (for DHCP-Proxy)"<br />
udp sport { bootpc, 4011 } udp dport { bootps, 4011 } ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } accept comment "Accept PXE"<br />
udp dport tftp ip6 saddr { fd00::/8, fe80::/10 } accept comment "Accept TFTP"<br />
udp dport tftp ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } accept comment "Accept TFTP"<br />
<br />
}<br />
<br />
chain my_forward {<br />
type filter hook forward priority 0; policy drop;<br />
# Drop everything forwarded to us. We do not forward. That is routers job.<br />
}<br />
<br />
chain my_output {<br />
type filter hook output priority 0; policy accept;<br />
# Accept every outbound connection<br />
}<br />
<br />
}<br />
</nowiki>}}<br />
<br />
=== Limit rate ===<br />
<br />
{{bc|1=<nowiki><br />
table inet my_table {<br />
chain my_input {<br />
type filter hook input priority 0; policy drop;<br />
<br />
iif lo accept comment "Accept any localhost traffic"<br />
ct state invalid drop comment "Drop invalid connections"<br />
<br />
meta l4proto icmp icmp type echo-request limit rate over 10/second burst 4 packets drop comment "No ping floods"<br />
meta l4proto ipv6-icmp icmpv6 type echo-request limit rate over 10/second burst 4 packets drop comment "No ping floods"<br />
<br />
ct state established,related accept comment "Accept traffic originated from us"<br />
<br />
meta l4proto ipv6-icmp icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, mld-listener-query, mld-listener-report, mld-listener-reduction, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report } accept comment "Accept ICMPv6"<br />
meta l4proto icmp icmp type { destination-unreachable, router-solicitation, router-advertisement, time-exceeded, parameter-problem } accept comment "Accept ICMP"<br />
ip protocol igmp accept comment "Accept IGMP"<br />
<br />
tcp dport ssh ct state new limit rate 15/minute accept comment "Avoid brute force on SSH"<br />
<br />
}<br />
<br />
}<br />
</nowiki>}}<br />
<br />
=== Jump ===<br />
<br />
When using jumps in config file, it is necessary to define the target chain first. Otherwise one could end up with {{ic|Error: Could not process rule: No such file or directory}}.<br />
<br />
{{bc|1=<nowiki><br />
table inet my_table {<br />
chain web {<br />
tcp dport http accept<br />
tcp dport 8080 accept<br />
}<br />
chain my_input {<br />
type filter hook input priority 0;<br />
ip saddr 10.0.2.0/24 jump web<br />
drop<br />
}<br />
}<br />
</nowiki>}}<br />
<br />
=== Different rules for different interfaces ===<br />
<br />
If your box has more than one network interface, and you would like to use different rules for different interfaces, you may want to use a "dispatching" filter chain, and then interface-specific filter chains. For example, let us assume your box acts as a home router, you want to run a web server accessible over the LAN (interface {{ic|enp3s0}}), but not from the public internet (interface {{ic|enp2s0}}), you may want to consider a structure like this:<br />
<br />
{{bc|<nowiki><br />
table inet my_table {<br />
chain my_input { # this chain serves as a dispatcher<br />
type filter hook input priority 0;<br />
<br />
iif lo accept # always accept loopback<br />
iifname enp2s0 jump my_input_public<br />
iifname enp3s0 jump my_input_private<br />
<br />
reject with icmpx type port-unreachable # refuse traffic from all other interfaces<br />
}<br />
chain my_input_public { # rules applicable to public interface interface<br />
ct state {established,related} accept<br />
ct state invalid drop<br />
udp dport bootpc accept<br />
tcp dport bootpc accept<br />
reject with icmpx type port-unreachable # all other traffic<br />
}<br />
chain my_input_private {<br />
ct state {established,related} accept<br />
ct state invalid drop<br />
udp dport bootpc accept<br />
tcp dport bootpc accept<br />
tcp port http accept<br />
tcp port https accept<br />
reject with icmpx type port-unreachable # all other traffic<br />
}<br />
chain my_output { # we let everything out<br />
type filter hook output priority 0;<br />
accept<br />
}<br />
}<br />
</nowiki>}}<br />
<br />
Alternatively you could choose only one {{ic|iifname}} statement, such as for the single upstream interface, and put the default rules for all other interfaces in one place, instead of dispatching for each interface.<br />
<br />
=== Masquerading ===<br />
<br />
nftables has a special keyword {{ic|masquerade}} "where the source address is automagically set to the address of the output interface" ([https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_%28NAT%29#Masquerading source]). This is particularly useful for situations in which the IP address of the interface is unpredictable or unstable, such as the upstream interface of routers connecting to many ISPs. Without it, the Network Address Translation rules would have to be updated every time the IP address of the interface changed.<br />
<br />
To use it:<br />
<br />
* make sure masquerading is enabled in the kernel (true if you use the default kernel), otherwise during kernel configuration, set {{ic|1=CONFIG_NFT_MASQ=m}}.<br />
* the {{ic|masquerade}} keyword can only be used in chains of type {{ic|nat}}.<br />
* masquerading is a kind of source NAT, so only works in the output path.<br />
<br />
Example for a machine with two interfaces: LAN connected to {{ic|enp3s0}}, and public internet connected to {{ic|enp2s0}}:<br />
<br />
{{bc|<nowiki><br />
table inet my_nat {<br />
chain my_masquerade {<br />
type nat hook postrouting priority 100;<br />
oifname "enp2s0" masquerade<br />
}<br />
}<br />
</nowiki>}}<br />
<br />
Since the table type is {{ic|inet}} both IPv4 and IPv6 packets will be masqueraded. If you want only ipv4 packets to be masqueraded (since extra adress space of IPv6 makes NAT not required) {{ic|meta nfproto ipv4}} expression can be used infront of {{ic|oifname "enp2s0" masquerade}} or the table type can be changed to {{ic|ip}}.<br />
<br />
=== NAT with port forwarding ===<br />
<br />
{{Accuracy|I think {{ic|my_postrouting}} chain will cause the destination computer see that connections are made by router rather than from some global IP. Also this does not masquerade outbound traffic.}}<br />
<br />
This example will forward ports 22 and 80 to {{ic|''destination_ip''}}. You will need to set {{ic|net.ipv4.ip_forward}} and {{ic|net.ipv4.conf.''wan_interface''.forwarding}} to {{ic|1}} via [[sysctl]].<br />
<br />
{{bc|<br />
table ip my_nat {<br />
chain my_prerouting {<br />
type nat hook prerouting priority -100;<br />
<br />
tcp dport { ssh, http } dnat to ''destination_ip''<br />
}<br />
<br />
chain my_postrouting {<br />
type nat hook postrouting priority 100;<br />
<br />
ip daddr ''destination_ip'' masquerade<br />
}<br />
}<br />
}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Saving current rule set ===<br />
<br />
The output of {{ic|nft list ruleset}} command is a valid input file for it as well. Current rule set can be saved to file and later loaded back in.<br />
<br />
$ nft -s list ruleset | tee ''filename''<br />
<br />
{{Note|{{ic|nft list}} does not output variable definitions, if you had any in your original file they will be lost. Any variables used in rules will be replaced by their value.}}<br />
<br />
=== Simple stateful firewall ===<br />
<br />
{{Accuracy|This is not a very simple firewall. I would consider what Arch Linux ships in /etc/nftables.conf simple. Recommend replacing this section with that script and give some directions on how to expand it for specific needs.}}<br />
<br />
See [[Simple stateful firewall]] for more information.<br />
<br />
==== Single machine ====<br />
<br />
Flush the current ruleset:<br />
<br />
# nft flush ruleset<br />
<br />
Add a table:<br />
<br />
# nft add table inet my_table<br />
<br />
Add the input, forward, and output base chains. The policy for input and forward will be to drop. The policy for output will be to accept.<br />
<br />
# nft add chain inet my_table my_input '{ type filter hook input priority 0 ; policy drop ; }'<br />
# nft add chain inet my_table my_forward '{ type filter hook forward priority 0 ; policy drop ; }'<br />
# nft add chain inet my_table my_output '{ type filter hook output priority 0 ; policy accept ; }'<br />
<br />
Add two regular chains that will be associated with tcp and udp:<br />
<br />
# nft add chain inet my_table my_tcp_chain<br />
# nft add chain inet my_table my_udp_chain<br />
<br />
Related and established traffic will be accepted:<br />
<br />
# nft add rule inet my_table my_input ct state related,established accept<br />
<br />
All loopback interface traffic will be accepted:<br />
<br />
# nft add rule inet my_table my_input iif lo accept<br />
<br />
Drop any invalid traffic:<br />
<br />
# nft add rule inet my_table my_input ct state invalid drop<br />
<br />
Accept ICMP and IGMP:<br />
<br />
# nft add rule inet my_table my_input meta l4proto ipv6-icmp icmpv6 type '{ destination-unreachable, packet-too-big, time-exceeded, parameter-problem, mld-listener-query, mld-listener-report, mld-listener-reduction, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert, mld2-listener-report }' accept<br />
# nft add rule inet my_table my_input meta l4proto icmp icmp type '{ destination-unreachable, router-solicitation, router-advertisement, time-exceeded, parameter-problem }' accept<br />
# nft add rule inet my_table my_input ip protocol igmp accept<br />
<br />
New udp traffic will jump to the UDP chain:<br />
<br />
# nft add rule inet my_table my_input meta l4proto udp ct state new jump my_udp_chain<br />
<br />
New tcp traffic will jump to the TCP chain:<br />
<br />
# nft add rule inet my_table my_input 'meta l4proto tcp tcp flags & (fin|syn|rst|ack) == syn ct state new jump my_tcp_chain'<br />
<br />
Reject all traffic that was not processed by other rules:<br />
<br />
# nft add rule inet my_table my_input meta l4proto udp reject<br />
# nft add rule inet my_table my_input meta l4proto tcp reject with tcp reset<br />
# nft add rule inet my_table my_input counter reject with icmpx type port-unreachable<br />
<br />
At this point you should decide what ports you want to open to incoming connections, which are handled by the TCP and UDP chains. For example to open connections for a web server add:<br />
<br />
# nft add rule inet my_table my_tcp_chain tcp dport 80 accept<br />
<br />
To accept HTTPS connections for a webserver on port 443:<br />
<br />
# nft add rule inet my_table my_tcp_chain tcp dport 443 accept<br />
<br />
To accept SSH traffic on port 22:<br />
<br />
# nft add rule inet my_table my_tcp_chain tcp dport 22 accept<br />
<br />
To accept incoming DNS requests:<br />
<br />
# nft add rule inet my_table my_tcp_chain tcp dport 53 accept<br />
# nft add rule inet my_table my_udp_chain udp dport 53 accept<br />
<br />
Be sure to make your changes permanent when satisifed.<br />
<br />
=== Prevent brute-force attacks ===<br />
<br />
[[Sshguard]] is program that can detect brute-force attacks and modify firewalls based on IP addresses it temporarily blacklists. See [[Sshguard#nftables]] on how to set up nftables to be used with it.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Working with Docker ===<br />
<br />
Using nftables can interfere with [[Docker]] networking (and probably other container runtimes as well). In particular the drop policy for the {{ic|forward}} chain will block packets originating in docker containers. If you want to keep the {{ic|forward}} rule in your {{ic|inet}} table, you can use the following:<br />
<br />
# [[Install]] {{Pkg|iptables-nft}} to provide an iptables compatible interface for nftables that docker can use.<br />
# Use the following for the {{ic|forward}} chain in your {{ic|inet}} table:<br />
#:{{bc|<nowiki><br />
chain forward {<br />
type filter hook forward priority security; policy drop;<br />
mark 1 accept<br />
</nowiki>}}<br />
# Add a rule to the DOCKER-USER chain in the {{ic|ip filter}} table to mark packets if docker is running:<br />
#:{{bc|<nowiki><br />
table ip filter {<br />
chain DOCKER-USER {<br />
mark set 1<br />
}<br />
}<br />
</nowiki>}}<br />
<br />
This works by marking packets if docker is active, and accepting the packets in this case, since docker has already filtered them (the forward chain defined by docker uses a drop policy).<br />
<br />
== See also ==<br />
<br />
* [https://wiki.nftables.org/ netfilter nftables wiki]<br />
* [[debian:nftables]]<br />
* [[gentoo:nftables]]<br />
* [https://lwn.net/Articles/324251/ First release of nftables]<br />
* [https://home.regit.org/netfilter-en/nftables-quick-howto/ nftables quick howto]<br />
* [https://lwn.net/Articles/564095/ The return of nftables]<br />
* [https://developers.redhat.com/blog/2016/10/28/what-comes-after-iptables-its-successor-of-course-nftables/ What comes after ‘iptables’? Its successor, of course: `nftables`]</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:AMDGPU&diff=617949Talk:AMDGPU2020-06-03T17:34:45Z<p>Strikemybread: Update kernel version</p>
<hr />
<div>== Supported Hardware ==<br />
I just crawled the product names "Radeon xyz" of VI/CI GPUs together and was going to go on for professional products "FirePro xzy", too.<br />
<br />
Afaik, there is no such complete listing on the web. There is a lot of confusion about the code and product names, due to AMD repeatedly rebranding their products and even change code names for same GPUs (Tonga = Antigua, Hawaii = Grenada, Carrizo = Bristol Ridge?, ...)<br />
<br />
When I started using gnu/linux, the arch wiki was a great help and there are still a lot of people struggling with graphics drivers. Now I know it is not hard to understand, but it is still confusing for beginners, coming from windows and just being used to install one software suite (not a drm driver, libdrm, mesa, gallium, etc.), supporting all the current hardware.<br />
<br />
now everyone has to go through all of this every time to determine 1) which hardware is really in their product and 2) which driver suits their hardware<br />
<br />
<br />
tl;dr I think maintaining such a list would be really useful for beginners, maybe not here but in a separate article?<br />
[[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 09:27, 16 February 2016 (UTC)<br />
<br />
:Well, [https://wiki.gentoo.org/wiki/Amdgpu#Feature_support Gentoo wiki] has a simple two-line summary. If it's still not sufficiently clear or the list is already much larger, I guess we could have a separate subpage to not clutter the main page... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:20, 16 February 2016 (UTC)<br />
<br />
:: yes, in the meantime I also found this table. It looks good but it is not complete. And completing the list would blow up the table cells a lot. I guess we should wait until vulkan and the new OpenCL driver has been released. Until then, there is no real reason for owners of pre-VI hardware to switch over to amdgpu. All vi and post-vi will be covered, so there is no need to list those separately. For the others I could create a subpage when switching to amdgpu gives you the opportunity for opencl 2.1 and vulkan -- [[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 10:50, 16 February 2016 (UTC)<br />
<br />
== Enable amdgpu for Sea Islands Cards ==<br />
testing my Hawaii card w/ amdgpu last week, sound did not work, even though 6 pcm/hdmi audio devices were listed. Might be added as an issue (as I think this is important deciding between radeon and amdgpu), but needs further investigation/confirmation from other testers.<br />
[[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 09:53, 16 February 2016 (UTC)<br />
:Please remember the AMDGPU is still in beta, and there's still info and knowledge/experience missing (e.g. most users use the Radeon driver).<br />
:AMD isn't that great in providing info and so far a lot of users are confused about their hardware support in use with amdgpu.<br />
:Remember there are flags like {{ic|exp_hw_support}}. More info need to be added, but it will take some time.<br />
:[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 13:14, 16 February 2016 (UTC)<br />
: It does indeed seem like that was no CI issue. Audio over hdmi is not supported by amdgpu atm, respectively only with the (upcoming) DAL changes[http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/853189-audio-over-hdmi-tonga-and-amdgpu], although it is listed as 'done' [http://xorg.freedesktop.org/wiki/RadeonFeature/ here]. [[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 15:59, 22 February 2016 (UTC)<br />
<br />
== Sea Islands cards not working with 4.5.x? ==<br />
I stumbled across this wiki page in hopes of getting more performance after seeing Michael from Phoronix get his 290 working with this. Following through all the instructions, menuconfiging and compiling new kernels, in the end all I get is a blank screen with my r9 390. No errors on Xorg.0.log. Can anyone confirm that it isn't just me?<br />
[[User:Katorisenko|Katorisenko]] ([[User talk:Katorisenko|talk]]) 07:46, 24 April 2016 (UTC)<br />
<br />
== AMDGPU and HDMI Audio ==<br />
<br />
According to [https://bugzilla.freedesktop.org/show_bug.cgi?id=92827#c2 this Freedesktop.org bug comment], HDMI audio support in AMDGPU requires DAL which is "not upstream yet", and won't be anytime soon according to [http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-DRM-No this Phoronix article]. I'm currently struggling to make my HDMI audio work with my AMD Radeon R9 380; if this happens to be impossible with AMDGPU, should we mention it in the "Troubleshooting" section of this page? --[[User:Hellpe|Hellpe]] ([[User talk:Hellpe|talk]]) 23:26, 3 January 2017 (UTC)<br />
<br />
:I am in favor of adding the information notice to the troubleshooting section. I think users who do not keep up with the news will be confused when Pulseaudio seems to add the HDMI audio devices, despite them being non-functional until the DAL code is refactored and accepted upstream then pushed to regular users. I know it was not immediately clear to me when I upgraded from my radeonsi card to an RX series amdgpu card until I did some reading. I "think" currently the only way to get HDMI audio is to use the AMDGPU-PRO driver for the time being. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 15:48, 4 January 2017 (UTC)<br />
<br />
::I have it working with an R9 380 under Xorg. I did nothing special, simply disabled the built-in audio and enabled the HDMI audio. It does not work under Wayland however. Pavucontrol shows unavailable. [[User:Unit73e|Unit73e]] ([[User talk:Unit73e|talk]]) 12:22, 2 December 2017 (UTC)<br />
<br />
== Some experiments with integrated AMD graphics ==<br />
<br />
Some results after playing with "radeon" and "amdgpu" drivers and gnome (for AMD A10 7850K):<br />
<br />
- Having both drivers loaded causes systemd to hang at system shutdown (xorg). Using amdgpu and blacklisting radeon or using radeon and blacklisting amdgpu both fix this problem.<br />
<br />
- Having amdgpu driver without mkinitcpio.conf entry causes<br />
1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11"<br />
2. HDMI sound output is shown only in rare cases<br />
<br />
- Having amdgpu driver with mkinitcpio.conf entry causes<br />
1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland"<br />
2. HDMI sound is always disabled<br />
<br />
- Having radeon driver without mkinitcpio.conf entry causes<br />
1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11"<br />
2. HDMI sound is always correctly detected and working<br />
<br />
- Having radeon driver with mkinitcpio.conf entry<br />
1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland"<br />
2. HDMI sound is always correctly detected and working<br />
<br />
[[User:Beoldhin|Beoldhin]] ([[User talk:Beoldhin|talk]]) 19:07, 23 May 2017 (UTC)<br />
<br />
Update: with kernel 4.11.2-1: HDMI sound output is now working with "amdgpu" but only in as "Gnome in xorg" login option (still no sound with Wayland). There are still some graphical glitches when running Wayland with the radeon driver: external screen doesn't turn off after timeout, windows can't be maximized with the "wmctrl" command and updating text in terminal causes some text updating problems (these don't exist with xorg, amdgpu and radeon both work fine). So in summary: I can now select either amdgpu or radeon driver but Wayland is still unstable.<br />
<br />
[[User:Beoldhin|Beoldhin]] ([[User talk:Beoldhin|talk]]) 19:07, 23 May 2017 (UTC)<br />
<br />
== Vega Changes for Wiki ==<br />
<br />
With Vega releasing around the end of the month, the DC/DAL is still not it the kernel. Should we just put a note for users to use the AMDGPU-PRO drivers if they have VEGA cards? We could possibly add a note saying that in the AUR, there is an alternate kernel built from their repos with the DC/DAL code. <br />
Alternate kernel--> https://aur.archlinux.org/packages/linux-amd-staging-git/ [[User:Sesese9|Sesese9]] ([[User talk:Sesese9|talk]]) 00:40, 10 July 2017 (UTC)<br />
<br />
== Moving "Enable GPU display scaling" to xrandr ==<br />
<br />
I thought about it to put this under xrandr directly, but for example for my integrated Intel 6th gen GPU I don't have the "scaling mode" option, and I don't know about NVIDIA.<br />
And even if the "scaling mode" option exists for other vendors and or cards, I don't know if the possible values for "scaling mode" are the same everywhere, as far as I remember there are not.<br />
That was the reason I did put it here. [[User:Bertl|Bertl]] ([[User talk:Bertl|talk]]) 16:01, 18 February 2018 (UTC)<br />
:Ok, looks like [[Intel_graphics#Setting_scaling_mode|Intel]] uses the same settings, but it's only available for internal (LVDS, eDP) ports, but at least according to https://bugs.freedesktop.org/show_bug.cgi?id=90989 it also uses "None, Full, Center, Full aspect".<br />
:I know that radeonsi uses the same commands, but still don't know about NVIDIA.<br />
:But yea, now I also think that it should be moved and the [[Intel_graphics#Setting_scaling_mode|Intel]] section should be merged into it. [[User:Bertl|Bertl]] ([[User talk:Bertl|talk]]) 18:37, 18 February 2018 (UTC)<br />
<br />
== Update on kernel parameters ==<br />
<br />
this part does not seems to be required on 4.17:<br />
<br />
>> Also, since kernel 4.13, adding the amdgpu.si_support=1 radeon.si_support=0 or amdgpu.cik_support=1 radeon.cik_support=0 kernel parameter is required. Otherwise, AMDGPU will not start and you will end up with either radeon being used instead or the display being frozen during the boot.<br />
<br />
{{unsigned|12:10, 22 April 2018|Lesto}}<br />
<br />
== Renaming AMDGPU-PRO to Radeon Software for Linux? ==<br />
<br />
So AMD basically changed the name of their AMDGPU-PRO driver as simply Radeon™ Software for Linux, see [https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx 17.40], [https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-for-Linux-Release-Notes.aspx 18.10] and [https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-for-Linux-18.20-Early-Preview-Release-Notes.aspx 18.20 preview] release notes. With that in mind, should the names on wiki be slowly changed, or the alternative name/note being added somewhere? I'm not sure if AMDGPU-PRO is still used by AMD officially and whether AMDGPU (without PRO) term is being used as well, but the name sure definitely stuck among community – any ideas? [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 17:33, 11 May 2018 (UTC)<br />
<br />
EDIT: Probably worth noticing is the similar situation happened between [[Fglrx]] and [[AMD Catalyst]] naming back then. [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 17:38, 11 May 2018 (UTC)<br />
<br />
== Vulkan support for FreeSync on Mesa 19.1 ==<br />
<br />
Mesa 19.1 recently came out and it supposedly has FreeSync support for Vulkan. I can't test it right now but I was running the freesync patch before 19.1 and it worked for me. Anyone can confirm it is working on 19.1 and edit the FreeSync part about "only OpenGL is supported"<br />
<br />
[[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 08:56, 5 July 2019 (UTC)<br />
<br />
== Move Variable Refresh Rate to New Page ==<br />
<br />
NVIDIA has supported freesync for a while now as well as having their own variable refresh rate technology (Gsync). I think it would make more sense to make a separate page for it.<br />
[[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 17:00, 2 August 2019 (UTC)<br />
<br />
:I have started writing the article on my [[User:Cknight70#Variable_refresh_rate|personal page]]. Please feel free to make edits, I will create the new page in a couple of days if there are no objections. [[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 18:58, 3 August 2019 (UTC)<br />
<br />
::Check out [[Variable Refresh Rate]] [[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 15:49, 9 August 2019 (UTC)<br />
<br />
== OpenCL implementation? ==<br />
<br />
I've just spent the past day finding out how to get OpenCL to work with AMDGPU and I just found the answer on the [[Blender]] page by using {{AUR|opencl-amd}}. I don't really know if it would fit in with the page (as I could of solved this much sooner by searching up OpenCL and just looking at [[GPGPU]]) but I was still confused by people saying that only AMDGPU-PRO has OpenCL 2 support, so if it was mentioned somehow on the page I think it would be very helpful.<br />
[[User:Polygonerror|Polygonerror]] ([[User talk:Polygonerror|talk]]) 15:45, 20 December 2019 (UTC)<br />
<br />
== Navi power consumption addition: Idle power consumption & memory clocks with Navi 10 and multiple monitors ==<br />
<br />
Using a Gigabyte 5700 XT Gaming OC and 2 Monitors (LG OLED 55" and Dell 25") connected, the GPU won't throttle down and uses around 30W in idle.<br />
Xorg.conf and xrandr etc. don't help.<br />
A workaround is to suspend and resume, using the following as an systemd user job.<br />
<br />
.config/systemd/user/xrandr.service<br />
[Unit]<br />
Description=xrandr<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=oneshot<br />
Environment=DISPLAY=:0<br />
ExecStart=/usr/bin/xrandr -s 2560x1440 --dpi 117 --output DisplayPort-2 --mode 2560x1440 --primary --output HDMI-A-0 --same-as DisplayPort-2 --scale-from 2560x1440 --mode 1920x1080 --rate 60 --dpi 96<br />
ExecStart=/usr/bin/xrandr --output HDMI-A-0 --off<br />
<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
<br />
Change ports and resolutions and enable with<br />
<br />
systemctl --user enable xrandr<br />
<br />
Setting --rate of the LG OLED to 120 will not reduce power consumption as much, because the GPU needs to clock the memory higher.<br />
<br />
Everything works as expected after resuming. Power1 from amdgpu is around 9-10W in idle.<br />
<br />
Is there anything official to fix this that I didn't find?<br />
<br />
The problem is still present in 5.5.15-1-ck and 5.6rc7-1.<br />
<br />
Is it OK to include this in the troubleshooting section ?<br />
<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]]) 11:29, 7 April 2020 (UTC)<br />
<br />
: still present in 5.7-mainline [[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]])</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:Nftables&diff=617848Talk:Nftables2020-06-03T14:46:15Z<p>Strikemybread: /* add CUPS to example */</p>
<hr />
<div>==Bad practice and redundant code==<br />
Sitting beside the nftables maintainer, asking for feedback.<br />
<br />
This page's sample rulesets could use a good cleanup. I'll do that soon.<br />
<br />
TCP flag checks are not necessary, because you can just check for whether the packet is in an invalid state, or just not whitelist:<br />
<pre>/* table of valid flag combinations - PUSH, ECE and CWR are always valid */<br />
static const u8 tcp_valid_flags[(TCPHDR_FIN|TCPHDR_SYN|TCPHDR_RST|TCPHDR_ACK|<br />
TCPHDR_URG) + 1] =<br />
{<br />
[TCPHDR_SYN] = 1,<br />
[TCPHDR_SYN|TCPHDR_URG] = 1,<br />
[TCPHDR_SYN|TCPHDR_ACK] = 1,<br />
[TCPHDR_RST] = 1,<br />
[TCPHDR_RST|TCPHDR_ACK] = 1,<br />
[TCPHDR_FIN|TCPHDR_ACK] = 1,<br />
[TCPHDR_FIN|TCPHDR_ACK|TCPHDR_URG] = 1,<br />
[TCPHDR_ACK] = 1,<br />
[TCPHDR_ACK|TCPHDR_URG] = 1,<br />
};<br />
</pre><br />
<br />
ICMPv6 rate limiting like in the example is just stupid, for it breaks neighbour discovery (IPv6 ARP), ICMP isn't expensive to process, and it's not ICMP in of itself that is the problem. Anyhow, QoS is the job of the traffic control subsystem.<br />
<br />
We probably should make not of kernel requirements for rulesets (e.g., 3.18+, so won't work with 3.14 linux-lts).<br />
<br />
Maybe we should also provide guidance for getting upstream documentation, and troubleshooting. Attendance to netdev01 confirmed that it is in quite active development, and lots of usability features and fixes are in the pipeline.<br />
<br />
Allowing all ICMP is not necessary, and is already handled by conntrack RELATED,ESTABLISHED.<br />
-- alp (2015-02-17<br />
<br />
== syntax improvements ==<br />
<br />
I noticed there is a request to add '' italics for pseudo variables''. I am planning on doing that.<br />
<br />
However, I would also want to rename some of those variables to make it even more apparent that they can be changed to whatever you want. For example, {{ic|table inet filter}} I would change to {{ic|table inet ''my_filter''}}. Any objections?<br />
<br />
[[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 01:41, 18 January 2020 (UTC)<br />
<br />
: No, absolutely no objections. Though, my personal preference would be to stick to ''filter'' respectively something which can be copy pasted without having to adapt it. In other words, a name which a sysadmin might reasonably choose on his or her system. IMHO this makes it easier for users who want to do exactly the thing that is described in the article and spares them from having to rename ''my_filter'' to something sensible. [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 08:24, 18 January 2020 (UTC)<br />
<br />
:I have no opinion on {{ic|filter}} vs {{ic|my_filter}}. My main concern is that pseudo-variables should not match the nft syntax keywords (see examples in the style template in [[nftables#top]]). -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:09, 18 January 2020 (UTC)<br />
<br />
: Exactly. '''filter''' is actually keyword in some statements. '''my_filter''' is not and probably never will be. [[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 20:36, 18 January 2020 (UTC)<br />
<br />
:: Ok. I went over the page. Psedo variables are should be ''*_name'' or ''*_type''. The examples use my_* naming scheme for non key word arguments. [[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 23:37, 18 January 2020 (UTC)<br />
<br />
::: For those wondering, like myself: this section probably related to [[special:diff/603849]]. Which is probably related to [[special:diff/595487]]. I think the section here should now be deleted, since it was resolved. Other than {{ic|filterName}} vs {{ic|my_filter}}, aren't all comments in agreement? As an aside, other then differently emphasizing the keyword and the name, I think {{man|8|nft}} is using exactly what claimed here to be confusing. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 12:42, 3 April 2020 (UTC)<br />
<br />
== Imperative vs Declarative syntax. ==<br />
<br />
nftables supports two types of syntax.<br />
<br />
Imperative. Used in {{ic|nft}} command, interactive mode and scripts:<br />
<br />
{{ic|nft add table family_type table_name}}<br />
<br />
can also be in the file with shebang<br />
<br />
{{hc|somefile|<br />
#/usr/bin/nft -f<br />
add table ''family_type'' ''table_name''}}<br />
<br />
Declerative. Only used in configuration:<br />
<br />
{{bc|<br />
...<br />
table ''family_type'' ''table_name'' <nowiki>{</nowiki><br />
...<br />
<nowiki>}</nowiki>}}<br />
<br />
Right now the '''Configuration''' section only gives examples in the imperative syntax, however, '''Example''' section only show declarative syntax. What do you think about showing how to use declarative syntax in configuration alongside the nft commands? At the top of Configuration section will be the explanation when each syntax is used.<br />
<br />
So the '''Create table''' section would look like this:<br />
<br />
==== Create table ====<br />
<br />
The following adds a new table at run-time:<br />
<br />
# nft add table ''family_type'' ''table_name''<br />
<br />
Declaring table in configuration file:<br />
<br />
{{bc|<br />
...<br />
table ''family_type'' ''table_name'' <nowiki>{</nowiki><br />
...<br />
<nowiki>}</nowiki>}}<br />
<br />
<br />
I also added some Accuracy templates in the areas I thought the examples in the article were not accurate. Tell me what you think of accuracy of those sections.<br />
<br />
: I agree, declarative syntax is much easier to understand, and translates directly to imperative syntax. I plan on writing a subsection on configuration explaining the differences and use cases of each before touching on the already existing subsections, but the configuration section needs some improvements for clarity as well. [[User:Ivanmlerner|Ivanmlerner]] ([[User talk:Ivanmlerner|talk]]) 17:28, 18 April 2020 (UTC)<br />
<br />
== add CUPS to example ==<br />
<br />
Since there is not much more information about cups and (nft)firewall rules than [https://www.cups.org/doc/firewalls.html CUPS Wiki], I added this to nftables.conf :<br />
<br />
tcp dport 53 accept<br />
udp dport 53 accept<br />
<br />
tcp dport 631 accept<br />
<br />
udp dport 5353 accept<br />
<br />
Missing those, CUPS cannot find network printers with nftable service started. Maybe this can be simplified by using "ipp" instead of port numbers, but I didn't test yet.<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]])<br />
<br />
:To discover network printers it should be enough to allow mDNS (UDP 5353), which already is in [[nftables#Examples]]. Also make note of the "Direction" in CUPS docs, you do not want to allow port 53 on an input chain.<br />
:The proper place to list the needed ports would be in articles of the software that requires those ports to be open. [[CUPS#Network]] says that it needs mDNS, thus UDP 5353, so there's no need to reiterate that. [[CUPS/Printer sharing]] does not state which ports should be opened, so that can be improved; since there are many options, the upstream doc could be linked from that page.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:08, 3 June 2020 (UTC)<br />
<br />
:Actually, adding 631 to [[nftables#Server]] should not be an issue, since the "server" could be a print server. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:11, 3 June 2020 (UTC)<br />
<br />
::In my initial test, 5353 wasn't enough, maybe I didn't wait long enough. Thanks for pointing that out, the printer can be used with only one extra port open. It's still strange that even in the nftables wiki, you don't find CUPS nor printer. [[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]])</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:Nftables&diff=617841Talk:Nftables2020-06-03T13:44:40Z<p>Strikemybread: /* add CUPS to example */ new section</p>
<hr />
<div>==Bad practice and redundant code==<br />
Sitting beside the nftables maintainer, asking for feedback.<br />
<br />
This page's sample rulesets could use a good cleanup. I'll do that soon.<br />
<br />
TCP flag checks are not necessary, because you can just check for whether the packet is in an invalid state, or just not whitelist:<br />
<pre>/* table of valid flag combinations - PUSH, ECE and CWR are always valid */<br />
static const u8 tcp_valid_flags[(TCPHDR_FIN|TCPHDR_SYN|TCPHDR_RST|TCPHDR_ACK|<br />
TCPHDR_URG) + 1] =<br />
{<br />
[TCPHDR_SYN] = 1,<br />
[TCPHDR_SYN|TCPHDR_URG] = 1,<br />
[TCPHDR_SYN|TCPHDR_ACK] = 1,<br />
[TCPHDR_RST] = 1,<br />
[TCPHDR_RST|TCPHDR_ACK] = 1,<br />
[TCPHDR_FIN|TCPHDR_ACK] = 1,<br />
[TCPHDR_FIN|TCPHDR_ACK|TCPHDR_URG] = 1,<br />
[TCPHDR_ACK] = 1,<br />
[TCPHDR_ACK|TCPHDR_URG] = 1,<br />
};<br />
</pre><br />
<br />
ICMPv6 rate limiting like in the example is just stupid, for it breaks neighbour discovery (IPv6 ARP), ICMP isn't expensive to process, and it's not ICMP in of itself that is the problem. Anyhow, QoS is the job of the traffic control subsystem.<br />
<br />
We probably should make not of kernel requirements for rulesets (e.g., 3.18+, so won't work with 3.14 linux-lts).<br />
<br />
Maybe we should also provide guidance for getting upstream documentation, and troubleshooting. Attendance to netdev01 confirmed that it is in quite active development, and lots of usability features and fixes are in the pipeline.<br />
<br />
Allowing all ICMP is not necessary, and is already handled by conntrack RELATED,ESTABLISHED.<br />
-- alp (2015-02-17<br />
<br />
== syntax improvements ==<br />
<br />
I noticed there is a request to add '' italics for pseudo variables''. I am planning on doing that.<br />
<br />
However, I would also want to rename some of those variables to make it even more apparent that they can be changed to whatever you want. For example, {{ic|table inet filter}} I would change to {{ic|table inet ''my_filter''}}. Any objections?<br />
<br />
[[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 01:41, 18 January 2020 (UTC)<br />
<br />
: No, absolutely no objections. Though, my personal preference would be to stick to ''filter'' respectively something which can be copy pasted without having to adapt it. In other words, a name which a sysadmin might reasonably choose on his or her system. IMHO this makes it easier for users who want to do exactly the thing that is described in the article and spares them from having to rename ''my_filter'' to something sensible. [[User:Edh|Edh]] ([[User talk:Edh|talk]]) 08:24, 18 January 2020 (UTC)<br />
<br />
:I have no opinion on {{ic|filter}} vs {{ic|my_filter}}. My main concern is that pseudo-variables should not match the nft syntax keywords (see examples in the style template in [[nftables#top]]). -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:09, 18 January 2020 (UTC)<br />
<br />
: Exactly. '''filter''' is actually keyword in some statements. '''my_filter''' is not and probably never will be. [[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 20:36, 18 January 2020 (UTC)<br />
<br />
:: Ok. I went over the page. Psedo variables are should be ''*_name'' or ''*_type''. The examples use my_* naming scheme for non key word arguments. [[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 23:37, 18 January 2020 (UTC)<br />
<br />
::: For those wondering, like myself: this section probably related to [[special:diff/603849]]. Which is probably related to [[special:diff/595487]]. I think the section here should now be deleted, since it was resolved. Other than {{ic|filterName}} vs {{ic|my_filter}}, aren't all comments in agreement? As an aside, other then differently emphasizing the keyword and the name, I think {{man|8|nft}} is using exactly what claimed here to be confusing. [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 12:42, 3 April 2020 (UTC)<br />
<br />
== Imperative vs Declarative syntax. ==<br />
<br />
nftables supports two types of syntax.<br />
<br />
Imperative. Used in {{ic|nft}} command, interactive mode and scripts:<br />
<br />
{{ic|nft add table family_type table_name}}<br />
<br />
can also be in the file with shebang<br />
<br />
{{hc|somefile|<br />
#/usr/bin/nft -f<br />
add table ''family_type'' ''table_name''}}<br />
<br />
Declerative. Only used in configuration:<br />
<br />
{{bc|<br />
...<br />
table ''family_type'' ''table_name'' <nowiki>{</nowiki><br />
...<br />
<nowiki>}</nowiki>}}<br />
<br />
Right now the '''Configuration''' section only gives examples in the imperative syntax, however, '''Example''' section only show declarative syntax. What do you think about showing how to use declarative syntax in configuration alongside the nft commands? At the top of Configuration section will be the explanation when each syntax is used.<br />
<br />
So the '''Create table''' section would look like this:<br />
<br />
==== Create table ====<br />
<br />
The following adds a new table at run-time:<br />
<br />
# nft add table ''family_type'' ''table_name''<br />
<br />
Declaring table in configuration file:<br />
<br />
{{bc|<br />
...<br />
table ''family_type'' ''table_name'' <nowiki>{</nowiki><br />
...<br />
<nowiki>}</nowiki>}}<br />
<br />
<br />
I also added some Accuracy templates in the areas I thought the examples in the article were not accurate. Tell me what you think of accuracy of those sections.<br />
<br />
: I agree, declarative syntax is much easier to understand, and translates directly to imperative syntax. I plan on writing a subsection on configuration explaining the differences and use cases of each before touching on the already existing subsections, but the configuration section needs some improvements for clarity as well. [[User:Ivanmlerner|Ivanmlerner]] ([[User talk:Ivanmlerner|talk]]) 17:28, 18 April 2020 (UTC)<br />
<br />
== add CUPS to example ==<br />
<br />
Since there is not much more information about cups and (nft)firewall rules than [https://www.cups.org/doc/firewalls.html CUPS Wiki], I added this to nftables.conf :<br />
<br />
tcp dport 53 accept<br />
udp dport 53 accept<br />
<br />
tcp dport 631 accept<br />
<br />
udp dport 5353 accept<br />
<br />
Missing those, CUPS cannot find network printers with nftable service started. Maybe this can be simplified by using "ipp" instead of port numbers, but I didn't test yet.<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]])</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:AMDGPU&diff=604520Talk:AMDGPU2020-04-07T11:29:01Z<p>Strikemybread: /* Navi power consumption addition: Idle power consumption & memory clocks with Navi 10 and multiple monitors */ Forgot to sign the comment.</p>
<hr />
<div>== Supported Hardware ==<br />
I just crawled the product names "Radeon xyz" of VI/CI GPUs together and was going to go on for professional products "FirePro xzy", too.<br />
<br />
Afaik, there is no such complete listing on the web. There is a lot of confusion about the code and product names, due to AMD repeatedly rebranding their products and even change code names for same GPUs (Tonga = Antigua, Hawaii = Grenada, Carrizo = Bristol Ridge?, ...)<br />
<br />
When I started using gnu/linux, the arch wiki was a great help and there are still a lot of people struggling with graphics drivers. Now I know it is not hard to understand, but it is still confusing for beginners, coming from windows and just being used to install one software suite (not a drm driver, libdrm, mesa, gallium, etc.), supporting all the current hardware.<br />
<br />
now everyone has to go through all of this every time to determine 1) which hardware is really in their product and 2) which driver suits their hardware<br />
<br />
<br />
tl;dr I think maintaining such a list would be really useful for beginners, maybe not here but in a separate article?<br />
[[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 09:27, 16 February 2016 (UTC)<br />
<br />
:Well, [https://wiki.gentoo.org/wiki/Amdgpu#Feature_support Gentoo wiki] has a simple two-line summary. If it's still not sufficiently clear or the list is already much larger, I guess we could have a separate subpage to not clutter the main page... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:20, 16 February 2016 (UTC)<br />
<br />
:: yes, in the meantime I also found this table. It looks good but it is not complete. And completing the list would blow up the table cells a lot. I guess we should wait until vulkan and the new OpenCL driver has been released. Until then, there is no real reason for owners of pre-VI hardware to switch over to amdgpu. All vi and post-vi will be covered, so there is no need to list those separately. For the others I could create a subpage when switching to amdgpu gives you the opportunity for opencl 2.1 and vulkan -- [[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 10:50, 16 February 2016 (UTC)<br />
<br />
== Enable amdgpu for Sea Islands Cards ==<br />
testing my Hawaii card w/ amdgpu last week, sound did not work, even though 6 pcm/hdmi audio devices were listed. Might be added as an issue (as I think this is important deciding between radeon and amdgpu), but needs further investigation/confirmation from other testers.<br />
[[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 09:53, 16 February 2016 (UTC)<br />
:Please remember the AMDGPU is still in beta, and there's still info and knowledge/experience missing (e.g. most users use the Radeon driver).<br />
:AMD isn't that great in providing info and so far a lot of users are confused about their hardware support in use with amdgpu.<br />
:Remember there are flags like {{ic|exp_hw_support}}. More info need to be added, but it will take some time.<br />
:[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 13:14, 16 February 2016 (UTC)<br />
: It does indeed seem like that was no CI issue. Audio over hdmi is not supported by amdgpu atm, respectively only with the (upcoming) DAL changes[http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/853189-audio-over-hdmi-tonga-and-amdgpu], although it is listed as 'done' [http://xorg.freedesktop.org/wiki/RadeonFeature/ here]. [[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 15:59, 22 February 2016 (UTC)<br />
<br />
== Sea Islands cards not working with 4.5.x? ==<br />
I stumbled across this wiki page in hopes of getting more performance after seeing Michael from Phoronix get his 290 working with this. Following through all the instructions, menuconfiging and compiling new kernels, in the end all I get is a blank screen with my r9 390. No errors on Xorg.0.log. Can anyone confirm that it isn't just me?<br />
[[User:Katorisenko|Katorisenko]] ([[User talk:Katorisenko|talk]]) 07:46, 24 April 2016 (UTC)<br />
<br />
== AMDGPU and HDMI Audio ==<br />
<br />
According to [https://bugzilla.freedesktop.org/show_bug.cgi?id=92827#c2 this Freedesktop.org bug comment], HDMI audio support in AMDGPU requires DAL which is "not upstream yet", and won't be anytime soon according to [http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-DRM-No this Phoronix article]. I'm currently struggling to make my HDMI audio work with my AMD Radeon R9 380; if this happens to be impossible with AMDGPU, should we mention it in the "Troubleshooting" section of this page? --[[User:Hellpe|Hellpe]] ([[User talk:Hellpe|talk]]) 23:26, 3 January 2017 (UTC)<br />
<br />
:I am in favor of adding the information notice to the troubleshooting section. I think users who do not keep up with the news will be confused when Pulseaudio seems to add the HDMI audio devices, despite them being non-functional until the DAL code is refactored and accepted upstream then pushed to regular users. I know it was not immediately clear to me when I upgraded from my radeonsi card to an RX series amdgpu card until I did some reading. I "think" currently the only way to get HDMI audio is to use the AMDGPU-PRO driver for the time being. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 15:48, 4 January 2017 (UTC)<br />
<br />
::I have it working with an R9 380 under Xorg. I did nothing special, simply disabled the built-in audio and enabled the HDMI audio. It does not work under Wayland however. Pavucontrol shows unavailable. [[User:Unit73e|Unit73e]] ([[User talk:Unit73e|talk]]) 12:22, 2 December 2017 (UTC)<br />
<br />
== Some experiments with integrated AMD graphics ==<br />
<br />
Some results after playing with "radeon" and "amdgpu" drivers and gnome (for AMD A10 7850K):<br />
<br />
- Having both drivers loaded causes systemd to hang at system shutdown (xorg). Using amdgpu and blacklisting radeon or using radeon and blacklisting amdgpu both fix this problem.<br />
<br />
- Having amdgpu driver without mkinitcpio.conf entry causes<br />
1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11"<br />
2. HDMI sound output is shown only in rare cases<br />
<br />
- Having amdgpu driver with mkinitcpio.conf entry causes<br />
1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland"<br />
2. HDMI sound is always disabled<br />
<br />
- Having radeon driver without mkinitcpio.conf entry causes<br />
1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11"<br />
2. HDMI sound is always correctly detected and working<br />
<br />
- Having radeon driver with mkinitcpio.conf entry<br />
1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland"<br />
2. HDMI sound is always correctly detected and working<br />
<br />
[[User:Beoldhin|Beoldhin]] ([[User talk:Beoldhin|talk]]) 19:07, 23 May 2017 (UTC)<br />
<br />
Update: with kernel 4.11.2-1: HDMI sound output is now working with "amdgpu" but only in as "Gnome in xorg" login option (still no sound with Wayland). There are still some graphical glitches when running Wayland with the radeon driver: external screen doesn't turn off after timeout, windows can't be maximized with the "wmctrl" command and updating text in terminal causes some text updating problems (these don't exist with xorg, amdgpu and radeon both work fine). So in summary: I can now select either amdgpu or radeon driver but Wayland is still unstable.<br />
<br />
[[User:Beoldhin|Beoldhin]] ([[User talk:Beoldhin|talk]]) 19:07, 23 May 2017 (UTC)<br />
<br />
== Vega Changes for Wiki ==<br />
<br />
With Vega releasing around the end of the month, the DC/DAL is still not it the kernel. Should we just put a note for users to use the AMDGPU-PRO drivers if they have VEGA cards? We could possibly add a note saying that in the AUR, there is an alternate kernel built from their repos with the DC/DAL code. <br />
Alternate kernel--> https://aur.archlinux.org/packages/linux-amd-staging-git/ [[User:Sesese9|Sesese9]] ([[User talk:Sesese9|talk]]) 00:40, 10 July 2017 (UTC)<br />
<br />
== Moving "Enable GPU display scaling" to xrandr ==<br />
<br />
I thought about it to put this under xrandr directly, but for example for my integrated Intel 6th gen GPU I don't have the "scaling mode" option, and I don't know about NVIDIA.<br />
And even if the "scaling mode" option exists for other vendors and or cards, I don't know if the possible values for "scaling mode" are the same everywhere, as far as I remember there are not.<br />
That was the reason I did put it here. [[User:Bertl|Bertl]] ([[User talk:Bertl|talk]]) 16:01, 18 February 2018 (UTC)<br />
:Ok, looks like [[Intel_graphics#Setting_scaling_mode|Intel]] uses the same settings, but it's only available for internal (LVDS, eDP) ports, but at least according to https://bugs.freedesktop.org/show_bug.cgi?id=90989 it also uses "None, Full, Center, Full aspect".<br />
:I know that radeonsi uses the same commands, but still don't know about NVIDIA.<br />
:But yea, now I also think that it should be moved and the [[Intel_graphics#Setting_scaling_mode|Intel]] section should be merged into it. [[User:Bertl|Bertl]] ([[User talk:Bertl|talk]]) 18:37, 18 February 2018 (UTC)<br />
<br />
== Update on kernel parameters ==<br />
<br />
this part does not seems to be required on 4.17:<br />
<br />
>> Also, since kernel 4.13, adding the amdgpu.si_support=1 radeon.si_support=0 or amdgpu.cik_support=1 radeon.cik_support=0 kernel parameter is required. Otherwise, AMDGPU will not start and you will end up with either radeon being used instead or the display being frozen during the boot.<br />
<br />
{{unsigned|12:10, 22 April 2018|Lesto}}<br />
<br />
== Renaming AMDGPU-PRO to Radeon Software for Linux? ==<br />
<br />
So AMD basically changed the name of their AMDGPU-PRO driver as simply Radeon™ Software for Linux, see [https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx 17.40], [https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-for-Linux-Release-Notes.aspx 18.10] and [https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-for-Linux-18.20-Early-Preview-Release-Notes.aspx 18.20 preview] release notes. With that in mind, should the names on wiki be slowly changed, or the alternative name/note being added somewhere? I'm not sure if AMDGPU-PRO is still used by AMD officially and whether AMDGPU (without PRO) term is being used as well, but the name sure definitely stuck among community – any ideas? [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 17:33, 11 May 2018 (UTC)<br />
<br />
EDIT: Probably worth noticing is the similar situation happened between [[Fglrx]] and [[AMD Catalyst]] naming back then. [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 17:38, 11 May 2018 (UTC)<br />
<br />
== Vulkan support for FreeSync on Mesa 19.1 ==<br />
<br />
Mesa 19.1 recently came out and it supposedly has FreeSync support for Vulkan. I can't test it right now but I was running the freesync patch before 19.1 and it worked for me. Anyone can confirm it is working on 19.1 and edit the FreeSync part about "only OpenGL is supported"<br />
<br />
[[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 08:56, 5 July 2019 (UTC)<br />
<br />
== Move Variable Refresh Rate to New Page ==<br />
<br />
NVIDIA has supported freesync for a while now as well as having their own variable refresh rate technology (Gsync). I think it would make more sense to make a separate page for it.<br />
[[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 17:00, 2 August 2019 (UTC)<br />
<br />
:I have started writing the article on my [[User:Cknight70#Variable_refresh_rate|personal page]]. Please feel free to make edits, I will create the new page in a couple of days if there are no objections. [[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 18:58, 3 August 2019 (UTC)<br />
<br />
::Check out [[Variable Refresh Rate]] [[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 15:49, 9 August 2019 (UTC)<br />
<br />
== OpenCL implementation? ==<br />
<br />
I've just spent the past day finding out how to get OpenCL to work with AMDGPU and I just found the answer on the [[Blender]] page by using {{AUR|opencl-amd}}. I don't really know if it would fit in with the page (as I could of solved this much sooner by searching up OpenCL and just looking at [[GPGPU]]) but I was still confused by people saying that only AMDGPU-PRO has OpenCL 2 support, so if it was mentioned somehow on the page I think it would be very helpful.<br />
[[User:Polygonerror|Polygonerror]] ([[User talk:Polygonerror|talk]]) 15:45, 20 December 2019 (UTC)<br />
<br />
== Navi power consumption addition: Idle power consumption & memory clocks with Navi 10 and multiple monitors ==<br />
<br />
Using a Gigabyte 5700 XT Gaming OC and 2 Monitors (LG OLED 55" and Dell 25") connected, the GPU won't throttle down and uses around 30W in idle.<br />
Xorg.conf and xrandr etc. don't help.<br />
A workaround is to suspend and resume, using the following as an systemd user job.<br />
<br />
.config/systemd/user/xrandr.service<br />
[Unit]<br />
Description=xrandr<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=oneshot<br />
Environment=DISPLAY=:0<br />
ExecStart=/usr/bin/xrandr -s 2560x1440 --dpi 117 --output DisplayPort-2 --mode 2560x1440 --primary --output HDMI-A-0 --same-as DisplayPort-2 --scale-from 2560x1440 --mode 1920x1080 --rate 60 --dpi 96<br />
ExecStart=/usr/bin/xrandr --output HDMI-A-0 --off<br />
<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
<br />
Change ports and resolutions and enable with<br />
<br />
systemctl --user enable xrandr<br />
<br />
Setting --rate of the LG OLED to 120 will not reduce power consumption as much, because the GPU needs to clock the memory higher.<br />
<br />
Everything works as expected after resuming. Power1 from amdgpu is around 9-10W in idle.<br />
<br />
Is there anything official to fix this that I didn't find?<br />
<br />
The problem is still present in 5.5.15-1-ck and 5.6rc7-1.<br />
<br />
Is it OK to include this in the troubleshooting section ?<br />
<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]]) 11:29, 7 April 2020 (UTC)</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:AMDGPU&diff=604316Talk:AMDGPU2020-04-06T17:38:31Z<p>Strikemybread: /* Navi power consumption addition: Idle power consumption & memory clocks with Navi 10 and multiple monitors */ Added idle consumption after resuming.</p>
<hr />
<div>== Supported Hardware ==<br />
I just crawled the product names "Radeon xyz" of VI/CI GPUs together and was going to go on for professional products "FirePro xzy", too.<br />
<br />
Afaik, there is no such complete listing on the web. There is a lot of confusion about the code and product names, due to AMD repeatedly rebranding their products and even change code names for same GPUs (Tonga = Antigua, Hawaii = Grenada, Carrizo = Bristol Ridge?, ...)<br />
<br />
When I started using gnu/linux, the arch wiki was a great help and there are still a lot of people struggling with graphics drivers. Now I know it is not hard to understand, but it is still confusing for beginners, coming from windows and just being used to install one software suite (not a drm driver, libdrm, mesa, gallium, etc.), supporting all the current hardware.<br />
<br />
now everyone has to go through all of this every time to determine 1) which hardware is really in their product and 2) which driver suits their hardware<br />
<br />
<br />
tl;dr I think maintaining such a list would be really useful for beginners, maybe not here but in a separate article?<br />
[[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 09:27, 16 February 2016 (UTC)<br />
<br />
:Well, [https://wiki.gentoo.org/wiki/Amdgpu#Feature_support Gentoo wiki] has a simple two-line summary. If it's still not sufficiently clear or the list is already much larger, I guess we could have a separate subpage to not clutter the main page... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:20, 16 February 2016 (UTC)<br />
<br />
:: yes, in the meantime I also found this table. It looks good but it is not complete. And completing the list would blow up the table cells a lot. I guess we should wait until vulkan and the new OpenCL driver has been released. Until then, there is no real reason for owners of pre-VI hardware to switch over to amdgpu. All vi and post-vi will be covered, so there is no need to list those separately. For the others I could create a subpage when switching to amdgpu gives you the opportunity for opencl 2.1 and vulkan -- [[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 10:50, 16 February 2016 (UTC)<br />
<br />
== Enable amdgpu for Sea Islands Cards ==<br />
testing my Hawaii card w/ amdgpu last week, sound did not work, even though 6 pcm/hdmi audio devices were listed. Might be added as an issue (as I think this is important deciding between radeon and amdgpu), but needs further investigation/confirmation from other testers.<br />
[[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 09:53, 16 February 2016 (UTC)<br />
:Please remember the AMDGPU is still in beta, and there's still info and knowledge/experience missing (e.g. most users use the Radeon driver).<br />
:AMD isn't that great in providing info and so far a lot of users are confused about their hardware support in use with amdgpu.<br />
:Remember there are flags like {{ic|exp_hw_support}}. More info need to be added, but it will take some time.<br />
:[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 13:14, 16 February 2016 (UTC)<br />
: It does indeed seem like that was no CI issue. Audio over hdmi is not supported by amdgpu atm, respectively only with the (upcoming) DAL changes[http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/853189-audio-over-hdmi-tonga-and-amdgpu], although it is listed as 'done' [http://xorg.freedesktop.org/wiki/RadeonFeature/ here]. [[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 15:59, 22 February 2016 (UTC)<br />
<br />
== Sea Islands cards not working with 4.5.x? ==<br />
I stumbled across this wiki page in hopes of getting more performance after seeing Michael from Phoronix get his 290 working with this. Following through all the instructions, menuconfiging and compiling new kernels, in the end all I get is a blank screen with my r9 390. No errors on Xorg.0.log. Can anyone confirm that it isn't just me?<br />
[[User:Katorisenko|Katorisenko]] ([[User talk:Katorisenko|talk]]) 07:46, 24 April 2016 (UTC)<br />
<br />
== AMDGPU and HDMI Audio ==<br />
<br />
According to [https://bugzilla.freedesktop.org/show_bug.cgi?id=92827#c2 this Freedesktop.org bug comment], HDMI audio support in AMDGPU requires DAL which is "not upstream yet", and won't be anytime soon according to [http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-DRM-No this Phoronix article]. I'm currently struggling to make my HDMI audio work with my AMD Radeon R9 380; if this happens to be impossible with AMDGPU, should we mention it in the "Troubleshooting" section of this page? --[[User:Hellpe|Hellpe]] ([[User talk:Hellpe|talk]]) 23:26, 3 January 2017 (UTC)<br />
<br />
:I am in favor of adding the information notice to the troubleshooting section. I think users who do not keep up with the news will be confused when Pulseaudio seems to add the HDMI audio devices, despite them being non-functional until the DAL code is refactored and accepted upstream then pushed to regular users. I know it was not immediately clear to me when I upgraded from my radeonsi card to an RX series amdgpu card until I did some reading. I "think" currently the only way to get HDMI audio is to use the AMDGPU-PRO driver for the time being. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 15:48, 4 January 2017 (UTC)<br />
<br />
::I have it working with an R9 380 under Xorg. I did nothing special, simply disabled the built-in audio and enabled the HDMI audio. It does not work under Wayland however. Pavucontrol shows unavailable. [[User:Unit73e|Unit73e]] ([[User talk:Unit73e|talk]]) 12:22, 2 December 2017 (UTC)<br />
<br />
== Some experiments with integrated AMD graphics ==<br />
<br />
Some results after playing with "radeon" and "amdgpu" drivers and gnome (for AMD A10 7850K):<br />
<br />
- Having both drivers loaded causes systemd to hang at system shutdown (xorg). Using amdgpu and blacklisting radeon or using radeon and blacklisting amdgpu both fix this problem.<br />
<br />
- Having amdgpu driver without mkinitcpio.conf entry causes<br />
1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11"<br />
2. HDMI sound output is shown only in rare cases<br />
<br />
- Having amdgpu driver with mkinitcpio.conf entry causes<br />
1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland"<br />
2. HDMI sound is always disabled<br />
<br />
- Having radeon driver without mkinitcpio.conf entry causes<br />
1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11"<br />
2. HDMI sound is always correctly detected and working<br />
<br />
- Having radeon driver with mkinitcpio.conf entry<br />
1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland"<br />
2. HDMI sound is always correctly detected and working<br />
<br />
[[User:Beoldhin|Beoldhin]] ([[User talk:Beoldhin|talk]]) 19:07, 23 May 2017 (UTC)<br />
<br />
Update: with kernel 4.11.2-1: HDMI sound output is now working with "amdgpu" but only in as "Gnome in xorg" login option (still no sound with Wayland). There are still some graphical glitches when running Wayland with the radeon driver: external screen doesn't turn off after timeout, windows can't be maximized with the "wmctrl" command and updating text in terminal causes some text updating problems (these don't exist with xorg, amdgpu and radeon both work fine). So in summary: I can now select either amdgpu or radeon driver but Wayland is still unstable.<br />
<br />
[[User:Beoldhin|Beoldhin]] ([[User talk:Beoldhin|talk]]) 19:07, 23 May 2017 (UTC)<br />
<br />
== Vega Changes for Wiki ==<br />
<br />
With Vega releasing around the end of the month, the DC/DAL is still not it the kernel. Should we just put a note for users to use the AMDGPU-PRO drivers if they have VEGA cards? We could possibly add a note saying that in the AUR, there is an alternate kernel built from their repos with the DC/DAL code. <br />
Alternate kernel--> https://aur.archlinux.org/packages/linux-amd-staging-git/ [[User:Sesese9|Sesese9]] ([[User talk:Sesese9|talk]]) 00:40, 10 July 2017 (UTC)<br />
<br />
== Moving "Enable GPU display scaling" to xrandr ==<br />
<br />
I thought about it to put this under xrandr directly, but for example for my integrated Intel 6th gen GPU I don't have the "scaling mode" option, and I don't know about NVIDIA.<br />
And even if the "scaling mode" option exists for other vendors and or cards, I don't know if the possible values for "scaling mode" are the same everywhere, as far as I remember there are not.<br />
That was the reason I did put it here. [[User:Bertl|Bertl]] ([[User talk:Bertl|talk]]) 16:01, 18 February 2018 (UTC)<br />
:Ok, looks like [[Intel_graphics#Setting_scaling_mode|Intel]] uses the same settings, but it's only available for internal (LVDS, eDP) ports, but at least according to https://bugs.freedesktop.org/show_bug.cgi?id=90989 it also uses "None, Full, Center, Full aspect".<br />
:I know that radeonsi uses the same commands, but still don't know about NVIDIA.<br />
:But yea, now I also think that it should be moved and the [[Intel_graphics#Setting_scaling_mode|Intel]] section should be merged into it. [[User:Bertl|Bertl]] ([[User talk:Bertl|talk]]) 18:37, 18 February 2018 (UTC)<br />
<br />
== Update on kernel parameters ==<br />
<br />
this part does not seems to be required on 4.17:<br />
<br />
>> Also, since kernel 4.13, adding the amdgpu.si_support=1 radeon.si_support=0 or amdgpu.cik_support=1 radeon.cik_support=0 kernel parameter is required. Otherwise, AMDGPU will not start and you will end up with either radeon being used instead or the display being frozen during the boot.<br />
<br />
{{unsigned|12:10, 22 April 2018|Lesto}}<br />
<br />
== Renaming AMDGPU-PRO to Radeon Software for Linux? ==<br />
<br />
So AMD basically changed the name of their AMDGPU-PRO driver as simply Radeon™ Software for Linux, see [https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx 17.40], [https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-for-Linux-Release-Notes.aspx 18.10] and [https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-for-Linux-18.20-Early-Preview-Release-Notes.aspx 18.20 preview] release notes. With that in mind, should the names on wiki be slowly changed, or the alternative name/note being added somewhere? I'm not sure if AMDGPU-PRO is still used by AMD officially and whether AMDGPU (without PRO) term is being used as well, but the name sure definitely stuck among community – any ideas? [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 17:33, 11 May 2018 (UTC)<br />
<br />
EDIT: Probably worth noticing is the similar situation happened between [[Fglrx]] and [[AMD Catalyst]] naming back then. [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 17:38, 11 May 2018 (UTC)<br />
<br />
== Vulkan support for FreeSync on Mesa 19.1 ==<br />
<br />
Mesa 19.1 recently came out and it supposedly has FreeSync support for Vulkan. I can't test it right now but I was running the freesync patch before 19.1 and it worked for me. Anyone can confirm it is working on 19.1 and edit the FreeSync part about "only OpenGL is supported"<br />
<br />
[[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 08:56, 5 July 2019 (UTC)<br />
<br />
== Move Variable Refresh Rate to New Page ==<br />
<br />
NVIDIA has supported freesync for a while now as well as having their own variable refresh rate technology (Gsync). I think it would make more sense to make a separate page for it.<br />
[[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 17:00, 2 August 2019 (UTC)<br />
<br />
:I have started writing the article on my [[User:Cknight70#Variable_refresh_rate|personal page]]. Please feel free to make edits, I will create the new page in a couple of days if there are no objections. [[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 18:58, 3 August 2019 (UTC)<br />
<br />
::Check out [[Variable Refresh Rate]] [[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 15:49, 9 August 2019 (UTC)<br />
<br />
== OpenCL implementation? ==<br />
<br />
I've just spent the past day finding out how to get OpenCL to work with AMDGPU and I just found the answer on the [[Blender]] page by using {{AUR|opencl-amd}}. I don't really know if it would fit in with the page (as I could of solved this much sooner by searching up OpenCL and just looking at [[GPGPU]]) but I was still confused by people saying that only AMDGPU-PRO has OpenCL 2 support, so if it was mentioned somehow on the page I think it would be very helpful.<br />
[[User:Polygonerror|Polygonerror]] ([[User talk:Polygonerror|talk]]) 15:45, 20 December 2019 (UTC)<br />
<br />
== Navi power consumption addition: Idle power consumption & memory clocks with Navi 10 and multiple monitors ==<br />
<br />
Using a Gigabyte 5700 XT Gaming OC and 2 Monitors (LG OLED 55" and Dell 25") connected, the GPU won't throttle down and uses around 30W in idle.<br />
Xorg.conf and xrandr etc. don't help.<br />
A workaround is to suspend and resume, using the following as an systemd user job.<br />
<br />
.config/systemd/user/xrandr.service<br />
[Unit]<br />
Description=xrandr<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=oneshot<br />
Environment=DISPLAY=:0<br />
ExecStart=/usr/bin/xrandr -s 2560x1440 --dpi 117 --output DisplayPort-2 --mode 2560x1440 --primary --output HDMI-A-0 --same-as DisplayPort-2 --scale-from 2560x1440 --mode 1920x1080 --rate 60 --dpi 96<br />
ExecStart=/usr/bin/xrandr --output HDMI-A-0 --off<br />
<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
<br />
Change ports and resolutions and enable with<br />
<br />
systemctl --user enable xrandr<br />
<br />
Setting --rate of the LG OLED to 120 will not reduce power consumption as much, because the GPU needs to clock the memory higher.<br />
<br />
Everything works as expected after resuming. Power1 from amdgpu is around 9-10W in idle.<br />
<br />
Is there anything official to fix this that I didn't find?<br />
<br />
The problem is still present in 5.5.15-1-ck and 5.6rc7-1.<br />
<br />
Is it OK to include this in the troubleshooting section ?</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:AMDGPU&diff=604315Talk:AMDGPU2020-04-06T17:33:29Z<p>Strikemybread: /* Navi power consumption addition: Idle power consumption & memory clocks with Navi 10 and multiple monitors */ new section</p>
<hr />
<div>== Supported Hardware ==<br />
I just crawled the product names "Radeon xyz" of VI/CI GPUs together and was going to go on for professional products "FirePro xzy", too.<br />
<br />
Afaik, there is no such complete listing on the web. There is a lot of confusion about the code and product names, due to AMD repeatedly rebranding their products and even change code names for same GPUs (Tonga = Antigua, Hawaii = Grenada, Carrizo = Bristol Ridge?, ...)<br />
<br />
When I started using gnu/linux, the arch wiki was a great help and there are still a lot of people struggling with graphics drivers. Now I know it is not hard to understand, but it is still confusing for beginners, coming from windows and just being used to install one software suite (not a drm driver, libdrm, mesa, gallium, etc.), supporting all the current hardware.<br />
<br />
now everyone has to go through all of this every time to determine 1) which hardware is really in their product and 2) which driver suits their hardware<br />
<br />
<br />
tl;dr I think maintaining such a list would be really useful for beginners, maybe not here but in a separate article?<br />
[[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 09:27, 16 February 2016 (UTC)<br />
<br />
:Well, [https://wiki.gentoo.org/wiki/Amdgpu#Feature_support Gentoo wiki] has a simple two-line summary. If it's still not sufficiently clear or the list is already much larger, I guess we could have a separate subpage to not clutter the main page... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:20, 16 February 2016 (UTC)<br />
<br />
:: yes, in the meantime I also found this table. It looks good but it is not complete. And completing the list would blow up the table cells a lot. I guess we should wait until vulkan and the new OpenCL driver has been released. Until then, there is no real reason for owners of pre-VI hardware to switch over to amdgpu. All vi and post-vi will be covered, so there is no need to list those separately. For the others I could create a subpage when switching to amdgpu gives you the opportunity for opencl 2.1 and vulkan -- [[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 10:50, 16 February 2016 (UTC)<br />
<br />
== Enable amdgpu for Sea Islands Cards ==<br />
testing my Hawaii card w/ amdgpu last week, sound did not work, even though 6 pcm/hdmi audio devices were listed. Might be added as an issue (as I think this is important deciding between radeon and amdgpu), but needs further investigation/confirmation from other testers.<br />
[[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 09:53, 16 February 2016 (UTC)<br />
:Please remember the AMDGPU is still in beta, and there's still info and knowledge/experience missing (e.g. most users use the Radeon driver).<br />
:AMD isn't that great in providing info and so far a lot of users are confused about their hardware support in use with amdgpu.<br />
:Remember there are flags like {{ic|exp_hw_support}}. More info need to be added, but it will take some time.<br />
:[[User:Francoism|Francoism]] ([[User talk:Francoism|talk]]) 13:14, 16 February 2016 (UTC)<br />
: It does indeed seem like that was no CI issue. Audio over hdmi is not supported by amdgpu atm, respectively only with the (upcoming) DAL changes[http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/853189-audio-over-hdmi-tonga-and-amdgpu], although it is listed as 'done' [http://xorg.freedesktop.org/wiki/RadeonFeature/ here]. [[User:Iuno|Iuno]] ([[User talk:Iuno|talk]]) 15:59, 22 February 2016 (UTC)<br />
<br />
== Sea Islands cards not working with 4.5.x? ==<br />
I stumbled across this wiki page in hopes of getting more performance after seeing Michael from Phoronix get his 290 working with this. Following through all the instructions, menuconfiging and compiling new kernels, in the end all I get is a blank screen with my r9 390. No errors on Xorg.0.log. Can anyone confirm that it isn't just me?<br />
[[User:Katorisenko|Katorisenko]] ([[User talk:Katorisenko|talk]]) 07:46, 24 April 2016 (UTC)<br />
<br />
== AMDGPU and HDMI Audio ==<br />
<br />
According to [https://bugzilla.freedesktop.org/show_bug.cgi?id=92827#c2 this Freedesktop.org bug comment], HDMI audio support in AMDGPU requires DAL which is "not upstream yet", and won't be anytime soon according to [http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-DC-DRM-No this Phoronix article]. I'm currently struggling to make my HDMI audio work with my AMD Radeon R9 380; if this happens to be impossible with AMDGPU, should we mention it in the "Troubleshooting" section of this page? --[[User:Hellpe|Hellpe]] ([[User talk:Hellpe|talk]]) 23:26, 3 January 2017 (UTC)<br />
<br />
:I am in favor of adding the information notice to the troubleshooting section. I think users who do not keep up with the news will be confused when Pulseaudio seems to add the HDMI audio devices, despite them being non-functional until the DAL code is refactored and accepted upstream then pushed to regular users. I know it was not immediately clear to me when I upgraded from my radeonsi card to an RX series amdgpu card until I did some reading. I "think" currently the only way to get HDMI audio is to use the AMDGPU-PRO driver for the time being. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 15:48, 4 January 2017 (UTC)<br />
<br />
::I have it working with an R9 380 under Xorg. I did nothing special, simply disabled the built-in audio and enabled the HDMI audio. It does not work under Wayland however. Pavucontrol shows unavailable. [[User:Unit73e|Unit73e]] ([[User talk:Unit73e|talk]]) 12:22, 2 December 2017 (UTC)<br />
<br />
== Some experiments with integrated AMD graphics ==<br />
<br />
Some results after playing with "radeon" and "amdgpu" drivers and gnome (for AMD A10 7850K):<br />
<br />
- Having both drivers loaded causes systemd to hang at system shutdown (xorg). Using amdgpu and blacklisting radeon or using radeon and blacklisting amdgpu both fix this problem.<br />
<br />
- Having amdgpu driver without mkinitcpio.conf entry causes<br />
1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11"<br />
2. HDMI sound output is shown only in rare cases<br />
<br />
- Having amdgpu driver with mkinitcpio.conf entry causes<br />
1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland"<br />
2. HDMI sound is always disabled<br />
<br />
- Having radeon driver without mkinitcpio.conf entry causes<br />
1. Wayland can't be enabled (always in xorg mode) and XDG_SESSION_TYPE shows "x11"<br />
2. HDMI sound is always correctly detected and working<br />
<br />
- Having radeon driver with mkinitcpio.conf entry<br />
1. Wayland is enabled by default and XDG_SESSION_TYPE shows "wayland"<br />
2. HDMI sound is always correctly detected and working<br />
<br />
[[User:Beoldhin|Beoldhin]] ([[User talk:Beoldhin|talk]]) 19:07, 23 May 2017 (UTC)<br />
<br />
Update: with kernel 4.11.2-1: HDMI sound output is now working with "amdgpu" but only in as "Gnome in xorg" login option (still no sound with Wayland). There are still some graphical glitches when running Wayland with the radeon driver: external screen doesn't turn off after timeout, windows can't be maximized with the "wmctrl" command and updating text in terminal causes some text updating problems (these don't exist with xorg, amdgpu and radeon both work fine). So in summary: I can now select either amdgpu or radeon driver but Wayland is still unstable.<br />
<br />
[[User:Beoldhin|Beoldhin]] ([[User talk:Beoldhin|talk]]) 19:07, 23 May 2017 (UTC)<br />
<br />
== Vega Changes for Wiki ==<br />
<br />
With Vega releasing around the end of the month, the DC/DAL is still not it the kernel. Should we just put a note for users to use the AMDGPU-PRO drivers if they have VEGA cards? We could possibly add a note saying that in the AUR, there is an alternate kernel built from their repos with the DC/DAL code. <br />
Alternate kernel--> https://aur.archlinux.org/packages/linux-amd-staging-git/ [[User:Sesese9|Sesese9]] ([[User talk:Sesese9|talk]]) 00:40, 10 July 2017 (UTC)<br />
<br />
== Moving "Enable GPU display scaling" to xrandr ==<br />
<br />
I thought about it to put this under xrandr directly, but for example for my integrated Intel 6th gen GPU I don't have the "scaling mode" option, and I don't know about NVIDIA.<br />
And even if the "scaling mode" option exists for other vendors and or cards, I don't know if the possible values for "scaling mode" are the same everywhere, as far as I remember there are not.<br />
That was the reason I did put it here. [[User:Bertl|Bertl]] ([[User talk:Bertl|talk]]) 16:01, 18 February 2018 (UTC)<br />
:Ok, looks like [[Intel_graphics#Setting_scaling_mode|Intel]] uses the same settings, but it's only available for internal (LVDS, eDP) ports, but at least according to https://bugs.freedesktop.org/show_bug.cgi?id=90989 it also uses "None, Full, Center, Full aspect".<br />
:I know that radeonsi uses the same commands, but still don't know about NVIDIA.<br />
:But yea, now I also think that it should be moved and the [[Intel_graphics#Setting_scaling_mode|Intel]] section should be merged into it. [[User:Bertl|Bertl]] ([[User talk:Bertl|talk]]) 18:37, 18 February 2018 (UTC)<br />
<br />
== Update on kernel parameters ==<br />
<br />
this part does not seems to be required on 4.17:<br />
<br />
>> Also, since kernel 4.13, adding the amdgpu.si_support=1 radeon.si_support=0 or amdgpu.cik_support=1 radeon.cik_support=0 kernel parameter is required. Otherwise, AMDGPU will not start and you will end up with either radeon being used instead or the display being frozen during the boot.<br />
<br />
{{unsigned|12:10, 22 April 2018|Lesto}}<br />
<br />
== Renaming AMDGPU-PRO to Radeon Software for Linux? ==<br />
<br />
So AMD basically changed the name of their AMDGPU-PRO driver as simply Radeon™ Software for Linux, see [https://support.amd.com/en-us/kb-articles/Pages/AMDGPU-PRO-Driver-for-Linux-Release-Notes.aspx 17.40], [https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-for-Linux-Release-Notes.aspx 18.10] and [https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-for-Linux-18.20-Early-Preview-Release-Notes.aspx 18.20 preview] release notes. With that in mind, should the names on wiki be slowly changed, or the alternative name/note being added somewhere? I'm not sure if AMDGPU-PRO is still used by AMD officially and whether AMDGPU (without PRO) term is being used as well, but the name sure definitely stuck among community – any ideas? [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 17:33, 11 May 2018 (UTC)<br />
<br />
EDIT: Probably worth noticing is the similar situation happened between [[Fglrx]] and [[AMD Catalyst]] naming back then. [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 17:38, 11 May 2018 (UTC)<br />
<br />
== Vulkan support for FreeSync on Mesa 19.1 ==<br />
<br />
Mesa 19.1 recently came out and it supposedly has FreeSync support for Vulkan. I can't test it right now but I was running the freesync patch before 19.1 and it worked for me. Anyone can confirm it is working on 19.1 and edit the FreeSync part about "only OpenGL is supported"<br />
<br />
[[User:Igo95862|Igo95862]] ([[User talk:Igo95862|talk]]) 08:56, 5 July 2019 (UTC)<br />
<br />
== Move Variable Refresh Rate to New Page ==<br />
<br />
NVIDIA has supported freesync for a while now as well as having their own variable refresh rate technology (Gsync). I think it would make more sense to make a separate page for it.<br />
[[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 17:00, 2 August 2019 (UTC)<br />
<br />
:I have started writing the article on my [[User:Cknight70#Variable_refresh_rate|personal page]]. Please feel free to make edits, I will create the new page in a couple of days if there are no objections. [[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 18:58, 3 August 2019 (UTC)<br />
<br />
::Check out [[Variable Refresh Rate]] [[User:Cknight70|Cknight70]] ([[User talk:Cknight70|talk]]) 15:49, 9 August 2019 (UTC)<br />
<br />
== OpenCL implementation? ==<br />
<br />
I've just spent the past day finding out how to get OpenCL to work with AMDGPU and I just found the answer on the [[Blender]] page by using {{AUR|opencl-amd}}. I don't really know if it would fit in with the page (as I could of solved this much sooner by searching up OpenCL and just looking at [[GPGPU]]) but I was still confused by people saying that only AMDGPU-PRO has OpenCL 2 support, so if it was mentioned somehow on the page I think it would be very helpful.<br />
[[User:Polygonerror|Polygonerror]] ([[User talk:Polygonerror|talk]]) 15:45, 20 December 2019 (UTC)<br />
<br />
== Navi power consumption addition: Idle power consumption & memory clocks with Navi 10 and multiple monitors ==<br />
<br />
Using a Gigabyte 5700 XT Gaming OC and 2 Monitors (LG OLED 55" and Dell 25") connected, the GPU won't throttle down and uses around 30W in idle.<br />
Xorg.conf and xrandr etc. don't help.<br />
A workaround is to suspend and resume, using the following as an systemd user job.<br />
<br />
.config/systemd/user/xrandr.service<br />
[Unit]<br />
Description=xrandr<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=oneshot<br />
Environment=DISPLAY=:0<br />
ExecStart=/usr/bin/xrandr -s 2560x1440 --dpi 117 --output DisplayPort-2 --mode 2560x1440 --primary --output HDMI-A-0 --same-as DisplayPort-2 --scale-from 2560x1440 --mode 1920x1080 --rate 60 --dpi 96<br />
ExecStart=/usr/bin/xrandr --output HDMI-A-0 --off<br />
<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
<br />
Change ports and resolutions and enable with<br />
<br />
systemctl --user enable xrandr<br />
<br />
Setting --rate of the LG OLED to 120 will not reduce power consumption as much, because the GPU needs to clock the memory higher.<br />
<br />
Everything works as expected after resuming<br />
<br />
Is there anything official to fix this that I didn't find?<br />
<br />
The problem is still present in 5.5.15-1-ck and 5.6rc7-1.<br />
<br />
Is it OK to include this in the troubleshooting section ?</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:NVIDIA/Tips_and_tricks&diff=485355Talk:NVIDIA/Tips and tricks2017-08-14T10:07:56Z<p>Strikemybread: additions after further investigation</p>
<hr />
<div>== Set fan speed at login ==<br />
<br />
Shouldn't this section be changed to use GPUTargetFanSpeed instead of GPUCurrentFanSpeed as this is the current working method? The note that is currently present explaining the change is very easy to miss.<br />
<br />
{{unsigned|17:59, 14 July 2017|Manypopes}}<br />
<br />
== Allow change to highest Performance Mode ==<br />
<br />
Any other way of "overclocking" won't change the Memory Transfer Rate offset (it has no effect in nvidia-settings).<br />
<br />
see https://devtalk.nvidia.com/default/topic/1010856/linux/how-to-force-performance-level-3-driver-381-22-with-gtx-1080-ti-/ and https://devtalk.nvidia.com/default/topic/977467/cuda-setup-and-installation/having-trouble-overclocking-gtx-1070/ and also https://devtalk.nvidia.com/default/topic/1014710/linux/understanding-weirdness-with-gpumemorytransferrateoffset-/<br />
<br />
Setting the clockspeed rates in nvidia-settings without prior adjusting the rates in nvidia-smi crashes really hard, because it tries to overclock max. performance mode which only is active when the card is idle (i.e. just after exiting a game or a miner...).<br />
<br />
default clock speed + overclocking = max. default clock speed or crash<br />
<br />
"set" clock speed + overclocking = more than max. default clock speed and memory transfer rate tunable<br />
<br />
<br />
This is a bug.<br />
<br />
<br />
Pointing out the fact that this is not my website, why did you delete the Watt-Limiting Section?<br />
(My) GTX 960 is not kepler, changing wattage works though? Man pages lie!<br />
<br />
<br />
<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]]) 12:06, 14 August 2017 (UTC)</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:NVIDIA/Tips_and_tricks&diff=485337Talk:NVIDIA/Tips and tricks2017-08-14T08:39:46Z<p>Strikemybread: mixed up nvidia-settings and nvidia-smi</p>
<hr />
<div>== Set fan speed at login ==<br />
<br />
Shouldn't this section be changed to use GPUTargetFanSpeed instead of GPUCurrentFanSpeed as this is the current working method? The note that is currently present explaining the change is very easy to miss.<br />
<br />
{{unsigned|17:59, 14 July 2017|Manypopes}}<br />
<br />
== Allow change to highest Performance Mode ==<br />
<br />
Any other way of "overclocking" won't change the Memory Transfer Rate offset (it has no effect in nvidia-settings).<br />
<br />
see https://devtalk.nvidia.com/default/topic/1010856/linux/how-to-force-performance-level-3-driver-381-22-with-gtx-1080-ti-/ and https://devtalk.nvidia.com/default/topic/977467/cuda-setup-and-installation/having-trouble-overclocking-gtx-1070/ and also https://devtalk.nvidia.com/default/topic/1014710/linux/understanding-weirdness-with-gpumemorytransferrateoffset-/<br />
<br />
Setting the clockspeed rates in nvidia-settings without prior adjusting the rates in nvidia-smi crashes really hard, because it tries to overclock max. performance mode which only is active when the card is idle (i.e. just after exiting a game or a miner...).<br />
<br />
default clock speed + overclocking = max. default clock speed or crash<br />
<br />
"set" clock speed + overclocking = more than max. default clock speed and memory transfer rate tunable<br />
<br />
<br />
This is a bug.<br />
<br />
<br />
Pointing out the fact that this is not my website so friendly, why did you delete the Watt-Limiting Section?<br />
<br />
<br />
<br />
<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]]) 08:20, 14 August 2017 (UTC)</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:NVIDIA/Tips_and_tricks&diff=485336Talk:NVIDIA/Tips and tricks2017-08-14T08:26:10Z<p>Strikemybread: small addition</p>
<hr />
<div>== Set fan speed at login ==<br />
<br />
Shouldn't this section be changed to use GPUTargetFanSpeed instead of GPUCurrentFanSpeed as this is the current working method? The note that is currently present explaining the change is very easy to miss.<br />
<br />
{{unsigned|17:59, 14 July 2017|Manypopes}}<br />
<br />
== Allow change to highest Performance Mode ==<br />
<br />
Any other way of "overclocking" won't change the Memory Transfer Rate offset (it has no effect in nvidia-settings).<br />
<br />
see https://devtalk.nvidia.com/default/topic/1010856/linux/how-to-force-performance-level-3-driver-381-22-with-gtx-1080-ti-/ and https://devtalk.nvidia.com/default/topic/977467/cuda-setup-and-installation/having-trouble-overclocking-gtx-1070/ and also https://devtalk.nvidia.com/default/topic/1014710/linux/understanding-weirdness-with-gpumemorytransferrateoffset-/<br />
<br />
Setting the clockspeed rates in nvidia-settings without adjusting the clockrates in nvidia-settings crashes really hard, because it tries to overclock max. performance mode which only is active when the card is idle (i.e. just after exiting a game or a miner...).<br />
<br />
default clock speed + overclocking = default clock speed or crash<br />
<br />
"set" clock speed + overclocking = more than default clock speed and memory transfer rate tunable<br />
<br />
<br />
<br />
<br />
This is a Bug.<br />
<br />
<br />
Pointing out the fact that this is not my website so friendly, why did you delete the Watt-Limiting Section?<br />
<br />
<br />
<br />
<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]]) 08:20, 14 August 2017 (UTC)</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=Talk:NVIDIA/Tips_and_tricks&diff=485333Talk:NVIDIA/Tips and tricks2017-08-14T08:20:04Z<p>Strikemybread: /* Allow change to highest Performance Mode */ new section</p>
<hr />
<div>== Set fan speed at login ==<br />
<br />
Shouldn't this section be changed to use GPUTargetFanSpeed instead of GPUCurrentFanSpeed as this is the current working method? The note that is currently present explaining the change is very easy to miss.<br />
<br />
{{unsigned|17:59, 14 July 2017|Manypopes}}<br />
<br />
== Allow change to highest Performance Mode ==<br />
<br />
Any other way of "overclocking" won't change the Memory Transfer Rate offset (it has no effect in nvidia-settings).<br />
<br />
see https://devtalk.nvidia.com/default/topic/1010856/linux/how-to-force-performance-level-3-driver-381-22-with-gtx-1080-ti-/ and https://devtalk.nvidia.com/default/topic/977467/cuda-setup-and-installation/having-trouble-overclocking-gtx-1070/ and also https://devtalk.nvidia.com/default/topic/1014710/linux/understanding-weirdness-with-gpumemorytransferrateoffset-/<br />
<br />
Setting the clockspeed rates in nvidia-settings without adjusting the clockrates in nvidia-settings crashes really hard, because it tries to overclock max. performance mode which only is active when the card is idle (i.e. just after exiting a game or a miner...).<br />
<br />
This is a Bug.<br />
<br />
<br />
Pointing out the fact that this is not my website so friendly, why did you delete the Watt-Limiting Section?<br />
<br />
<br />
<br />
<br />
[[User:Strikemybread|Strikemybread]] ([[User talk:Strikemybread|talk]]) 08:20, 14 August 2017 (UTC)</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=NVIDIA/Tips_and_tricks&diff=485263NVIDIA/Tips and tricks2017-08-13T13:17:21Z<p>Strikemybread: minor additions</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[ja:NVIDIA/Tips and tricks]]<br />
[[ru:NVIDIA/Tips and tricks]]<br />
== Fixing terminal resolution ==<br />
<br />
Transitioning from nouveau may cause your startup terminal to display at a lower resolution. For GRUB, see [[GRUB/Tips and tricks#Setting the framebuffer resolution]] for details.<br />
<br />
== Using TV-out ==<br />
<br />
A good article on the subject can be found [http://en.wikibooks.org/wiki/NVidia/TV-OUT here].<br />
<br />
== X with a TV (DFP) as the only display ==<br />
<br />
The X server falls back to CRT-0 if no monitor is automatically detected. This can be a problem when using a DVI connected TV as the main display, and X is started while the TV is turned off or otherwise disconnected.<br />
<br />
To force NVIDIA to use DFP, store a copy of the EDID somewhere in the filesystem so that X can parse the file instead of reading EDID from the TV/DFP.<br />
<br />
To acquire the EDID, start nvidia-settings. It will show some information in tree format, ignore the rest of the settings for now and select the GPU (the corresponding entry should be titled "GPU-0" or similar), click the {{ic|DFP}} section (again, {{ic|DFP-0}} or similar), click on the {{ic|Acquire Edid}} Button and store it somewhere, for example, {{ic|/etc/X11/dfp0.edid}}.<br />
<br />
If in the front-end mouse and keyboard are not attached, the EDID can be acquired using only the command line. Run an X server with enough verbosity to print out the EDID block:<br />
$ startx -- -logverbose 6<br />
After the X Server has finished initializing, close it and your log file will probably be in {{ic|/var/log/Xorg.0.log}}. Extract the EDID block using nvidia-xconfig:<br />
$ nvidia-xconfig --extract-edids-from-file=/var/log/Xorg.0.log --extract-edids-output-file=/etc/X11/dfp0.bin<br />
<br />
Edit {{ic|xorg.conf}} by adding to the {{ic|Device}} section:<br />
Option "ConnectedMonitor" "DFP"<br />
Option "CustomEDID" "DFP-0:/etc/X11/dfp0.edid"<br />
The {{ic|ConnectedMonitor}} option forces the driver to recognize the DFP as if it were connected. The {{ic|CustomEDID}} provides EDID data for the device, meaning that it will start up just as if the TV/DFP was connected during X the process.<br />
<br />
This way, one can automatically start a display manager at boot time and still have a working and properly configured X screen by the time the TV gets powered on.<br />
<br />
If the above changes did not work, in the {{ic|xorg.conf}} under {{ic|Device}} section you can try to remove the {{ic|Option "ConnectedMonitor" "DFP"}} and add the following lines:<br />
Option "ModeValidation" "NoDFPNativeResolutionCheck"<br />
Option "ConnectedMonitor" "DFP-0"<br />
<br />
The {{ic|NoDFPNativeResolutionCheck}} prevents NVIDIA driver from disabling all the modes that do not fit in the native resolution.<br />
<br />
== Check the power source ==<br />
<br />
The NVIDIA X.org driver can also be used to detect the GPU's current source of power. To see the current power source, check the 'GPUPowerSource' read-only parameter (0 - AC, 1 - battery):<br />
<br />
{{hc|$ nvidia-settings -q GPUPowerSource -t|1}}<br />
<br />
== Listening to ACPI events ==<br />
<br />
NVIDIA drivers automatically try to connect to the [[acpid]] daemon and listen to ACPI events such as battery power, docking, some hotkeys, etc. If connection fails, X.org will output the following warning:<br />
<br />
{{hc|~/.local/share/xorg/Xorg.0.log|<br />
NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon<br />
NVIDIA(0): may not be running or the "AcpidSocketPath" X<br />
NVIDIA(0): configuration option may not be set correctly. When the<br />
NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will<br />
NVIDIA(0): try to use it to receive ACPI event notifications. For<br />
NVIDIA(0): details, please see the "ConnectToAcpid" and<br />
NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X<br />
NVIDIA(0): Config Options in the README.<br />
}}<br />
<br />
While completely harmless, you may get rid of this message by disabling the {{ic|ConnectToAcpid}} option in your {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}}:<br />
<br />
Section "Device"<br />
...<br />
Driver "nvidia"<br />
Option "ConnectToAcpid" "0"<br />
...<br />
EndSection<br />
<br />
If you are on laptop, it might be a good idea to install and enable the [[acpid]] daemon instead.<br />
<br />
== Displaying GPU temperature in the shell ==<br />
<br />
There are three methods to query the GPU temperature. ''nvidia-settings'' requires that you are using X, ''nvidia-smi'' or ''nvclock'' do not. Also note that ''nvclock'' currently does not work with newer NVIDIA cards such as GeForce 200 series cards as well as embedded GPUs such as the Zotac IONITX's 8800GS.<br />
<br />
=== nvidia-settings ===<br />
<br />
To display the GPU temp in the shell, use ''nvidia-settings'' as follows:<br />
$ nvidia-settings -q gpucoretemp<br />
<br />
This will output something similar to the following:<br />
Attribute 'GPUCoreTemp' (hostname:0.0): 41.<br />
'GPUCoreTemp' is an integer attribute.<br />
'GPUCoreTemp' is a read-only attribute.<br />
'GPUCoreTemp' can use the following target types: X Screen, GPU.<br />
<br />
The GPU temps of this board is 41 C.<br />
<br />
In order to get just the temperature for use in utilities such as ''rrdtool'' or ''conky'':<br />
<br />
{{hc|$ nvidia-settings -q gpucoretemp -t|41}}<br />
<br />
=== nvidia-smi ===<br />
<br />
Use ''nvidia-smi'' which can read temps directly from the GPU without the need to use X at all, e.g. when running Wayland or on a headless server. <br />
To display the GPU temperature in the shell, use ''nvidia-smi'' as follows:<br />
<br />
$ nvidia-smi<br />
<br />
This should output something similar to the following:<br />
<br />
{{hc|$ nvidia-smi|<nowiki><br />
Fri Jan 6 18:53:54 2012 <br />
+------------------------------------------------------+ <br />
| NVIDIA-SMI 2.290.10 Driver Version: 290.10 | <br />
|-------------------------------+----------------------+----------------------+<br />
| Nb. Name | Bus Id Disp. | Volatile ECC SB / DB |<br />
| Fan Temp Power Usage /Cap | Memory Usage | GPU Util. Compute M. |<br />
|===============================+======================+======================|<br />
| 0. GeForce 8500 GT | 0000:01:00.0 N/A | N/A N/A |<br />
| 30% 62 C N/A N/A / N/A | 17% 42MB / 255MB | N/A Default |<br />
|-------------------------------+----------------------+----------------------|<br />
| Compute processes: GPU Memory |<br />
| GPU PID Process name Usage |<br />
|=============================================================================|<br />
| 0. ERROR: Not Supported |<br />
+-----------------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
Only for temperature:<br />
<br />
{{hc|$ nvidia-smi -q -d TEMPERATURE|<nowiki><br />
<br />
====NVSMI LOG====<br />
<br />
Timestamp : Sun Apr 12 08:49:10 2015<br />
Driver Version : 346.59<br />
<br />
Attached GPUs : 1<br />
GPU 0000:01:00.0<br />
Temperature<br />
GPU Current Temp : 52 C<br />
GPU Shutdown Temp : N/A<br />
GPU Slowdown Temp : N/A<br />
<br />
</nowiki>}}<br />
<br />
In order to get just the temperature for use in utilities such as ''rrdtool'' or ''conky'':<br />
<br />
{{hc|<nowiki>$ nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader,nounits</nowiki>|52}}<br />
<br />
Reference: http://www.question-defense.com/2010/03/22/gpu-linux-shell-temp-get-nvidia-gpu-temperatures-via-linux-cli.<br />
<br />
=== nvclock ===<br />
<br />
Use {{AUR|nvclock}} which is available from the [[AUR]].<br />
<br />
{{Note|''nvclock'' cannot access thermal sensors on newer NVIDIA cards such as Geforce 200 series cards.}}<br />
<br />
There can be significant differences between the temperatures reported by ''nvclock'' and ''nvidia-settings''/''nv-control''. According to [http://sourceforge.net/projects/nvclock/forums/forum/67426/topic/1906899 this post] by the author (thunderbird) of ''nvclock'', the ''nvclock'' values should be more accurate.<br />
<br />
== Set fan speed at login ==<br />
<br />
{{Poor writing|Refer to [[#Enabling overclocking]] for description of ''Coolbits''.}}<br />
<br />
You can adjust the fan speed on your graphics card with ''nvidia-settings''' console interface. First ensure that your Xorg configuration sets the Coolbits option to {{ic|4}}, {{ic|5}} or {{ic|12}} for fermi and above in your {{ic|Device}} section to enable fan control.<br />
<br />
Option "Coolbits" "4"<br />
<br />
{{Note|GeForce 400/500 series cards cannot currently set fan speeds at login using this method. This method only allows for the setting of fan speeds within the current X session by way of nvidia-settings.}}<br />
<br />
Place the following line in your [[xinitrc]] file to adjust the fan when you launch Xorg. Replace {{ic|''n''}} with the fan speed percentage you want to set.<br />
<br />
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=''n''"<br />
<br />
You can also configure a second GPU by incrementing the GPU and fan number.<br />
<br />
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=''n''" \<br />
-a "[gpu:1]/GPUFanControlState=1" -a [fan:1]/GPUCurrentFanSpeed=''n''" &<br />
<br />
If you use a login manager such as GDM or KDM, you can create a desktop entry file to process this setting. Create {{ic|~/.config/autostart/nvidia-fan-speed.desktop}} and place this text inside it. Again, change {{ic|''n''}} to the speed percentage you want.<br />
<br />
[Desktop Entry]<br />
Type=Application<br />
Exec=nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=''n''"<br />
X-GNOME-Autostart-enabled=true<br />
Name=nvidia-fan-speed<br />
<br />
{{Note|Since the drivers version 349.16, {{ic|GPUCurrentFanSpeed}} has to be replaced with {{ic|GPUTargetFanSpeed}}.[https://devtalk.nvidia.com/default/topic/821563/linux/can-t-control-fan-speed-with-beta-driver-349-12/post/4526208/#4526208]}}<br />
<br />
To make it possible to adjust the fanspeed of more than one graphics card, run:<br />
$ nvidia-xconfig --enable-all-gpus<br />
$ nvidia-xconfig --cool-bits=4<br />
<br />
== Manual configuration ==<br />
<br />
Several tweaks (which cannot be enabled [[NVIDIA#Automatic configuration|automatically]] or with the [[NVIDIA#NVIDIA Settings|GUI]]) can be performed by editing your [[NVIDIA#Minimal configuration|config]] file. The Xorg server will need to be restarted before any changes are applied.<br />
<br />
See [ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/README.txt NVIDIA Accelerated Linux Graphics Driver README and Installation Guide] for additional details and options.<br />
<br />
=== Disabling the logo on startup ===<br />
<br />
Add the {{ic|"NoLogo"}} option under section {{ic|Device}}:<br />
Option "NoLogo" "1"<br />
<br />
=== Overriding monitor detection ===<br />
<br />
The {{ic|"ConnectedMonitor"}} option under section {{ic|Device}} allows to override monitor detection when X server starts, which may save a significant amount of time at start up. The available options are: {{ic|"CRT"}} for analog connections, {{ic|"DFP"}} for digital monitors and {{ic|"TV"}} for televisions.<br />
<br />
The following statement forces the NVIDIA driver to bypass startup checks and recognize the monitor as DFP:<br />
Option "ConnectedMonitor" "DFP"<br />
{{Note| Use "CRT" for all analog 15 pin VGA connections, even if the display is a flat panel. "DFP" is intended for DVI, HDMI, or DisplayPort digital connections only.}}<br />
<br />
=== Enabling brightness control ===<br />
<br />
Add under section {{ic|Device}}:<br />
Option "RegistryDwords" "EnableBrightnessControl=1"<br />
<br />
If brightness control still does not work with this option, try installing {{AUR|nvidia-bl}} or {{AUR|nvidiabl}}.<br />
<br />
{{Note|Installing either {{AUR|nvidia-bl}} or {{AUR|nvidiabl}} will provide a {{ic|/sys/class/backlight/nvidia_backlight/}} interface to backlight brightness control, but your system may continue to issue backlight control changes on {{ic|/sys/class/backlight/acpi_video0/}}. One solution in this case is to watch for changes on, e.g. {{ic|acpi_video0/brightness}} with ''inotifywait'' and to translate and write to {{ic|nvidia_backlight/brightness}} accordingly. See [[Backlight#sysfs modified but no brightness change]].}}<br />
<br />
=== Enabling SLI ===<br />
<br />
{{Warning|As of May 7, 2011, you may experience sluggish video performance in GNOME 3 after enabling SLI.}}<br />
{{Warning|Since the GTX 10xx Series (1080, 1070, 1060, etc) only 2-way SLI is supported. 3-way and 4-way SLI may work for CUDA/OpenCL applications, but will most likely break all OpenGL applications.}}<br />
<br />
Taken from the NVIDIA driver's [ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/xconfigoptions.html README] Appendix B: ''This option controls the configuration of SLI rendering in supported configurations.'' A "supported configuration" is a computer equipped with an SLI-Certified Motherboard and 2 or 3 SLI-Certified GeForce GPUs. See NVIDIA's [http://www.slizone.com/page/home.html SLI Zone] for more information.<br />
<br />
Find the first GPU's PCI Bus ID using {{ic|lspci}}:<br />
{{hc|<nowiki>$ lspci | grep VGA</nowiki>|<br />
03:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce 8800 GTS 512] (rev a2)<br />
05:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce 8800 GTS 512] (rev a2)<br />
}}<br />
<br />
Add the BusID (3 in the previous example) under section {{ic|Device}}:<br />
BusID "PCI:3:0:0"<br />
<br />
{{Note|The format is important. The BusID value must be specified as {{ic|"PCI:<BusID>:0:0"}}}}<br />
<br />
Add the desired SLI rendering mode value under section {{ic|Screen}}:<br />
Option "SLI" "AA"<br />
<br />
The following table presents the available rendering modes.<br />
<br />
{| class="wikitable"<br />
! Value !! Behavior<br />
|-<br />
| 0, no, off, false, Single || Use only a single GPU when rendering.<br />
|-<br />
| 1, yes, on, true, Auto || Enable SLI and allow the driver to automatically select the appropriate rendering mode.<br />
|-<br />
| AFR || Enable SLI and use the alternate frame rendering mode.<br />
|-<br />
| SFR || Enable SLI and use the split frame rendering mode.<br />
|-<br />
| AA || Enable SLI and use SLI antialiasing. Use this in conjunction with full scene antialiasing to improve visual quality.<br />
|}<br />
<br />
Alternatively, you can use the {{ic|nvidia-xconfig}} utility to insert these changes into {{ic|xorg.conf}} with a single command:<br />
# nvidia-xconfig --busid=PCI:3:0:0 --sli=AA<br />
<br />
To verify that SLI mode is enabled from a shell:<br />
{{hc|<nowiki>$ nvidia-settings -q all | grep SLIMode</nowiki>|<br />
Attribute 'SLIMode' (arch:0.0): AA <br />
'SLIMode' is a string attribute.<br />
'SLIMode' is a read-only attribute.<br />
'SLIMode' can use the following target types: X Screen.<br />
}}<br />
<br />
{{Warning| After enabling SLI, your system may become frozen/non-responsive upon starting xorg. It is advisable that you disable your display manager before restarting.}}<br />
<br />
=== Enabling overclocking ===<br />
<br />
{{Warning|Please note that overclocking may damage hardware and that no responsibility may be placed on the authors of this page due to any damage to any information technology equipment from operating products out of specifications set by the manufacturer.}}<br />
<br />
Overclocking is controlled via ''Coolbits'' option in the {{ic|Device}} section, which enables various unsupported features:<br />
Option "Coolbits" "''value''"<br />
<br />
{{Tip|The ''Coolbits'' option can be easily controlled with the ''nvidia-xconfig'', which manipulates the Xorg configuration files: {{bc|1=# nvidia-xconfig --cool-bits=''value''}}}}<br />
<br />
The ''Coolbits'' value is the sum of its component bits in the binary numeral system. The component bits are:<br />
<br />
* {{ic|1}} (bit 0) - Enables overclocking of older (pre-Fermi) cores on the ''Clock Frequencies'' page in ''nvidia-settings''.<br />
* {{ic|2}} (bit 1) - When this bit is set, the driver will "attempt to initialize SLI when using GPUs with different amounts of video memory".<br />
* {{ic|4}} (bit 2) - Enables manual configuration of GPU fan speed on the ''Thermal Monitor'' page in ''nvidia-settings''.<br />
* {{ic|8}} (bit 3) - Enables overclocking on the ''PowerMizer'' page in ''nvidia-settings''. Available since version 337.12 for the Fermi architecture and newer.[http://www.phoronix.com/scan.php?px=MTY1OTM&page=news_item]<br />
* {{ic|16}} (bit 4) - Enables overvoltage using ''nvidia-settings'' CLI options. Available since version 346.16 for the Fermi architecture and newer.[http://www.phoronix.com/scan.php?page=news_item&px=MTg0MDI]<br />
<br />
To enable multiple features, add the ''Coolbits'' values together. For example, to enable overclocking and overvoltage of Fermi cores, set {{ic|Option "Coolbits" "24"}}.<br />
<br />
The documentation of ''Coolbits'' can be found in {{ic|/usr/share/doc/nvidia/html/xconfigoptions.html}}. Driver version 346.16 documentation on ''Coolbits'' can be found online [ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/xconfigoptions.html here].<br />
<br />
{{Note|An alternative is to edit and reflash the GPU BIOS either under DOS (preferred), or within a Win32 environment by way of [http://www.mvktech.net/component/option,com_remository/Itemid,26/func,select/id,127/orderby,2/page,1/ nvflash]{{Dead link|2013|05|25}} and [http://www.mvktech.net/component/option,com_remository/Itemid,26/func,select/id,135/orderby,2/page,1/ NiBiTor 6.0]{{Dead link|2013|05|25}}. The advantage of BIOS flashing is that not only can voltage limits be raised, but stability is generally improved over software overclocking methods such as Coolbits. [http://ivanvojtko.blogspot.sk/2014/03/how-to-overclock-geforce-460gtx-fermi.html Fermi BIOS modification tutorial]}}<br />
<br />
==== Setting static 2D/3D clocks ====<br />
<br />
Set the following string in the {{ic|Device}} section to enable PowerMizer at its maximum performance level (VSync will not work without this line):<br />
Option "RegistryDwords" "PerfLevelSrc=0x2222"<br />
<br />
==== Allow change to highest Performance Mode====<br />
<br />
Since changing Performance Mode and Overclocking Memory Rate has little to no effect in nvidia-settings, try this:<br />
<br />
- Setting Coolbits to 24 or 28 and remove Powermizer RegistryDwords -> Restart X<br />
- find out max. Clock and Memory rate. (this can be LOWER than what your gfx card reports after booting!):<br />
nvidia-smi -q -d SUPPORTED_CLOCKS<br />
<br />
- set rates for GPU 0:<br />
sudo nvidia-smi -i 0 -ac memratemax,clockratemax<br />
<br />
After setting the rates the max. Performance Mode works in nvidia-settings and you can overclock graphics-clock AND Memory Transfer Rate.<br />
This does not increase mining performance (didn't try with games) on my gtx 960,<br />
but just overclocking the memory transfer rate reduced power usage a little bit.<br />
<br />
==== Watt-Limiting ====<br />
<br />
- List your GPUs and their according Power Usage and Limits<br />
nvidia-smi<br />
<br />
- Limit GPU 0 to 60 watts<br />
sudo nvidia-smi -i 0 -pl 60<br />
<br />
According to my energy meter this works quite accurate.</div>Strikemybreadhttps://wiki.archlinux.org/index.php?title=NVIDIA/Tips_and_tricks&diff=485262NVIDIA/Tips and tricks2017-08-13T13:00:42Z<p>Strikemybread: added two tricks</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[ja:NVIDIA/Tips and tricks]]<br />
[[ru:NVIDIA/Tips and tricks]]<br />
== Fixing terminal resolution ==<br />
<br />
Transitioning from nouveau may cause your startup terminal to display at a lower resolution. For GRUB, see [[GRUB/Tips and tricks#Setting the framebuffer resolution]] for details.<br />
<br />
== Using TV-out ==<br />
<br />
A good article on the subject can be found [http://en.wikibooks.org/wiki/NVidia/TV-OUT here].<br />
<br />
== X with a TV (DFP) as the only display ==<br />
<br />
The X server falls back to CRT-0 if no monitor is automatically detected. This can be a problem when using a DVI connected TV as the main display, and X is started while the TV is turned off or otherwise disconnected.<br />
<br />
To force NVIDIA to use DFP, store a copy of the EDID somewhere in the filesystem so that X can parse the file instead of reading EDID from the TV/DFP.<br />
<br />
To acquire the EDID, start nvidia-settings. It will show some information in tree format, ignore the rest of the settings for now and select the GPU (the corresponding entry should be titled "GPU-0" or similar), click the {{ic|DFP}} section (again, {{ic|DFP-0}} or similar), click on the {{ic|Acquire Edid}} Button and store it somewhere, for example, {{ic|/etc/X11/dfp0.edid}}.<br />
<br />
If in the front-end mouse and keyboard are not attached, the EDID can be acquired using only the command line. Run an X server with enough verbosity to print out the EDID block:<br />
$ startx -- -logverbose 6<br />
After the X Server has finished initializing, close it and your log file will probably be in {{ic|/var/log/Xorg.0.log}}. Extract the EDID block using nvidia-xconfig:<br />
$ nvidia-xconfig --extract-edids-from-file=/var/log/Xorg.0.log --extract-edids-output-file=/etc/X11/dfp0.bin<br />
<br />
Edit {{ic|xorg.conf}} by adding to the {{ic|Device}} section:<br />
Option "ConnectedMonitor" "DFP"<br />
Option "CustomEDID" "DFP-0:/etc/X11/dfp0.edid"<br />
The {{ic|ConnectedMonitor}} option forces the driver to recognize the DFP as if it were connected. The {{ic|CustomEDID}} provides EDID data for the device, meaning that it will start up just as if the TV/DFP was connected during X the process.<br />
<br />
This way, one can automatically start a display manager at boot time and still have a working and properly configured X screen by the time the TV gets powered on.<br />
<br />
If the above changes did not work, in the {{ic|xorg.conf}} under {{ic|Device}} section you can try to remove the {{ic|Option "ConnectedMonitor" "DFP"}} and add the following lines:<br />
Option "ModeValidation" "NoDFPNativeResolutionCheck"<br />
Option "ConnectedMonitor" "DFP-0"<br />
<br />
The {{ic|NoDFPNativeResolutionCheck}} prevents NVIDIA driver from disabling all the modes that do not fit in the native resolution.<br />
<br />
== Check the power source ==<br />
<br />
The NVIDIA X.org driver can also be used to detect the GPU's current source of power. To see the current power source, check the 'GPUPowerSource' read-only parameter (0 - AC, 1 - battery):<br />
<br />
{{hc|$ nvidia-settings -q GPUPowerSource -t|1}}<br />
<br />
== Listening to ACPI events ==<br />
<br />
NVIDIA drivers automatically try to connect to the [[acpid]] daemon and listen to ACPI events such as battery power, docking, some hotkeys, etc. If connection fails, X.org will output the following warning:<br />
<br />
{{hc|~/.local/share/xorg/Xorg.0.log|<br />
NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon<br />
NVIDIA(0): may not be running or the "AcpidSocketPath" X<br />
NVIDIA(0): configuration option may not be set correctly. When the<br />
NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will<br />
NVIDIA(0): try to use it to receive ACPI event notifications. For<br />
NVIDIA(0): details, please see the "ConnectToAcpid" and<br />
NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X<br />
NVIDIA(0): Config Options in the README.<br />
}}<br />
<br />
While completely harmless, you may get rid of this message by disabling the {{ic|ConnectToAcpid}} option in your {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}}:<br />
<br />
Section "Device"<br />
...<br />
Driver "nvidia"<br />
Option "ConnectToAcpid" "0"<br />
...<br />
EndSection<br />
<br />
If you are on laptop, it might be a good idea to install and enable the [[acpid]] daemon instead.<br />
<br />
== Displaying GPU temperature in the shell ==<br />
<br />
There are three methods to query the GPU temperature. ''nvidia-settings'' requires that you are using X, ''nvidia-smi'' or ''nvclock'' do not. Also note that ''nvclock'' currently does not work with newer NVIDIA cards such as GeForce 200 series cards as well as embedded GPUs such as the Zotac IONITX's 8800GS.<br />
<br />
=== nvidia-settings ===<br />
<br />
To display the GPU temp in the shell, use ''nvidia-settings'' as follows:<br />
$ nvidia-settings -q gpucoretemp<br />
<br />
This will output something similar to the following:<br />
Attribute 'GPUCoreTemp' (hostname:0.0): 41.<br />
'GPUCoreTemp' is an integer attribute.<br />
'GPUCoreTemp' is a read-only attribute.<br />
'GPUCoreTemp' can use the following target types: X Screen, GPU.<br />
<br />
The GPU temps of this board is 41 C.<br />
<br />
In order to get just the temperature for use in utilities such as ''rrdtool'' or ''conky'':<br />
<br />
{{hc|$ nvidia-settings -q gpucoretemp -t|41}}<br />
<br />
=== nvidia-smi ===<br />
<br />
Use ''nvidia-smi'' which can read temps directly from the GPU without the need to use X at all, e.g. when running Wayland or on a headless server. <br />
To display the GPU temperature in the shell, use ''nvidia-smi'' as follows:<br />
<br />
$ nvidia-smi<br />
<br />
This should output something similar to the following:<br />
<br />
{{hc|$ nvidia-smi|<nowiki><br />
Fri Jan 6 18:53:54 2012 <br />
+------------------------------------------------------+ <br />
| NVIDIA-SMI 2.290.10 Driver Version: 290.10 | <br />
|-------------------------------+----------------------+----------------------+<br />
| Nb. Name | Bus Id Disp. | Volatile ECC SB / DB |<br />
| Fan Temp Power Usage /Cap | Memory Usage | GPU Util. Compute M. |<br />
|===============================+======================+======================|<br />
| 0. GeForce 8500 GT | 0000:01:00.0 N/A | N/A N/A |<br />
| 30% 62 C N/A N/A / N/A | 17% 42MB / 255MB | N/A Default |<br />
|-------------------------------+----------------------+----------------------|<br />
| Compute processes: GPU Memory |<br />
| GPU PID Process name Usage |<br />
|=============================================================================|<br />
| 0. ERROR: Not Supported |<br />
+-----------------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
Only for temperature:<br />
<br />
{{hc|$ nvidia-smi -q -d TEMPERATURE|<nowiki><br />
<br />
====NVSMI LOG====<br />
<br />
Timestamp : Sun Apr 12 08:49:10 2015<br />
Driver Version : 346.59<br />
<br />
Attached GPUs : 1<br />
GPU 0000:01:00.0<br />
Temperature<br />
GPU Current Temp : 52 C<br />
GPU Shutdown Temp : N/A<br />
GPU Slowdown Temp : N/A<br />
<br />
</nowiki>}}<br />
<br />
In order to get just the temperature for use in utilities such as ''rrdtool'' or ''conky'':<br />
<br />
{{hc|<nowiki>$ nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader,nounits</nowiki>|52}}<br />
<br />
Reference: http://www.question-defense.com/2010/03/22/gpu-linux-shell-temp-get-nvidia-gpu-temperatures-via-linux-cli.<br />
<br />
=== nvclock ===<br />
<br />
Use {{AUR|nvclock}} which is available from the [[AUR]].<br />
<br />
{{Note|''nvclock'' cannot access thermal sensors on newer NVIDIA cards such as Geforce 200 series cards.}}<br />
<br />
There can be significant differences between the temperatures reported by ''nvclock'' and ''nvidia-settings''/''nv-control''. According to [http://sourceforge.net/projects/nvclock/forums/forum/67426/topic/1906899 this post] by the author (thunderbird) of ''nvclock'', the ''nvclock'' values should be more accurate.<br />
<br />
== Set fan speed at login ==<br />
<br />
{{Poor writing|Refer to [[#Enabling overclocking]] for description of ''Coolbits''.}}<br />
<br />
You can adjust the fan speed on your graphics card with ''nvidia-settings''' console interface. First ensure that your Xorg configuration sets the Coolbits option to {{ic|4}}, {{ic|5}} or {{ic|12}} for fermi and above in your {{ic|Device}} section to enable fan control.<br />
<br />
Option "Coolbits" "4"<br />
<br />
{{Note|GeForce 400/500 series cards cannot currently set fan speeds at login using this method. This method only allows for the setting of fan speeds within the current X session by way of nvidia-settings.}}<br />
<br />
Place the following line in your [[xinitrc]] file to adjust the fan when you launch Xorg. Replace {{ic|''n''}} with the fan speed percentage you want to set.<br />
<br />
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=''n''"<br />
<br />
You can also configure a second GPU by incrementing the GPU and fan number.<br />
<br />
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=''n''" \<br />
-a "[gpu:1]/GPUFanControlState=1" -a [fan:1]/GPUCurrentFanSpeed=''n''" &<br />
<br />
If you use a login manager such as GDM or KDM, you can create a desktop entry file to process this setting. Create {{ic|~/.config/autostart/nvidia-fan-speed.desktop}} and place this text inside it. Again, change {{ic|''n''}} to the speed percentage you want.<br />
<br />
[Desktop Entry]<br />
Type=Application<br />
Exec=nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=''n''"<br />
X-GNOME-Autostart-enabled=true<br />
Name=nvidia-fan-speed<br />
<br />
{{Note|Since the drivers version 349.16, {{ic|GPUCurrentFanSpeed}} has to be replaced with {{ic|GPUTargetFanSpeed}}.[https://devtalk.nvidia.com/default/topic/821563/linux/can-t-control-fan-speed-with-beta-driver-349-12/post/4526208/#4526208]}}<br />
<br />
To make it possible to adjust the fanspeed of more than one graphics card, run:<br />
$ nvidia-xconfig --enable-all-gpus<br />
$ nvidia-xconfig --cool-bits=4<br />
<br />
== Manual configuration ==<br />
<br />
Several tweaks (which cannot be enabled [[NVIDIA#Automatic configuration|automatically]] or with the [[NVIDIA#NVIDIA Settings|GUI]]) can be performed by editing your [[NVIDIA#Minimal configuration|config]] file. The Xorg server will need to be restarted before any changes are applied.<br />
<br />
See [ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/README.txt NVIDIA Accelerated Linux Graphics Driver README and Installation Guide] for additional details and options.<br />
<br />
=== Disabling the logo on startup ===<br />
<br />
Add the {{ic|"NoLogo"}} option under section {{ic|Device}}:<br />
Option "NoLogo" "1"<br />
<br />
=== Overriding monitor detection ===<br />
<br />
The {{ic|"ConnectedMonitor"}} option under section {{ic|Device}} allows to override monitor detection when X server starts, which may save a significant amount of time at start up. The available options are: {{ic|"CRT"}} for analog connections, {{ic|"DFP"}} for digital monitors and {{ic|"TV"}} for televisions.<br />
<br />
The following statement forces the NVIDIA driver to bypass startup checks and recognize the monitor as DFP:<br />
Option "ConnectedMonitor" "DFP"<br />
{{Note| Use "CRT" for all analog 15 pin VGA connections, even if the display is a flat panel. "DFP" is intended for DVI, HDMI, or DisplayPort digital connections only.}}<br />
<br />
=== Enabling brightness control ===<br />
<br />
Add under section {{ic|Device}}:<br />
Option "RegistryDwords" "EnableBrightnessControl=1"<br />
<br />
If brightness control still does not work with this option, try installing {{AUR|nvidia-bl}} or {{AUR|nvidiabl}}.<br />
<br />
{{Note|Installing either {{AUR|nvidia-bl}} or {{AUR|nvidiabl}} will provide a {{ic|/sys/class/backlight/nvidia_backlight/}} interface to backlight brightness control, but your system may continue to issue backlight control changes on {{ic|/sys/class/backlight/acpi_video0/}}. One solution in this case is to watch for changes on, e.g. {{ic|acpi_video0/brightness}} with ''inotifywait'' and to translate and write to {{ic|nvidia_backlight/brightness}} accordingly. See [[Backlight#sysfs modified but no brightness change]].}}<br />
<br />
=== Enabling SLI ===<br />
<br />
{{Warning|As of May 7, 2011, you may experience sluggish video performance in GNOME 3 after enabling SLI.}}<br />
{{Warning|Since the GTX 10xx Series (1080, 1070, 1060, etc) only 2-way SLI is supported. 3-way and 4-way SLI may work for CUDA/OpenCL applications, but will most likely break all OpenGL applications.}}<br />
<br />
Taken from the NVIDIA driver's [ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/xconfigoptions.html README] Appendix B: ''This option controls the configuration of SLI rendering in supported configurations.'' A "supported configuration" is a computer equipped with an SLI-Certified Motherboard and 2 or 3 SLI-Certified GeForce GPUs. See NVIDIA's [http://www.slizone.com/page/home.html SLI Zone] for more information.<br />
<br />
Find the first GPU's PCI Bus ID using {{ic|lspci}}:<br />
{{hc|<nowiki>$ lspci | grep VGA</nowiki>|<br />
03:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce 8800 GTS 512] (rev a2)<br />
05:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce 8800 GTS 512] (rev a2)<br />
}}<br />
<br />
Add the BusID (3 in the previous example) under section {{ic|Device}}:<br />
BusID "PCI:3:0:0"<br />
<br />
{{Note|The format is important. The BusID value must be specified as {{ic|"PCI:<BusID>:0:0"}}}}<br />
<br />
Add the desired SLI rendering mode value under section {{ic|Screen}}:<br />
Option "SLI" "AA"<br />
<br />
The following table presents the available rendering modes.<br />
<br />
{| class="wikitable"<br />
! Value !! Behavior<br />
|-<br />
| 0, no, off, false, Single || Use only a single GPU when rendering.<br />
|-<br />
| 1, yes, on, true, Auto || Enable SLI and allow the driver to automatically select the appropriate rendering mode.<br />
|-<br />
| AFR || Enable SLI and use the alternate frame rendering mode.<br />
|-<br />
| SFR || Enable SLI and use the split frame rendering mode.<br />
|-<br />
| AA || Enable SLI and use SLI antialiasing. Use this in conjunction with full scene antialiasing to improve visual quality.<br />
|}<br />
<br />
Alternatively, you can use the {{ic|nvidia-xconfig}} utility to insert these changes into {{ic|xorg.conf}} with a single command:<br />
# nvidia-xconfig --busid=PCI:3:0:0 --sli=AA<br />
<br />
To verify that SLI mode is enabled from a shell:<br />
{{hc|<nowiki>$ nvidia-settings -q all | grep SLIMode</nowiki>|<br />
Attribute 'SLIMode' (arch:0.0): AA <br />
'SLIMode' is a string attribute.<br />
'SLIMode' is a read-only attribute.<br />
'SLIMode' can use the following target types: X Screen.<br />
}}<br />
<br />
{{Warning| After enabling SLI, your system may become frozen/non-responsive upon starting xorg. It is advisable that you disable your display manager before restarting.}}<br />
<br />
=== Enabling overclocking ===<br />
<br />
{{Warning|Please note that overclocking may damage hardware and that no responsibility may be placed on the authors of this page due to any damage to any information technology equipment from operating products out of specifications set by the manufacturer.}}<br />
<br />
Overclocking is controlled via ''Coolbits'' option in the {{ic|Device}} section, which enables various unsupported features:<br />
Option "Coolbits" "''value''"<br />
<br />
{{Tip|The ''Coolbits'' option can be easily controlled with the ''nvidia-xconfig'', which manipulates the Xorg configuration files: {{bc|1=# nvidia-xconfig --cool-bits=''value''}}}}<br />
<br />
The ''Coolbits'' value is the sum of its component bits in the binary numeral system. The component bits are:<br />
<br />
* {{ic|1}} (bit 0) - Enables overclocking of older (pre-Fermi) cores on the ''Clock Frequencies'' page in ''nvidia-settings''.<br />
* {{ic|2}} (bit 1) - When this bit is set, the driver will "attempt to initialize SLI when using GPUs with different amounts of video memory".<br />
* {{ic|4}} (bit 2) - Enables manual configuration of GPU fan speed on the ''Thermal Monitor'' page in ''nvidia-settings''.<br />
* {{ic|8}} (bit 3) - Enables overclocking on the ''PowerMizer'' page in ''nvidia-settings''. Available since version 337.12 for the Fermi architecture and newer.[http://www.phoronix.com/scan.php?px=MTY1OTM&page=news_item]<br />
* {{ic|16}} (bit 4) - Enables overvoltage using ''nvidia-settings'' CLI options. Available since version 346.16 for the Fermi architecture and newer.[http://www.phoronix.com/scan.php?page=news_item&px=MTg0MDI]<br />
<br />
To enable multiple features, add the ''Coolbits'' values together. For example, to enable overclocking and overvoltage of Fermi cores, set {{ic|Option "Coolbits" "24"}}.<br />
<br />
The documentation of ''Coolbits'' can be found in {{ic|/usr/share/doc/nvidia/html/xconfigoptions.html}}. Driver version 346.16 documentation on ''Coolbits'' can be found online [ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/xconfigoptions.html here].<br />
<br />
{{Note|An alternative is to edit and reflash the GPU BIOS either under DOS (preferred), or within a Win32 environment by way of [http://www.mvktech.net/component/option,com_remository/Itemid,26/func,select/id,127/orderby,2/page,1/ nvflash]{{Dead link|2013|05|25}} and [http://www.mvktech.net/component/option,com_remository/Itemid,26/func,select/id,135/orderby,2/page,1/ NiBiTor 6.0]{{Dead link|2013|05|25}}. The advantage of BIOS flashing is that not only can voltage limits be raised, but stability is generally improved over software overclocking methods such as Coolbits. [http://ivanvojtko.blogspot.sk/2014/03/how-to-overclock-geforce-460gtx-fermi.html Fermi BIOS modification tutorial]}}<br />
<br />
==== Setting static 2D/3D clocks ====<br />
<br />
Set the following string in the {{ic|Device}} section to enable PowerMizer at its maximum performance level (VSync will not work without this line):<br />
Option "RegistryDwords" "PerfLevelSrc=0x2222"<br />
<br />
==== Allow change to highest Performance Mode====<br />
<br />
Since changing Performance Mode and Overclocking Memory Rate has little to no effect in nvidia-settings, try this:<br />
<br />
- Setting Coolbits to 24 or 28 and remove Powermizer RegistryDwords -> Restart X<br />
- find out max. Clock and Memory rate. (this can be LOWER than what your gfx card reports after booting!):<br />
nvidia-smi -q -d SUPPORTED_CLOCKS<br />
<br />
- set rates for GPU 0:<br />
sudo nvidia-smi -i 0 -ac memratemax,clockratemax<br />
<br />
After setting the rates the max. Performance Mode works in nvidia-settings and you can overclock graphics-clock and Memory Transfer Rate.<br />
<br />
==== Watt-Limiting ====<br />
<br />
- List your GPUs and their according Power Usage and Limits<br />
nvidia-smi<br />
<br />
- Limit GPU 0 to 60 watts<br />
sudo nvidia-smi -i 0 -pl 60</div>Strikemybread