00:15 karolherbst: nice " Failed: 3/7773 (0.0%)"
00:16 karolherbst: hum, why did "KHR-GL45.packed_pixels.varied_rectangle.rg16i" suddenly fail
00:17 karolherbst: annoying
00:22 imirkin: karolherbst: just make sure you indent any CTS code with at least 80 characters of tabs. preferably 160.
00:23 karolherbst: the indentation is so terrible in the CTS then I can hardly care about code style there... :(
00:23 imirkin: it took me a while to understand why all the code looked double-spaced in my editor
00:23 karolherbst: but yeah, I guess I should do my best still
00:24 karolherbst: :D
00:24 imirkin: common when writing essays, less common when writing code
00:24 karolherbst: well in github it kind of looks okayish actually
00:24 imirkin: since my editor width is set to 80, and EVERY line in the section of code i was looking at was indented further
00:28 karolherbst: I am sure the code was originally generated where the author didn't really cared much about indentation and the other devs tried to make sense out of it and just went with that...
00:28 karolherbst: or maybe nobody actually cares
00:29 karolherbst: anyway, I guess the most annoying tests fails are left now, KHR-GL45.packed_depth_stencil.blit.depth32f_stencil8 and KHR-GL45.shader_image_load_store.non-layered_binding :(
00:30 karolherbst: I think for the depth32f_stencil8 one nvidia is resolving the samples inside a vertex shader
00:31 karolherbst: or is doing some other weird magic
00:32 karolherbst: anyway, the vertex shader I found while tracing this is super weird
00:34 imirkin: a lot of times nvidia will stick in a fake vertex shader for reasons unknown
00:34 imirkin: instead of reading shader inputs
00:34 imirkin: it reads them from a constbuf
00:35 imirkin: i think it's an opt where you know that a certain vertex input is always the same value
00:35 imirkin: and due to the way their variants work, they happen to upload that style of shader, but it's never used.
00:35 karolherbst: ohhhh
00:36 karolherbst: well I was mainly curious because the fp shader following looked quite like our blitter
00:36 imirkin: vertex shader would have little to do with resolving depth
00:36 imirkin: it'd just be various output parameters in the RT[] logic
00:36 imirkin: and surface parameters
00:36 karolherbst: okay
04:21 rhyskidd: Volta's BIT table 'P' v2 appears to be setting odd offsets (e.g. too far away) for entries at 0x14, 0x28 - 0x64 and 0x74 - 98
04:21 rhyskidd: seen with three sample VBIOS from Volta now
04:22 rhyskidd: odd, as no change in the version # of that table from Pascal
04:22 rhyskidd: and we have known docs for the table entries: https://download.nvidia.com/open-gpu-doc/BIOS-Information-Table/1/BIOS-Information-Table.html#BIT_PERF_PTRS_v2
13:29 karolherbst: rhyskidd: you have to extract the vbios via nouveau
13:29 karolherbst: if you use nvagetbios you get a weirdo vbios with multiple parts
13:29 karolherbst: nvbios can't handle that yet
16:10 karolherbst: imirkin: mhh, if we have the situation where glReadPixels gives us different data than a texture view (I assume that is being used in qapitrace?), then something is wrong inside either of those method, most likely glReadPixels, right? It's always a bit confusing if a piglit test says something is wrong, but in qapitrace it all looks just fine :(
20:04 Elv1313: Hi, I am still on the almost EoL 4.4 kernel because anything > 4.7 broke bbswitch and my power hungry NVIDIA Quadro eat the battery in minutes instead of 9 hours. Some people say nouveau can disable the GPU so I get 6 watt instead of 35 watt again. I can't find doc on this. Is it possible?
20:11 Lyude: nouveau will automatically uspend your gpu if you aren't using it on a hybrid system, yes
20:11 Lyude: no additional work needed, it should just work right out of the box
20:12 Lyude: (no bumblebee hacks required, either. in fact, I'd even recommend removing bumblebee entirely if you are planning on using nouveau
20:12 Elv1313: Lyude: last time I tried, all I had was a green #00ff00 screen and the laptop kernel panic 10 seconds later
20:12 Lyude: that sounds like a bug that should be reported then so we can fix it ;)
20:13 Lyude: does anyone know if there's a reason that we don't just enable atomic modesetting by default (skeggsb?)
20:13 Elv1313:because it crashes my 2012 macOS laptop when it is
20:14 Lyude: atomic modesetting?
20:15 Elv1313: whatever nomodeset is for
20:15 Lyude: nomodeset turns off your graphics driver
20:15 Lyude: don't add it
20:15 Lyude: unless you're using nvidia's blob
20:16 Elv1313:compiling nouveau right now, lets see what happen
20:16 Lyude: also, it would appear fedora's kernel is keeping nouveau from autosuspending the secondaRY GPU on here when it's not in use, hrm.
20:17 Elv1313: Usually (like 99.9% of the time), I want no NVIDIA GPU at all. I -only- need it when I run some OpenCL stuff and it is very rare. I value longer battery life a lot more than shiny graphics
20:18 Elv1313:about to modprobe nouveau, I might log me out
20:18 Lyude: yes, like i said nouveau will shut your GPU down (it's supposed to, anyway. if that's broken i'm about to fix it) after it hasn't been used for a short period of time
20:19 Elv1313: Lyude: brb, I need to reboot "[35867.426014] nouveau: Unknown symbol drm_legacy_mmap (err 0)"
20:22 Elv1313:back
20:22 Elv1313: Lyude: Nope, it doesn't work, I got 35 watts instead of 6
20:22 Elv1313: (according to powertop, kernel 4.16-latest, self compiled)
20:23 Lyude: try the latest upstream kernel, 4.16 might have had some runtime pm issues
20:23 Lyude: additionally, you're only driving a single display in this config right?
20:23 Elv1313: latest as in git-master or stable?
20:23 Lyude: git master
20:24 karolherbst: Lyude: even with nvidias blobs you don't add nomodeset
20:24 Lyude: ah right
20:24 Lyude: if that's the case i need to actually go and submit that patch for printing errors on nomodeset like I said I would before
20:24 karolherbst: their modesetting support is quite okayish, used it on a new laptop I got where I can set to nvidia only
20:25 Lyude: I bet there are a LOT of tutorials out there that suggest nomodeset
20:25 karolherbst: dracut -> sddm migration is still not working out that nice though
20:25 karolherbst: yes
20:25 karolherbst: and a lot of debian forum posts
20:25 Elv1313: As for that laptop, I guess nobody try the NVIDIA Mac anymore. I got the "last" and most powerful one, the original retina. If there is no nomodeset, it crash
20:25 Lyude: yes
20:25 Lyude: that's completely expected
20:25 airlied: I don't think we got dynamic power on macbooks
20:25 karolherbst: Elv1313: yeah well, it depends why it crashes
20:25 airlied: since they are "special"
20:25 karolherbst: airlied: we kind of have
20:26 karolherbst: pmoreau knows more as he has such
20:26 karolherbst: I think it works on some
20:26 airlied: karolherbst: yeah, I don't think the retina is one of those though
20:26 Lyude: btw karolherbst, didn't you say the other day you were working on ci stuff for nouveau?
20:26 karolherbst: might be, yes
20:26 karolherbst: Lyude: it is quite high on my todo list actually, yeah
20:26 airlied: most retina's boot up in nvidia only mode anyways unless you do some magic in OSX
20:27 karolherbst: Lyude: actually I thought some others would work on this, but apperantly nothing happens there, so I should work on that on my own I guess
20:27 Lyude: karolherbst: goodo, I only realized just the other day how many parts of igt are not actually as non-intel as I had assumed
20:27 Lyude: karolherbst: i can totally help, power related stuff for nouveau is also on my list but imo it is a lot more important we have CI then that
20:27 karolherbst: airlied: afaik that only happens if you boot in CMS mode
20:27 Lyude: ...also I can actually push stuff you do to igt :)
20:27 karolherbst: uhm CSM
20:27 karolherbst: maybe that changed
20:28 karolherbst: but my macbook I had was disabling the intel GPU completly in CSM mode
20:28 karolherbst: so the dedicated GPU was the only one
20:28 karolherbst: but, if booted in uefi mode, the device still defaulted to the AMD one, yes
20:28 karolherbst: but might be that this changed
20:28 Elv1313: It worked until whatever Ubuntu 16.04.0 shipped with. It broke afterward. I use Gentoo and added nomodeset on it, so I don't know. I only use that laptop to test HiDPI stuff
20:28 karolherbst: or CSM isn't a thing anymore
20:29 Lyude: nothing is going to work if you add nomodeset
20:29 karolherbst: Elv1313: do you have a dmesg from the time it crashed?
20:29 airlied: karolherbst: mine is efi only
20:29 Elv1313: karolherbst: I think it's more trouble that it is worth. And no, because it crashed in initramfs so nothing persist at all. I would need to create a custom OS on a usb stick to get the KP
20:29 karolherbst: ahh
20:30 karolherbst: Elv1313: well, with nomodeset basically nothing will work
20:30 airlied: there was a flag to set in efi to pick intel or nvidia by default
20:30 karolherbst: like literally, nothing
20:30 Elv1313: Intel works ;)
20:31 karolherbst: Elv1313: no
20:31 karolherbst: it doesn't
20:31 Elv1313: yes it does
20:31 Lyude: no
20:31 karolherbst: it isn't used ;)
20:31 Lyude: it doesn't
20:31 Lyude: you're seeing vesa
20:31 karolherbst: you get no OpenGL
20:31 Lyude: the intel GPU is being managed by the bios which means you're not getting any power manaement
20:31 karolherbst: everything is software rendered
20:31 Elv1313: there is no bios
20:31 karolherbst: your battery lifetime is crappy
20:31 karolherbst: anyway
20:31 karolherbst: with nomodeset you are on your own
20:31 Lyude: Elv1313: drivers/video/console/vgacon.c:119
20:31 karolherbst: because, it exactly does what you asked for
20:31 Lyude: there is the actual line that makes it disable your video drivers in the kernel
20:32 Elv1313: I don't want to get further into that Mac discussion thing, nobody care about these devices anyway, neither do I
20:32 Elv1313: Lets fix that Quadro issue on a real computer
20:32 Lyude: will people be up to reviewing a patch I'll probably send out in a little bit to start printing errors on having nomodeset enabled?
20:32 karolherbst: Elv1313: if you think you have problems when using nomodeset, ask this question: is something broken displaying stuff? no? then you have no bug ;)
20:32 karolherbst: Elv1313: what quadro issue?
20:33 Elv1313: I was talking with Lyude about a power managment problem on kernel > 4.7 on a workstation laptop with a Quadro GPU. It uses 30 watt more that it should
20:33 Lyude: Elv1313: can you cat /proc/cmdline on that machine
20:33 karolherbst: you use nomodeset, you have no issue ;)
20:34 Elv1313: I am not using nomodeset on that one
20:34 karolherbst: ahh, okay
20:34 karolherbst: what quadro gpu?
20:34 Elv1313: GK107GLM
20:34 HdkR: Is Nouveau missing an optimization on Maxwell where it tries to merge cbank loads in to an instruction so you don't get a freestanding move?
20:34 karolherbst: HdkR: yes
20:34 HdkR: Damn
20:34 Lyude: (ironically, that is exactly the gpu I am seeing get kept on by runtime power management when it shouldn't be)
20:35 karolherbst: HdkR: movs are not significant though
20:35 HdkR: karolherbst: Sure. I just saw a shader that was literally twice the length due to them though
20:35 Elv1313: Lyude: I am compiling Linux git-master right now, wont be long, but I will have to reboot again
20:35 Lyude: alright
20:35 karolherbst: Elv1313: usually you should get the power managemet stuff, but sometimes firmware is odd or we don't support/do something we sould
20:36 HdkR: Obviously moves aren't significant, but when they double the program size I can see it being an issue :P
20:36 Elv1313: karolherbst: Technically, I don't want PM stuff, I just want to disable the damn thing
20:36 karolherbst: yeah, which is done by the pm stuff
20:36 karolherbst: allthough bbswitch should just work
20:36 Elv1313: karolherbst: In Linux <= 4.7, bbswtich worked, but it's broken now, so I am on 4.4
20:37 karolherbst: Elv1313: how did you install bbswitch?
20:37 karolherbst: allthough I guess it shoulnd't matter today, es develop == master branch
20:37 Elv1313: karolherbst: It is official, bbswitch does not support he new kernels, they said that themselves
20:37 Elv1313: It's 4.4 or nouveau
20:38 karolherbst: mhh, odd
20:38 Elv1313: (4.4 being the last supported LTS that works)
20:38 karolherbst: I mean they can't support the pr3 stuff properly
20:38 karolherbst: but yeah
20:38 karolherbst: it should still work
20:38 nyef: Lyude: You said that you're seeing PM issues on the GK107GLM, are you seeing the same on GK107M as well?
20:38 karolherbst: I think the last time I used bbswitch was on a 4.13 kernel or so
20:39 karolherbst: Elv1313: did you actually tried bbswitch on a newer kernel?
20:39 Elv1313: karolherbst: yes
20:39 karolherbst: what was the issue you were seeing?
20:40 Elv1313: And I added the workaround `modprobe.blacklist=nouveau pcie_port_pm=off` proposed by them and I got one of the laptop where it doesn't work for everybody
20:40 Elv1313: karolherbst: I get 35 watts instead of 6
20:40 karolherbst: hum, weird
20:41 karolherbst: Elv1313: did you verify that bbswitch was loaded?
20:41 karolherbst: and did you verify the /proc/acpi/bbswitch status file?
20:41 Elv1313: karolherbst: Yes, I did all that, it is official: It work work on 4.7+ because of changes in the kernel
20:42 karolherbst: what means "official"? some offical blog post or something or some random guy on IRC?
20:42 Elv1313: https://github.com/Bumblebee-Project/bbswitch/issues/170 https://github.com/Bumblebee-Project/bbswitch/issues/140
20:44 karolherbst: I see
20:44 karolherbst: in worst case you could do the ACPI magic yourself, but this is a bit ugly
20:45 karolherbst: Elv1313: and if you boot with nouveau the system simply crashes/freezes or something like that?
20:45 Elv1313: karolherbst: I came here in the hope of having a nouveau based solution ;)
20:45 karolherbst: yeah sure, I just want to get a better picture of the overall situation, because I assumed that bbswitch still kind of works
20:45 Elv1313: karolherbst: It used to crash, but I am on 4.16 with nouveau loaded (using X11 Intel) and it did not crash
20:45 karolherbst: I see
20:45 karolherbst: and the power consumption is still high?
20:45 Elv1313: I will reboot into git-master now, brb
20:46 Elv1313: yes, still 35w
20:47 Elv1313: back
20:47 Elv1313: Linux elepage-laptop 4.18.0-rc3+ #1 SMP PREEMPT Mon Jul 2 20:31:14 EDT 2018 x86_64 Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz GenuineIntel GNU/Linux
20:48 karolherbst: Elv1313: mind checking the /sys/kernel/debug/vgaswitcheroo/switch file?
20:48 Elv1313: karolherbst: I am now on a bbswitch kernel I just compiled
20:48 Elv1313: but it was OFF
20:50 pmoreau: airlied, karolherbst: IIRC, suspend works fine, the issue is more if you want to switch at runtime between the integrated and the discrete, as main GPU. (suspend works fine on my second gen MBP retina, at least)
20:50 pmoreau: But not out of the box, you need extra patches to get the suspend.
20:51 Elv1313: sorry lost the net for a minute by abusing of the ACPI slider, missed something?
20:51 karolherbst: Elv1313: not really
20:51 karolherbst: Elv1313: I am just wondering mainly what issues you saw when using nouveau
20:51 karolherbst: dmesg might help, /sys/kernel/debug/vgaswitcheroo/switch might help as well
20:52 Elv1313: Lyude: I installed git-master, the PM is much better, but still > 20w, so there is still 14 watts to be accounted for
20:52 karolherbst: Lyude: powergating is still disabled by default, right?
20:53 Lyude: karolherbst: yes
20:53 Lyude: we don't have support for powergating on maxwell yet as well
20:54 Lyude: i still need to figure out some stuff
20:54 Elv1313: umm, 19.2w over 3 minutes with wifi and Firefox running. So I guess if I shut down both it would be ~16w. So it is actually quite good compared to 35w!
20:54 Elv1313: Lyude, karolherbst: any kernel parameter I can use to alpha test? After all I don't use that GPU, so I might not be affected by glitches
20:54 HdkR: karolherbst: Just for reference. I was looking at the vertex shader in es2gears and saw this issue with the moves. Confused me that it grew to such a massive set of instructions :P
20:55 karolherbst: Elv1313: you can provide output of your dmesg and what is inside /sys/kernel/debug/vgaswitcheroo/switch
20:55 Lyude: Elv1313: this is the GK107M right
20:56 Lyude: erm, GLM107... what is your model number? nvidia's models are confusing
20:56 Elv1313: karolherbst: no such file or directory
20:56 karolherbst: Elv1313: I guess you have no debugfs?
20:56 Lyude: btw
20:56 Lyude: karolherbst: this is gentoo, so expect the required kernel parameters for things to work to possibly have gotten disabled
20:57 karolherbst: Elv1313: also a lot depends on the CPU freq thing you use as well
20:57 karolherbst: you kind of want performance governor + intel_pstate
20:57 Elv1313: karolherbst: https://pastebin.com/fa8xL0s1
20:58 Elv1313: Lyude: I am on gentoo, but it is my own kernel I just git-cloned from kernel.org
20:59 Lyude: i mean in terms of kernel cofiguration
20:59 Lyude: *configuration
20:59 karolherbst: Elv1313: /sys/bus/pci/devices/0000\:01\:00.0/power/runtime_status
20:59 Elv1313: my own .config
20:59 Elv1313: karolherbst: active
21:00 karolherbst: Elv1313: /sys/bus/pci/devices/0000\:01\:00.0/power/runtime_suspended_time is 0?
21:00 Elv1313: karolherbst: yes
21:00 karolherbst: mhh
21:00 karolherbst: so _something_ prevents the GPU from sleeping or it doesn't sleep at all
21:00 karolherbst: but
21:00 karolherbst: I think you just missed stuff to enable in the kernel
21:01 karolherbst: wait a minute
21:01 Elv1313: karolherbst: do you want the .config?
21:01 karolherbst: no
21:01 karolherbst: it isn't that much
21:01 karolherbst: Elv1313: CONFIG_VGA_SWITCHEROO has to be enabled
21:02 Lyude: btw Elv1313, just curious: where did you learn about nomodeset from?
21:02 Elv1313: Lyude: I am old
21:02 karolherbst: Elv1313: CONFIG_PM as well, but I suspect you already have this enabled
21:04 Elv1313: karolherbst: I will reboot again CONFIG_VGA_SWITCHEROO, until 15 minutes ago `nouveau` wasn't part of my kernel, so it wasn't enabled
21:04 karolherbst: Elv1313: regarding CPUFreq governor, don't use ondemand or conservative or powersave
21:04 karolherbst: I've heard good things about schedutil, but never tried it
21:05 Elv1313: karolherbst: last time I tried, powersave still won by a narrow margin against p_state
21:05 karolherbst: well if you messure one data point yes
21:05 karolherbst: but avg is better with performance
21:05 karolherbst: because you let the CPU sleep more when you have load
21:06 karolherbst: instead of keeping the CPU awake 100% and have some low freq, you have it awake less and burst the freq
21:06 karolherbst: which ends up saving more power
21:06 karolherbst: or in theory it should
21:06 karolherbst: it is kind of hard to meassure in the end
21:06 Elv1313: I use powersave and a while true; do if "$(load | grep ...)" -gt ...; then performance; else; powersave;fi
21:07 karolherbst: yeah... maybe that helps overall
21:07 karolherbst: but I think you won't need it with schedutil
21:07 Elv1313:rebooting
21:08 Lyude: jfyi https://patchwork.freedesktop.org/patch/235976/
21:08 karolherbst: Lyude: "Any video related functionality will be disabled and emulated by software where possible"
21:08 Lyude: aaah, i like that message more
21:09 Lyude: i'm also stuck between whether we should have it in vgacon.c or have it as part of drm's initialization so warnings don't come up if there's no graphics drivers to be loaded
21:09 karolherbst: maybe even "only emuldated by..."
21:09 karolherbst: *emulated
21:09 Elv1313:back
21:10 Elv1313: /sys/bus/pci/devices/0000\:01\:00.0/power/runtime_suspended_time is now 82817
21:10 karolherbst: ahh
21:10 karolherbst: Elv1313: remember that things like lspci maybe wkae up the GPU as well
21:10 karolherbst: or software checking devices or whatever
21:10 karolherbst: but this value being not 0 is a step forward :)
21:11 karolherbst: and it takes roughly 5 seconds for the GPU to be turned off again
21:11 karolherbst: Elv1313: what do you use to get the power consumption? it might wake up the GPU for a moment, so you need to keep that in mind
21:13 Elv1313: karolherbst: /sys/bus/pci/devices/0000\:01\:00.0/power/runtime_status is now suspended, but the number of watts is atill around 20
21:13 karolherbst: Elv1313: did you read this? "what do you use to get the power consumption? it might wake up the GPU for a moment, so you need to keep that in mind"
21:14 karolherbst: also maybe it is some avg value and the GPU was on seconds ago
21:14 Elv1313: karolherbst: https://gist.github.com/Elv13/615727373bbf80ad2971a3b9082ada8a
21:14 karolherbst: but if it stays around 15-20W, then something is odd indeed
21:15 Elv1313: karolherbst: better than 35w, but still, yes, it should hover around 10w with wifi
21:15 Elv1313: that's what I get with v4.4
21:15 karolherbst: Elv1313: there is also software like laptops-mode-utils or tlp to do stuff like, but if you like to do it yourself, you are free to write scripts ;)
21:15 karolherbst: mhhh
21:15 karolherbst: Elv1313: do you have lm_sensors installed?
21:15 karolherbst: sensors might give you some meaningful output
21:16 Elv1313: karolherbst: I tried those utils, never really had good result with them, I may need to try them again now that the laptop is 3 years old
21:16 karolherbst: Elv1313: yeah I know, I disable most of the stuff those tools do, but for the basic things they are quite useful
21:16 karolherbst: and less painful than checking what one can do
21:16 Elv1313: karolherbst: https://gist.github.com/Elv13/c4b93c629c332cba9eef32cdb87146c2
21:17 karolherbst: Elv1313: mhh okay, at least for the kernel the nvidia GPU seems to be off
21:17 karolherbst: sadly no power sensor on that one
21:17 Elv1313: I guess some of the watts are the fan and it's over 30C here, but I think they should not be running
21:17 Elv1313: what's the kernel module for that sensor? I think I enabled them all, but I may need to check again
21:17 karolherbst: nouveau
21:18 Elv1313:running sensors-detect
21:18 karolherbst: low/mid range nvidia GPUs don't have power sensors
21:18 karolherbst: usually
21:18 karolherbst: and only high ends have those
21:18 karolherbst: or mid-high end
21:18 karolherbst: there are other means to get the power consumption, but then we would have to calculate stuff and nobody really got to it
21:19 karolherbst: anyway, if there is a sensor on the nvidia GPU, nouveau detects this and reports the power consumption
21:19 karolherbst: if not, then there is none
21:20 karolherbst: Elv1313: do you have a /sys/kernel/debug/vgaswitcheroo/switch file now?
21:20 Elv1313: right, sensors-detect found nothing new
21:20 Elv1313: 0:IGD:+:Pwr:0000:00:02.0
21:20 Elv1313: 1:DIS: :DynOff:0000:01:00.0
21:20 karolherbst: Elv1313: otherwise you could check if you get a different power consumption if the GPU is enabled or disabled
21:23 karolherbst: Elv1313: in the worst case you can use nouveau.config=NvPmEnableGating=1
21:23 karolherbst: Lyude: there are no different levels anymore?
21:23 Lyude: karolherbst: no, mupuf suggested they be removed (and they are right)
21:23 karolherbst: Elv1313: this should save a few W as long as the nvidia gpu is turned on, so maybe a good idea to enable it anyway
21:23 Lyude: the different levels are still enabled, you just can't control them from the kernel cmdline
21:23 Lyude: it's either on or off
21:23 karolherbst: and maybe it helps even if the GPU is off, because on older hardware the GPU stays on a little
21:24 karolherbst: Lyude: okay
21:24 Elv1313:enabled
21:24 Elv1313: is there a /proc/ or /sys for it so I don't need to reboot?
21:24 karolherbst: not for this one
21:24 karolherbst: sadly
21:29 Elv1313: Umm, there is some changes in the "new" kernel (I am jumping from 4.4, I just found that the fingerprint reader ACPI changed, it is now 17w with updated "unbind"
21:30 Elv1313: Maybe the other extra watts are other aspects like that, I will need to try a bunch of things again. My old ACPI script may be outdated when it comes to the "best practices" on recent kernel. I will try pstate again. Thanks for your help eveybody
21:31 Elv1313: 4.16 didn't work, but 4.18-rc3 does, so: progress!
21:42 karolherbst: Elv1313: yeah... the main reason I prefer to use tlp/laptop-mode-tools :) I am sure I can be better, but I also want to do other things instead
21:43 Elv1313: karolherbst: The 4.18 has a brand new kernel power capping subsystem, that's cutting edge stuff, I am currently reading the doc about it, will see what happen
21:45 karolherbst: Elv1313: nice :)
21:45 Elv1313:rebooting
21:58 Elv1313: For the record, it isn't a good idea to enable that thing. The fan now spins 1k RPM faster and the idle CPU temp is 6C higher with the thermal capping than without
21:58 Elv1313: but as far as nouveau goes, it seems to work
22:44 Lyude: has anyone hit this with 4.18rc3?
22:44 Lyude: https://paste.fedoraproject.org/paste/exuOCJ61RXr1GUiUJSQZCA
22:44 Lyude: just happened on this P50
22:45 airlied: one for skeggsb I suspect
22:45 Lyude:will bisect unless someone knows of a pre-existing fix
22:45 skeggsb: Lyude: *how* did you hit it?
22:46 Lyude: skeggsb: booting the machine and trying to go into a gui with nouveau.atomic=1... i also just realized I still have nouveau.atomic=1 and should try disabling that first
22:47 skeggsb: ah, yeah, that hasn't ever been tested with a userspace atomic client, just against what the drm turns the legacy ioctls into - hence why it's disabled :)
22:47 skeggsb: well, hasn't properly been tested
22:47 Lyude: ah
22:47 skeggsb: a "drm.debug=0x14 nouveau.debug=disp=trace,bios=trace" would be useful in figuring out what went wrong though ;)
22:48 skeggsb: assuming it is because of atomic
22:48 Lyude: skeggsb: btw, I mentioned to karolherbst since they've been wanting to work on CI stuff for nouveau: while I would like to work on modesetting stuff with nouveau once I'm finished fixing bugs for work stuff, I might help get igt running with nouveau first
22:48 Lyude: skeggsb: sure thing
22:48 skeggsb: igt running would be awesome
22:49 Lyude: yeah, I had actually thought that igt ran fine on everything else until i discovered the other day nothing even seems to have gem ioctls implemented in igt
22:49 nyef: "it goes there"? (-:
22:52 pendingchaos: HdkR: "cbank"?
22:52 airlied: Lyude: the gem tests are pretty much i915 specific anyways
22:53 airlied: Lyude: you mostly just want the kms_* tests
22:53 karolherbst: skeggsb: btw, 3 tests left until we pass all public 4.5 CTS tests :) I kind of try to push for the remaining ones, but those are super super annoying :(
22:53 HdkR: pendingchaos: Const buffer
22:53 Lyude: airlied: it's more so we can create non-dumb fbos for the kms_* tests
22:53 airlied: Lyude: do dumb fbos not work enough?
22:54 karolherbst: pendingchaos: if you want to work on implementing more extensions, you can always check out all the NotSupported entries within the CTS: https://trello.com/c/yyJqtjrd/25-cts-master-461x-khronos-mustpass-gl45-master-status
22:54 Lyude: there is some strangeness with them I need to fix, some of it doesn't actually require non-dumb bos
22:54 Lyude: i guess if we don't actually need to test gem that much I could probably skip that
22:54 airlied: though I suppose you want tiling in some tests but then you are into gpu specifc testing
22:55 karolherbst: ARB_parallel_shader_compile is a fun exteions
22:55 karolherbst: *extension
22:55 pendingchaos:nods
22:55 Lyude: airlied: i mean, if GPU specific testing just means "we have to specify tiling options that are specific to this driver" that doesn't sound terrible to implement
22:55 HdkR: That extension is a bunch of nonsense
22:55 karolherbst: it doesn't really _add_ anything
22:55 HdkR: The driver can literally noop it
22:55 karolherbst: yes
22:56 HdkR: Which the Nvidia blob did for a long time
22:57 pendingchaos: HdkR: doesn't LoadPropagation do that (doing things like mov r0 c[0]; add r0 r0 5 -> add r0 c[0] 5)?
22:57 HdkR: pendingchaos: Potentially. It's definitely a pass that I would expect it to end up in
22:58 karolherbst: pendingchaos: RA is sometimes a little silly
22:59 karolherbst: say you have st b128 $r1 $r2 $r3 $r4, RA might turn this into mov $r0 $r1; mov $r1 $r2; mov $r2 $r3; mov $r3 $r4, st b128 $r0q
22:59 karolherbst: for cx[] it is a different story
23:00 karolherbst: but some ops can't read directly from c[]
23:00 airlied: Lyude: no it's not terrrible, just the fun of making it actually test interesting things on different hw
23:00 Lyude: i'm down for that!
23:00 karolherbst: and sometimes there are constraints like only the second src
23:00 airlied: karolherbst: some of those not supported don't seem like missing extensions
23:00 airlied: like shader_image_size
23:00 karolherbst: airlied: yeah, that is MS support for images
23:00 karolherbst: which we don't support on maxwell+
23:01 karolherbst: because uhm, we have to do that in software
23:01 karolherbst: or so
23:01 airlied: karolherbst: ah ms images are a pain everywhere
23:01 karolherbst: imirkin knows more, but I think it was something like that
23:01 karolherbst: airlied: well, on kepler we support it
23:02 karolherbst: uhm, we actually pass that "KHR-GL45.packed_pixels.varied_rectangle.rg16i" test
23:02 karolherbst: it is just one of those which sometimes fail for no apperant reason
23:03 karolherbst: "KHR-GL45.packed_depth_stencil.blit.depth32f_stencil8" we fail because of MS resolving when doing getPixels
23:03 karolherbst: and "KHR-GL45.shader_image_load_store.non-layered_binding" we fail due to poor implemented 3d images
23:03 Lyude: oh, that's interesting... that kernel panic I mentioned a moment ago isn't from atomic
23:04 skeggsb: it's not a panic, it's a warning that a timeout happened
23:04 skeggsb: [ 14.859653] nouveau 0000:01:00.0: DRM: core notifier timeout
23:04 skeggsb: and whatever caused that is the cause of the timeout too
23:04 Lyude: ah right, forgot I have my kernel set to panic on warnings like that
23:05 Lyude: oh, no, there's a panic but it must happen right after that
23:09 Lyude: skeggsb: https://paste.fedoraproject.org/paste/fVCmJUpSxIXNobsmB3F9Ow
23:11 Lyude: it might be a race condition, as I have trouble reproducing it unless nouveau is autoloaded at boot
23:13 Lyude: i think i see the issue
23:34 nyef: Hrm. I can't iterate the drm_connectors for a device, convert to nouveau_connector(), then check ->type == DCB_CONNECTOR_eDP and existence of ->detected_encoder to find active eDP panels? Or am I even more lost than I thought?
23:35 nyef: More lost than I thought.
23:42 nyef:removes all of the conditional noise.
23:46 Lyude: skeggsb: are nvkm_outp objects created/destroyed whenever an mst connector is created or destroyed?
23:46 skeggsb: no, mst stuff is completely unknown at that level
23:47 Lyude: it seems the problem is stemming from here: [ 14.800624] Lyude:nvkm_dp_acquire:436: (dp->outp.ior) == (null)
23:47 Lyude: what exactly is an ior?
23:48 skeggsb: in this case, it's just an OR (Output Resource), a SOR (Serial ...) specifically that handles DP/TMDS/LVDS encoding
23:49 skeggsb: they can be dynamically assigned as needed on gm20x and up, fixed mappings on earlier HW
23:49 Lyude: also, https://paste.fedoraproject.org/paste/RvoUd9RBTYApT8y1DQ5VOA
23:52 Lyude: gonna take a wild guess and say we're not holding the drm connector lock
23:52 skeggsb: hmm, interesting, not sending a base channel update, and core is interlocked with it, which is why it's hanging
23:54 Lyude: I'm assuming channel = evo channel, but what do you mean by update?
23:55 skeggsb: there's an UPDATE method which you send to make changes take effect
23:55 skeggsb: a "go bit" as it were
23:55 skeggsb: we're not sending it for some reason on one of the channels involved
23:56 Lyude: oooh, so you actually build up changes you want to make to the display state in the evo channel then commit them?
23:56 skeggsb: yeah
23:56 skeggsb: display is like graphics in that stuff is submitted in a ring buffer
23:56 Lyude: i guess that explains why there doesn't seem to be any drm locking anywhere in nouveau, i'm assuming the evo streams have their own form of mutexes as well?
23:57 skeggsb: we take a mutex for the core channel, and the atomic plane locking should protect the other ones
23:57 Lyude: huh, anyway sorry-off topic :P