08:12 karolherbst: imirkin: there are like 5 gtf fails and they may be the same issue in the end
08:12 karolherbst: okay, two issues
08:13 karolherbst: and the fp64 stuff could be upstreamed though
08:15 karolherbst: imirkin: and I cleaned up that codegen patch and should look totally fine now: https://github.com/karolherbst/mesa/commit/eb45e3c64e2f5239db7790d6c6efc1f28b599dd2
08:18 karolherbst: and this should be the most questionable patch as well
08:18 karolherbst: but yeah, I doubt we will make it for 17.3, but 17.4/18.0 should be quite doable
11:02 aphirst: Hi there! I'm setting up a "new" thinkpad T430 with nvidia graphics, and have just gotten dual-head working with PRIME (intel + nouveau).
11:02 aphirst: I'm connected via the DP port on the docking station. However, I don't seem to have any audio outputs.
11:03 aphirst: https://nouveau.freedesktop.org/wiki/FeatureMatrix/ HDMI Audio seems to work for a lot of models but I can't quite work out which category my card is
11:04 aphirst: ah OK, GF108M (NVS 5400m) seems to be NVC0 family, where it says that HDMI Audio works
11:04 aphirst: How might I best go about diagnosing this?
11:07 gnarface: aphirst: that's optimus hardware? i think last time i was trying to help someone debug the problem, it turned out that the HDMI Audio output passthrough card is the *intel* one not the nvidia one
11:07 aphirst: gnarface, pretty sure it is optimus hardware
11:08 aphirst: i initially set up the proprietary driver with bumblebee and primusrun/optirun worked as expected; but i switched to nouveau since it seemed impossible to set up multimonitor in the way i expected
11:08 aphirst: i have since taken off the nvidia driver and bumblebee (and checked to see there are no remnants in modprobe.d, xorg.conf.d etc
11:08 aphirst: )
11:09 gnarface: i think it turns out to be alsa configuration actually that you want to mess with here
11:09 gnarface: not sure bumblebee has any effect on the hdmi audio passthrough feature
11:09 gnarface: though i'm not actually sure and i don't have similar hardware here to test with unfortunately, sorry :(
11:10 aphirst: still alsa even though I'm wanting to use pulseaudio?
11:10 gnarface: yea, the nvidia proprietary driver sucks at xrandr
11:10 aphirst: i suppose alsa is still ther underneath
11:10 gnarface: oh, if you have pulseaudio installed, it could need to be reconfigured too
11:11 gnarface: i'm not actually sure if it's easier or harder to use it in this case
11:11 aphirst: hmm
11:11 gnarface: but i can't help you much with pulseaudio either
11:11 aphirst: well i didn't really do any config to either manually
11:11 gnarface: check the configs maybe?
11:11 aphirst: i foolishly expected things to "just work" as they did with an intel-only T430
11:11 gnarface: maybe just knowing the HDMI Audio may be coming from the Intel video card's output instead could be the clue to make sense of the pulseaudio interface to fix it, i dunno?
11:12 gnarface: sorry, i would have warned you that optimus hardware is crippled badly on linux :(
11:12 aphirst: is it a bad sign that lspci | grep Audio only shows the intel entry
11:12 aphirst: (also, lspci causes microlag)
11:15 aphirst: tbh regarding alsa and pulseaudio i'm not sure what i'm even looking fore
11:17 gnarface: well i can help a little with alsa and none with pulseaudio
11:17 gnarface: both of them have their own irc channels though
11:17 gnarface: you can't be the first person who has run into this
11:17 gnarface: someone in there will know a workaround
11:18 aphirst: where first, alsa or pulseaudio :P
11:18 gnarface: in general you'll want to disable pulseaudio while debugging alsa
11:19 gnarface: if you are determined to keep pulseaudio, you may not actually have to deal with alsa at all
11:19 gnarface: at least that's the idea
11:19 gnarface: (it doesn't always work out that way though)
11:21 aphirst: hmm, i would have hoped that here was the right place to ask
11:23 gnarface: well someone in here has probably seen the issue too but odds are more slim you're gonna run into them online and awake and paying attention
11:24 aphirst: true
11:24 aphirst: on the t430 with just the intel chip, it all "just worked" :P
11:24 gnarface: look at the output of aplay -L and aplay -l
11:24 aphirst: only show an intel card
11:24 gnarface: right, but the number of the HDMI one is in there
11:24 gnarface: you need to know it to fix this
11:25 aphirst: no it isn't
11:25 aphirst: :P
11:25 aphirst: i'm looking at it right now
11:25 gnarface: oh, it isn't?
11:25 gnarface: hmmm
11:25 gnarface: something else could be wrong too
11:25 gnarface: the t430 "just worked" because it only had one video and one audio device and alsa and pulseaudio in that case will default to the first one which, being the only one, is generally the right choice
11:26 gnarface: see, if you're using optimus hardware and it's assuming your default hdmi output is also the default video card, and you then *switch* that, it's not gonna find it
11:26 gnarface: however
11:26 gnarface: it's also possible you could be missing all kinds of other things too
11:26 gnarface: like driver support or even kernel support
11:26 gnarface: are you on Gentoo?
11:27 gnarface: or did you compile your own kernel?
11:27 gnarface: it's possible for you to sabotage yourself with regards to the HDMI audio passthrough by missing just one kernel compilation option
11:28 aphirst: I'm on arch
11:28 aphirst: i did this install yesterday and barely touched any default configs
11:28 aphirst: i asked there but as usual got swamped by other easier questions
11:29 aphirst: i can see someone called "damex" discussed something similar in the past
11:29 aphirst: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2016-02-19
11:30 gnarface: hmm. interesting
11:31 gnarface: it's worth noting that i don't actually work on nouveau, nor do i know for sure the hdmi passthrough will even work without the nvidia proprietary firmware
11:31 gnarface: or if it's supported by nouveau at all
11:31 gnarface: i assumed it by the context of the discussion, but it's worth verifying
11:31 aphirst: i did post earlier a link to a feature support matrix
11:31 aphirst: where HDMI audio is claimed to work for my chipset family
11:31 gnarface: as is that thing he mentions about the thinkpad option to the soundcard module
11:33 gnarface: just so we're clear here, you do know that aplay -L is different output from aplay -l right?
11:34 aphirst: I do
11:35 gnarface: and you've also checked the pulseaudio mixer, pavucontrol i think it's called?
11:35 aphirst: aplay -l just listed the intel card, aplay -L gave a whole load of output modes but all were for the intel card
11:35 gnarface: yea, i'm expecting they're all for the intel card
11:35 aphirst: yes, pavucontrol is how i know there's no hdmi audio output in the first place
11:35 gnarface: but what i'm also expecting is aplay -L should have one called 'hdmi'
11:36 gnarface: could be called something else maybe like spdif
11:37 aphirst: sure, I'd expect that too
11:37 aphirst: but rest assured, the only stuff was intel related
11:37 aphirst: well, adding the thinkpad vendor module option didn't help
11:38 gnarface: wait
11:38 gnarface: so there wasn't even an hdmi entry listed on the intel card in the output of aplay -L?
11:39 gnarface: again, i want to emphasize that we have no reason to assume the hdmi would be coming from the nvidia card
11:39 aphirst: xrandr --listproviders shows that the nvidia card is powering the dp/hdmi port
11:40 gnarface: https://askubuntu.com/questions/641172/does-not-detect-my-sound-card-hdmi/660910#660910
11:40 gnarface: this one looks potentially relevant
11:41 aphirst: i was just looking at something recommending the same command
11:41 aphirst: (sudo) lspci -H1 does NOT show an NVIDIA Audio device
11:42 karolherbst: aphirst: there is a workaround for getting the audio device
11:42 karolherbst: aphirst: do you have envytools installed or setpci?
11:42 aphirst: no but I can install one or the other
11:43 aphirst: setpci is there
11:43 karolherbst: okay, let me get the command to get the audio device
11:44 karolherbst: aphirst: https://devtalk.nvidia.com/default/topic/1024022/linux/gtx-1060-no-audio-over-hdmi-only-hda-intel-detected-azalia/post/5211273/#5211273
11:44 aphirst: karolherbst, i guess you've encountered this issue before
11:44 karolherbst: but except doing modprobe nvidia, you modprobe nouveau
11:44 karolherbst: well
11:44 karolherbst: I have the same issue, but none of my ports are connected to the nvidia card, but intel
11:44 aphirst: this command needs to occur before X starts?
11:44 karolherbst: so for me it doesn't amtter
11:44 karolherbst: aphirst: before nouveau gets loaded
11:44 aphirst: hmm, how will be best to do that
11:45 karolherbst: write a service which your login manager depends on or something
11:45 karolherbst: and blacklist nouveau
11:45 aphirst: also, the thread talks about 'newer'/'recent' laptops but ths T430 isn't that new
11:45 karolherbst: maybe Lekensteyn or I will work on a proper fix for this, but it ain't that simple
11:46 karolherbst: aphirst: doesn't matter
11:46 karolherbst: aphirst: what's the GPU?
11:46 karolherbst: I have a 770M with the same problem
11:47 aphirst: GF108M (NVS 5400m) NVC0 family
11:47 karolherbst: so one generation before mine
11:47 aphirst: ok, i stopped lightdm, dropped to a TTY, ran those commands (nouveau instead of nvidia)
11:47 aphirst: kernel oops
11:47 karolherbst: meh :/
11:47 karolherbst: I wouldn't do that xinit stuff as well though
11:48 aphirst: yeah i removed that too
11:48 aphirst: ok, other TTY worked
11:48 karolherbst: does lspci show the audio device?
11:48 aphirst: no, it shows complaints at the top
11:48 aphirst: pcilib: cannot open /sys/bus/devices/0000:01:00.0/config
11:49 karolherbst: uhm
11:49 aphirst: lspci: Unable to read the standard configuration space header of device 0000:01:00.0
11:49 karolherbst: okay
11:49 karolherbst: do this
11:49 karolherbst: echo 1 > /sys/bus/pci/rescan
11:49 aphirst: with X down?
11:49 karolherbst: doesn't amtter
11:49 karolherbst: or was it /sys/bus/pci/devices/rescan
11:49 karolherbst: ... one of the two
11:50 aphirst: well, i did the echo
11:50 aphirst: that TTY is now hung too
11:50 karolherbst: it might be, that it works differently on nvc0 gpus
11:50 karolherbst: :(
11:50 aphirst: yeah i guess
11:50 karolherbst: aphirst: could you install envytools? then it is easier to debug
11:51 aphirst: i will reboot then install that
11:51 aphirst: brb, hot mug of tea waiting for me
11:55 karolherbst: aphirst: you have to wait for me now, because I have to drive home on short notice and don't really know when I will be available again, but we can debug it for sure in like 3-4 hours
11:55 karolherbst: maybe earlier
11:59 aphirst: shame
12:05 gnarface: install envytools and start reading how to query basic info with them, is my advice, aphirst
12:05 gnarface: he'll be back
12:05 aphirst: i was already looking at what binaries envytools installed
12:06 aphirst: https://envytools.readthedocs.io/en/latest/hw/nv1-paudio.html
12:06 aphirst: >todo: write me
12:06 aphirst: oh dear
12:06 gnarface: yikes
12:07 aphirst: up shit creek without a paddle, i think
12:08 gnarface: how's opengl run on that thing with nouveau?
12:08 gnarface: you using the latest kernel&mesa?
12:08 aphirst: using the latest in the arch repo
12:08 aphirst: not really tested opengl tbh, i did some mesa-demos tests
12:09 gnarface: ioquake3 is a good test
12:10 gnarface: it's in the debian repos
12:10 gnarface: probably arch too
12:11 gnarface: you can get teamfortress 2 for free on steam also
12:11 aphirst: i'll do ioquake
12:11 aphirst: the variable is DRI_PRIME=1 right?
12:11 gnarface: i'd be curious to know how whether hardware h264 decoding works on it with the steam in-home streaming feature as well, actually
12:12 aphirst: well for a lot of that stuff i expect i'll just use the stuff in the intel card
12:12 gnarface: i don't know but DRI_PRIME=1 looks familiar, so probably
12:12 aphirst: it does h264 decoding just fine
12:12 aphirst: at least its brother in the other T430 and X230 does
12:12 aphirst: even h264 encoding
12:12 aphirst: everyone cringes when i mention that but it does /work/ so whatever
12:13 gnarface: well the question i have for streaming with steam is specific, because while h264 decoding almost always works it sometimes falls back on software decoding actually
12:13 gnarface: which is usually not noticeable for just video watching, but is actually a latency liability for gaming
12:14 gnarface: (you end up with huge latency spikes when the scene gets complex)
12:14 gnarface: gets much worse at higher resolutions
12:14 aphirst: in the meantime I should make a bbs.archlinux.org thread
12:15 aphirst: lel, ioquake3 failed to build
12:15 gnarface: ouch
12:16 aphirst: will try ioquake3-git
12:24 aphirst: hmm, using the demo file, seems to crash when opening
12:24 aphirst: too many things at once to be sure what's wrong there
12:24 gnarface: pastebin the log i might know
12:25 aphirst: imma try 0ad in the mean time
12:25 aphirst: will do
12:25 gnarface: just the last few lines where it fails probably
12:25 gnarface: also check this: glxinfo |grep dire -i
12:26 gnarface: and this: glxinfo |grep opengl -i
12:26 aphirst: with and without DRI_PRIME=1 i get direct rendering Yes and a load of opengl info
12:27 aphirst: 0ad works fine in 3d
12:27 gnarface: more explicitly for the first one: glxinfo |grep direct.rendering -i
12:28 gnarface: just looking for "Yes" here
12:28 gnarface: the other one is so you can check what opengl version it sees
12:28 gnarface: affects game compatibility
12:28 aphirst: ok, both get 3.0 Mesa 17.2.2
12:29 aphirst: for shading language, intel gets OpenGL ES GLSL ES 3.10
12:29 aphirst: nouveau the same but "3.00" at the end
12:29 aphirst: sorry, forgot about the "core profile version string"
12:29 aphirst: nouveau gets 4.3, intel gets 4.2
12:29 gnarface: should be fine
12:30 gnarface: maybe it's just a problem with the path to your data files
12:31 gnarface: i think it should be in ~/.q3a/baseq3/games.log
12:31 gnarface: or mabye ~/.q3a/demoq3/games.log or something like that
12:31 gnarface: i'm not sure if the demo path is different
12:31 gnarface: did 0ad work?
12:32 imirkin: aphirst: there's a lot of scrollback that i don't feel like reading... are you still having issues, and if so, what are they?
12:32 aphirst: gnarface, 0ad worked fine, quake3 log when using intel https://ptpb.pw/2xgN.log
12:32 aphirst: imirkin, hi! basically i'm using a thinkpad t430 with intel+nvidia graphics, tried and failed using the prop. driver to get mulithead, got it working with nouveau (uninstalling all the prop. stuff) but don't seem to have HDMI audio
12:32 aphirst: not even in lspci
12:33 imirkin: try booting with the hdmi cable plugged in
12:33 aphirst: i'm connected to a monitor via the DP port on my thinkpad docking station which connects to the HDMI in of a monitor/tv
12:33 imirkin: oh
12:33 aphirst: imirkin, it has never been removed and i rebooted several times
12:33 imirkin: pastebin `lspci -nn -d 10de:`
12:34 aphirst: just the one output line:
12:34 aphirst: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108M [NVS 5400M] [10de:0def] (rev a1)
12:34 imirkin: srsly?
12:34 aphirst: why would I lie?
12:34 imirkin: i'm more disappointed in the universe than suspecting you of lying
12:34 aphirst: fair
12:34 aphirst: just to triple check, my BIOS setting should still be set to Optimus instead of just one of the cards, yes?
12:34 imirkin: ok, so you need to enable the audio subfunction
12:35 aphirst: I can go digging in my BIOS if you need?
12:35 imirkin: there should be a 01:00.1 audio device
12:35 imirkin: have a look at ...
12:35 aphirst: this is a mostly clean arch install; while i can't rule out remnant dumb config from my trying bumblebee+nvidia, I did uninstall those, and did basically no nonstandard config
12:36 hermier: aphirst: seems you have mixed version of engine and game for quake 3
12:36 aphirst: hermier, possibly, I just did a cursory search for the relevant quake3 demo files
12:36 imirkin: aphirst: https://devtalk.nvidia.com/default/topic/1024022/linux/gtx-1060-no-audio-over-hdmi-only-hda-intel-detected-azalia/post/5211273/#5211273
12:37 gnarface: aphirst: about your ioquake3 log, uh... this doesn't look good: ERROR: User Interface is version 3, expected 6
12:37 imirkin: same basic thing should apply to your situation, i suspect
12:37 aphirst: imirkin, i think it was gnarface who mentioned that thread first
12:37 hermier: ERROR: User Interface is version 3, expected 6 <= this as nothing to do with GL problems
12:37 gnarface: aphirst: dunno though if that's hte actual problem. i also noticed this, it seems to be using the Intel card not nouveau: GL_RENDERER: Mesa DRI Intel(R) Ivybridge Mobile
12:37 aphirst: gnarface, if that was regarding ioquake, i didn't post a log of when I ran quake3 with the DRI_PRIME variable set
12:38 aphirst: but this is a side issue which frankly isn't very important
12:38 imirkin: skeggsb: looks like airlied already added code to poke 0x88488 on pm runtime resume. i guess we should be doing it on init too and triggering a pci rescan of some sort?
12:38 aphirst: imirkin, when i tried commands from that thread (modifying them to replace reference to nvidia with nouveau)
12:38 aphirst: it didn't exactly work
12:38 aphirst: lspci after restarting x showed: "pcilib: cannot open /sys/bus/devices/0000:01:00.0/config" and "lspci: Unable to read the standard configuration space header of device 0000:01:00.0"
12:39 aphirst: (copied from above)
12:39 aphirst: if the commands had to be adapted to be system specific, i didn't do that, and wasn' looking forward to interpreting lspci's topology output
12:40 aphirst: i wonder whether all the linux T430 users just got the intel-only models; and all the optimus T430 models are owned by windows users
12:40 aphirst: or people who just set the nvidia card as the main one using the prop. driver
12:40 aphirst: or never use external video :P
12:41 aphirst: and there was me hoping to have this machine set up by lunchtime
12:44 aphirst: i wonder whether it's work trying some other distro's livecd
12:44 aphirst: just to see what it does
12:45 aphirst: because if it did work, it would mean i broke something somehow
12:50 gnarface: ooh ooh, devuan livecd!
12:54 aphirst: oh god this usb disk is slow
12:54 gnarface: that's normal
12:55 aphirst: i should get some usb3 ones
12:55 gnarface: it won't matter
12:55 gnarface: the bottleneck is the flash itself
12:56 aphirst: hmm i guess write is the issue
12:56 gnarface: yea, on the newer stuff, burst read rates are decent
12:56 gnarface: if you really need write speed you would need to go to something like a solid state drive
12:57 aphirst: but yeah, imirkin, is there anything i can do from here?
13:13 imirkin: aphirst: i think that runtime pm is interfering with this
13:13 imirkin: hm
13:13 aphirst: not sure whether you saw in the scrollback
13:13 imirkin: oh hm, that wouldn't happen
13:14 aphirst: i linked this discussion from a while ago https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2016-02-19
13:14 aphirst: karolherbst and someone called "damex" spoke about a similar issue
13:14 imirkin: did you rescan the right device?
13:14 imirkin: it's not the same device you remove
13:14 aphirst: imirkin, good question, not sure :P
13:14 imirkin: i think there's also a way to trigger pci hotplug
13:14 imirkin: but i don't know what it is
13:15 imirkin: i think this is a question for linux-pci -- i.e. what is it we're supposed to do
13:15 imirkin: writing that bit is easy enough
13:15 imirkin: but then we have to cause linux to notice the device
13:15 aphirst: removed was 0000:01:00.0
13:15 aphirst: rescanned was 0000:00:01.0
13:15 imirkin: hm, that's probably right
13:15 aphirst: i can try it again if you really want, i have a script which i can run after killing lightdm
13:15 imirkin: no
13:16 aphirst: i'm just brainstorming other things i know i set up
13:16 aphirst: i'm going to disable TLP and see what a reboot does
13:17 aphirst: ..oh, seems i never enabled it
13:17 aphirst: forget that then
13:18 aphirst: if there's to be a formal bug report or something, feel free to get me to make a set of logs or something
13:19 aphirst: but it looks like i'm waiting for karolherbst to come back in any case
13:19 gnarface: isn't there some non-free thinkpad firmware package?
13:19 gnarface: maybe this functionality is missing without that?
13:19 aphirst: there is?
13:19 aphirst: not to my knowledge
13:20 gnarface: maybe i'm wrong
13:20 gnarface: i know there's thinkpad-specific kernel modules for the older ones though, at least
13:20 gnarface: or at least compile-time optinos
13:20 aphirst: tp_smapi and so on
13:20 gnarface: i don't know if they're actually modules
13:20 aphirst: options idk
13:24 aphirst: for the record, if i poke in my bios and enable only the nvidia card, I do get the HDMI audio
13:24 aphirst: the setting is "Integrated", "Discrete", and "Optimus"
13:25 gnarface: lucky to have that option
13:25 gnarface: i'd personally probably just switch it to the nvidia card and disable the intel one
13:26 gnarface: if that was an option
13:26 aphirst: I mean I might have to stick to that for now
13:26 gnarface: i don't know, but the thinkpad-specific kernel stuff may be important for power management
13:26 aphirst: though let's not jump the gun
13:26 aphirst: I'll actually test it properly first
13:26 gnarface: so if he thinks this could be powermanagement related...
13:26 aphirst: gnarface, sure but unless i know what package it's supposed to be i can hardly test it, can I
13:27 aphirst: or know what specific functions it has so that i can work out what package it is
13:27 gnarface: also, you should check for that guy's handle in the alsa channel log too
13:27 gnarface: maybe he got his answer eventually
13:27 gnarface: from there or pulseaudio actually
13:27 aphirst: alsa channel log?
13:27 aphirst: oh right
13:28 gnarface: while we're on double-checking everything, probably worth mentioning that differences in behavior could be bios version related too. maybe this isn't working for you when it worked for others due to having an older bios? it's just a shot in the dark, but it's happened to me more than once
13:29 aphirst: well I'm running the most recent lenovo bios
13:29 gnarface: oh, nevermind then
13:29 aphirst: i know this because i updated it the day before yesterday
13:29 gnarface: ah, good
13:29 gnarface: just making sure
13:29 aphirst: so yeah with the first BIOS setting to "discrete" i get the nvidia and intel audio in lspci
13:29 aphirst: rebooting now to check the other bios options
13:30 aphirst: OK so in Config / Display, there's Boot Display Device (which sets the monitor for the BIOS stuff)
13:31 aphirst: there's also "Graphics Device" (Integrated, Discrete and NVIDIA Optimus)
13:31 aphirst: and then tere's "OS Detection for NVidia Optimus" (Disabled, Enabled) defaults to Disabled
13:32 aphirst: setting that one to Enabled just seems to break everything
13:33 aphirst: this is definitely going to have to be a thread somewhere, isn't it
13:47 imirkin_: either way we should be force-enabling the hdmi audio function
13:50 aphirst: it seems there are a handful of arch forums threads which touch on this, though either using the prop. driver or unsolved
13:50 aphirst: unclear references to updates to the kernel and to the nvidia packages
13:53 aphirst: same behaviour in Linux Mint's liveISO btw
14:32 imirkin_: i'll send an email
14:32 aphirst: mailing list?
14:32 imirkin_: yes
14:32 imirkin_: linux-pci and nouveau...
14:33 aphirst: i'll see if i can follow the thread(s), should i subscribe to the lists or would following an archive page be enough
14:33 imirkin_: archive is enough...
14:33 aphirst: i'm almost finished with my thread which documents what i tried so maybe that'd be a useful reference?
14:33 imirkin_: it's not in specific connection to your issue
14:34 aphirst: fair
14:41 imirkin_: aphirst: https://marc.info/?l=linux-pci&m=150756010119164&w=2
14:42 aphirst: thanks, I'll keep track of that
15:15 aphirst: submitted: https://bbs.archlinux.org/viewtopic.php?pid=1741579#p1741579
15:16 aphirst: I don't think I've missed anything out?
15:27 imirkin_: not sure what the point of that post is
15:27 imirkin_: the people that can help you are all here.
15:28 imirkin_: btw, i'm guessing that after writing to that 488 register, you *will* see it in lspci -H1
15:29 aphirst: imirkin_, it's more to document everything in one coherent place
15:29 imirkin_: gotcha.
15:29 aphirst: and so that if someone else with the same issue decides to look online, they find that first, and hopefully get on-track faster
15:29 aphirst: when I spend time on something I like to make it so others don't need to too
15:30 aphirst: seems like basic etiquette
15:30 imirkin_: if it's to document, that's fine; i have no idea what those forums are for.
15:30 imirkin_: in my limited experience, it tends more to be with people asking questions
15:30 aphirst: well ostensibly it's for support
15:31 aphirst: it just seems right that there be a thread there
15:31 aphirst: even if just for someone else to find
15:31 imirkin_: in a distro-specific support forum for a non-distro-related issue?
15:32 imirkin_: either way, doesn't hurt me one bit ;) do what you think is best.
15:32 aphirst: with arch's increasing popularity and the large amount of overlap between thinkpad users and arch users it's going to be the first port of call for a lot of people
15:33 imirkin_: i think that statement could be made with any distro's name in there, and any laptop manufacturer...
15:33 imirkin_: [ok, admittedly some distros might be a hard sell there...]
15:33 imirkin_: is thinkwiki still a thing?
15:33 aphirst: i'm sure there's a way to strengthen my statement to preserve what we both know to have been my meaning
15:33 aphirst: imirkin_, it is but good luck getting an account
15:34 imirkin_: ah, i see =/
15:34 imirkin_: it used to be great back in the T4x days
15:35 aphirst: imirkin_, i can double check whether the thing shows up with -H1
15:35 aphirst: but like i say, i'm confident that it isn't applying properly
15:35 aphirst: since it's anyway not able to rmmod nouveau
15:36 aphirst: i couldn't even get it to blacklist properly, i added "blacklist nouveau" to blacklist.conf but it seemed to get loaded anyway
15:36 imirkin_: that's the sort of thing you'd want to get distro support for ;)
15:36 imirkin_: if you just do the setpci thing, without touching nouveau
15:36 imirkin_: er, i guess you'd need to ensure the damn thing was powered
15:37 imirkin_: so no runpm
15:37 aphirst: hmm?
15:37 aphirst: where does runpm factor in
15:37 imirkin_: well, nouveau auto-suspends the gpu
15:37 imirkin_: assuming your platform supports it, which 99.9999% of laptops do
15:37 aphirst: would it be a bad idea to do setpci with some application running under DRI_PRIME=1 ?
15:37 imirkin_: no
15:38 imirkin_: i mean - i don't think so ;)
15:38 imirkin_: can't say it's a well-tested scenario
15:38 aphirst: ah!
15:38 aphirst: it didn't break and it made the nvidia audio appear under -H1
15:39 imirkin_: right, which makes sense
15:39 imirkin_: the problem is that now you have to convince linux to find it
15:39 imirkin_: which is basically what my email to linux-pci was about
15:40 gnarface: if you run it early enough in boot up it works?
15:40 imirkin_: sure
15:40 imirkin_: if you wanted to hack it for just your system you could add an early_pci fixup
15:42 aphirst: i suppose I could make a systemd service to run that command early somewhere
15:48 aphirst: DefaultDependencies=no // WantedBy=sysinit.target should do, right?
15:50 aphirst: hmm, that wasn't enough, perhaps I should make it run those other commands too
15:50 aphirst: :P
15:50 aphirst: not just setpci
15:52 imirkin_: early like before the pci subsystem is initialized?
15:53 imirkin_: i suppose if you were very careful you could do it in an initrd, but it'd mean that pci would have to be modularized. not sure it supports that.
15:53 imirkin_: of course it's a catch 22, since in order to run setpci you need the pci subsystem :)
15:54 imirkin_: if you wanted it to work, you could do an early pci fixup
15:54 imirkin_: but i'm unsure whether that's within your skillset
15:56 karolherbst: aphirst, imirkin_ : doing the remove/rescan dance is kind of required for the kernel to make that device available
15:56 karolherbst: setpci isn't enough afaik
15:56 imirkin_: karolherbst: of course it's not.
15:56 imirkin_: it's a hack.
15:56 imirkin_: i.e. not required.
15:56 karolherbst: well...
15:56 imirkin_: just the way it is now.
15:57 karolherbst: no, it isn't
15:57 karolherbst: it's not a hack
15:57 imirkin_: no, it's a hack.
15:57 karolherbst: it's the way it has to be done
15:57 imirkin_: anytime the user runs setpci, it's a hack
15:57 karolherbst: ;) no
15:57 imirkin_: that's like the definition of "a hack"
15:57 karolherbst: well
15:57 karolherbst: that the user needs to do it is a hack, yes
15:57 karolherbst: but in the kernel we need to do the same thing basically
15:57 karolherbst: a quirk to set that pci reg and do a remove/rescan
15:58 karolherbst: just instead of userspace, the kernel has to do it in the end
15:59 karolherbst: I wish there would be another way
15:59 karolherbst: but with the information I've got, there ain't
15:59 karolherbst: and currently the pci subsyetem doesn't support those kind of quirks
15:59 karolherbst: *subsystem
16:05 karolherbst: aphirst: so here is the deal. the setpci call has to be done _before_ nouveau gets loaded, and the remove and rescan call needs to be done _before_ nouveau gets loaded as well. I think on your system nouveau gets loaded in initrd
16:10 karolherbst: I am not sure if the requiernment to do a remove is a limitation of Linux itself or if the device actually needs to be removed like that
16:12 karolherbst: aphirst: so here is what you need to do: 1. stop X 2. rmmod nouveau 3. make sure that nouveau isn't loaded anymore in lsmod 4. setpci -s 01:00.0 0x488.l=0x2000000:0x2000000 5. echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove 6. echo 1 > /sys/bus/pci/rescan 7. lspci should show the HDMI device now 8. modprobe nvidia-drm 9. start X again
16:13 karolherbst: ... *8. modprobe nouveau
16:18 aphirst: karolherbst, hey!
16:18 aphirst: sorry, I was away having dinner
16:20 aphirst: #1 so my service still seems to fail, i have it run a script (which IS executable) which does setpci, rmmod, the 2 other commands, then modprobe
16:20 aphirst: i hate how awkward it is to get useful log info from systemd
16:21 aphirst: especially with stuff like systemd-load-modules, i just want to know which module failed, and not have to parse miles of journalctl for it
16:21 karolherbst: journalctl -x name.service
16:21 karolherbst: or was it -u?
16:21 karolherbst: dunno
16:21 aphirst: "no entries" also "warning: journal has been rotated since unit was started"
16:22 aphirst: which is soo helpful
16:22 karolherbst: damn
16:22 karolherbst: anyhow, the GPU needs to be on to be able to be removed
16:22 karolherbst: removing it while it's off -> messup big times
16:23 karolherbst: but that's covered when nouveau was removed
16:23 aphirst: oh i might still have gotten the script wrong
16:23 karolherbst: you have to do it in initrd
16:23 aphirst: if i manually search journalctl -xe i see "failed at step EXEC spawning .. exec format error"
16:24 aphirst: so one sec again
16:29 aphirst: aha! OK, now that my commands actually run
16:29 aphirst: I see the devices in lspci and pavucontrol
16:30 karolherbst: :)
16:31 karolherbst: Lekensteyn: by the way, do you still plan to work on having a proper upstreamable way? It might be that we require a new kind of device quirk class for this
16:35 imirkin_: aphirst: are you going to be able to test kernel patches?
16:36 aphirst: imirkin_, I could do so at a push, preferably on weekends, and not repeatedly
16:37 aphirst: it's not exactly complicated to modify a PKGBUILD for linux to build from some other git repo or apply a patch, add a bootloader entry, and reboot
16:37 aphirst: even if the compilation takes a little while
16:37 imirkin_: some people would disagree
16:37 imirkin_: compilation should be fast, unless you use a distro config
16:38 imirkin_: not sure why anyone compiling their own kernels would use a distro config though
16:40 aphirst: well i'm not in the habit of doing it
16:40 aphirst: but i can set up the build system for it
16:48 aphirst: wait... not everything is as peachy as it seems
16:48 aphirst: chromium seems fine playing audio through HDMI but mpv doesn't like it
16:48 aphirst: why can't anything just work :P
16:49 karolherbst: well ;)
16:49 karolherbst: maybe mpv doesn't select the right output or something, who knows
16:49 aphirst: aaargh works after a reboot
16:50 aphirst: i get the feeling that X should not restart when an application screws up picking the audio dev
16:50 karolherbst: well at least more works on your system than before, that's something
16:50 aphirst: this is true
16:51 aphirst: i'll try to cut down on the chatter until i have a hook on what's going on
17:32 airlied: karolherbst: an early pci quirk isnt early enough?
17:33 karolherbst: either I did something wrong or yes, it isn't
17:33 imirkin_: airlied: i'm sure it's enough
17:33 imirkin_: airlied: however it feels a bit wrong to put something like that into the pci layer
17:33 karolherbst: well
17:33 airlied: imirkin_: its wheee it goes
17:33 imirkin_: not for the least of reasons that we'd have to get pretty extensive with pci id matching
17:34 karolherbst: somebody could use the HDMI audio function without nouveau
17:34 karolherbst: I know some with exactly this usecase where they don't need the graphic output
17:34 imirkin_: karolherbst: still have to use nouveau :)
17:34 imirkin_: to set up the hdmi link
17:34 airlied: passthrough
17:34 karolherbst: imirkin_: ohh I see
17:35 airlied: a qurik is the right place lots of insane stuff gets fixed there
17:35 imirkin_: airlied: seems a lot more straightforward to just hotplug the device in
17:35 imirkin_: but i don't know how to do that
17:35 imirkin_: we could do a by-family list of pci id "groups", but even that would be a long list
17:36 karolherbst: there are long lists for intel GPUs already
17:36 karolherbst: but yeah, I get your point
17:36 imirkin_: and i dunno that we could access bar values from within an early quirk
17:37 karolherbst: for runpm we have to set that reg anyhow
17:38 imirkin_: setting isn't the question
17:38 imirkin_: it's knowing when to set.
17:38 karolherbst: well, we need to set it after waking up the GPU
17:38 imirkin_: wouldn't want to do it to a gpu prior to GT215
17:38 karolherbst: makes sense
17:38 imirkin_: when waking up a gpu, it's often the same gpu as the one that went to sleep :)
17:39 karolherbst: imirkin_: G84+ is fine actually
17:39 imirkin_: the audio subfunction only exists on GT215+
17:39 karolherbst: imirkin_: right, but we need to poke that reg otherwise the audio device is still in "suspend state"
17:39 karolherbst: imirkin_: that reg isn't just for audio
17:39 karolherbst: but for any kind of multi functionality stuff
17:39 imirkin_: right
17:39 imirkin_: which only exists on GT215+
17:40 karolherbst: nvidia touches that reg on g84+
17:40 airlied: no bar access since you have to do it early
17:41 karolherbst: but yeah, it might be pointless prior gt215
17:41 imirkin_: and i suspect that prior to GF100 it all comes up OK
17:41 karolherbst: who knows for sure
17:41 imirkin_: i think GF108 is where they started messing around with it
17:42 karolherbst: well in doubt I would just do it for gt215+ in case there is this one card which needs it. Except there is a good reason not to do it
19:32 pmoreau: imirkin_, karolherbst: I’d appreciate if you cam take some time to review: https://patchwork.freedesktop.org/series/31280/ and https://patchwork.freedesktop.org/series/31548/
19:36 karolherbst: pmoreau: looks fine, will try to take a more detailed look tomorrow though
19:37 pmoreau: Thanks! :-)
19:37 pmoreau: Not sure when I’ll be able to finish reviewing your patches, I need to work on the linker for Friday.
19:39 karolherbst: I like how stable it is to run piglit in parallel now on nouveau :)
19:39 imirkin_: it kills the box much more consistently? :)
19:40 karolherbst: nope, it runs through without problems
19:40 karolherbst: still excluding the textureGather tests though
19:40 imirkin_: every time ben has said that, a piglit run killed my box
19:40 karolherbst: exclude textureGather
19:40 imirkin_: the bugs he fixes are real
19:40 karolherbst: not quite sure how stable it is on a non prime setup though
19:40 imirkin_: but ... still more left, i suppose
19:41 karolherbst: I run piglit on a second X server just to be super sure
19:47 karolherbst: ohh, now that I think of it, I could host my piglit results now
19:57 karolherbst: uhh wow nice, master: skip: 1536, pass: 22022, warn: 9, fail: 143, crash: 4 cts: skip: 1530, pass: 22038, warn: 9, fail: 133, crash: 4
19:59 karolherbst: no regressions
20:01 karolherbst: imirkin_: any plan to work on the textureGrad patch? https://github.com/karolherbst/mesa/commit/5a0c2ff1cf0805de1e6bc35f91e8aeeb46fc48b7
20:02 imirkin_: forgot all about that
20:02 karolherbst: it seems to fix 3 piglit tests as well
20:03 imirkin_: this all seems to suggest that there's something about derivatives i don't know
20:03 karolherbst: ohh more actually
20:04 imirkin_: mwk: can you look at that patch and see if it makes sense as to why it's needed?
20:04 karolherbst: glsl-130.tex-miplevel-selection texturegrad cube{,array,shadow} and arb_shader_texture_lod.tex-miplevel-selection *gradarb cube
20:06 karolherbst: uhm.. why are some arb_shader_image_load_store tests passing now
20:07 karolherbst: oh well
20:07 karolherbst: maybe that format fix
20:07 imirkin_: mwk: basically it looks like we need to do explicit derivatives based on "lane 0" as opposed to the "natural" lane
20:08 imirkin_: and i could even maybe see that in vertex shaders, but this is in frag shaders too
20:11 imirkin_: karolherbst: did i ever end up doing gm107?
20:12 karolherbst: doubt it
20:12 karolherbst: well that patch only contains the nvc0 stuff
20:12 imirkin_: i think i need to play around with some test apps
20:12 imirkin_: and see wtf is going on
20:13 karolherbst: maybe the current code is wrong in a different way and it might work in theory this way
20:13 imirkin_: i guess should be possible with 2darray
20:13 imirkin_: dunno
20:13 imirkin_: or does it only ever fail with cube?
20:13 karolherbst: let me check
20:13 karolherbst: yeah
20:14 imirkin_: it won't fail with plain things like 2d, since that's all handled by the built-in texgrad op
20:14 karolherbst: as I said: fixed piglit tests are glsl-130.tex-miplevel-selection texturegrad cube{,array,shadow}
20:14 imirkin_: =/
20:14 karolherbst: there are still 3 more fails
20:14 imirkin_: which ones?
20:14 karolherbst: uff isinf-and-isnan vs_xfb and so on
20:14 imirkin_: oh
20:14 imirkin_: unrelated to texture grad
20:15 karolherbst: yep
20:15 karolherbst: so all texturegrad tests seem to pass with this
20:15 karolherbst: at least with texturegrad in their names
20:15 imirkin_: :)
20:16 karolherbst: I'll make the results available in a short moment
20:20 karolherbst: imirkin_: https://mini.karolherbst.de:40443/nouveau/piglit/nve6-cts/
20:20 karolherbst: uhm.. maybe this link makes more sense https://mini.karolherbst.de:40443/nouveau/piglit/nve6-cts/problems.html
20:20 imirkin_: what are the 2 columns?
20:21 karolherbst: first is master
20:21 karolherbst: second is cts rebased on that master
20:21 imirkin_: ah cool
20:21 karolherbst: yeah
20:23 imirkin_: wtf
20:23 imirkin_: int64 fs-shift-vector-by-scalar fails?
20:23 imirkin_: i thought we fixed all that
20:23 imirkin_: did i mess it up?
20:24 karolherbst: no clue
20:24 karolherbst: I have two other master results
20:24 imirkin_: it's a different impl for SM30 vs SM35
20:24 imirkin_: but i thought i got both covered
20:24 karolherbst: ohh, I see
20:24 imirkin_: [for shifting]
20:26 karolherbst: uhh, there are two texgrad fails
20:26 imirkin_: oh those? i know about those.
20:26 imirkin_: iirc they've always failed
20:26 imirkin_: issue in the test or something
20:27 karolherbst: on other GPUs as well?
20:27 imirkin_: no
20:27 imirkin_: or i dunno
20:27 karolherbst: well
20:27 imirkin_: tbh i forget
20:27 karolherbst: at least both tests fails the same on both branches
20:27 karolherbst: *fail
20:27 imirkin_: ;)
20:28 karolherbst: on 641f629536c2daf6112fe9d5b904c012bb07b912 those int64 tests also fail
20:29 karolherbst: mhh, interesting
20:29 karolherbst: we have indeed some regressions
20:29 karolherbst: we passed those isinf-and-isnan fs_fbo tests once
20:29 peterius: hi, I just got a new laptop to replace one that failed... gtx 1060 and I think it has some onboard intel thing
20:29 peterius: I get these little mini-freezes in x11
20:30 karolherbst: but I also ran a super old piglit with those, oh well
20:30 peterius: I tried disabling the intel drivers thinking they were interferring with the nouveau, switching in and out, but then I can't even get to a console
20:31 imirkin_: screen is driven by intel
20:31 imirkin_: at least in most cases
20:32 imirkin_: karolherbst: can you the a debug log with those int64 fails?
20:32 imirkin_: i wonder wtf happened. iirc you tested it and it all worked. probably new tests.
20:32 karolherbst: what did I test?
20:32 imirkin_: my int64 enablement patches
20:33 karolherbst: really... can't remember
20:33 imirkin_: well, i'm sure i tested them on a kepler1
20:33 imirkin_: and i don't have one
20:33 karolherbst: maybe very vaguely
20:33 imirkin_: you're the most likely candidate ;)
20:33 karolherbst: well I would prefer to focus on the gtf fails for now though
20:34 imirkin_: if it's not hard though, just grab a NV50_PROG_DEBUG=1 for one of them please
20:34 karolherbst: yeah, should be possible
20:34 karolherbst: and by the way, something is super odd with my server... I think it shuts down itself automatically for whatever reason
20:35 imirkin_: can't handle the intense load? :)
20:36 karolherbst: uhm...
20:37 karolherbst: nice, nothing inside the logs, perfect
20:37 karolherbst: ups "[kernel] [ 2189.840924] nouveau 0000:02:00.0: therm: temperature (101 C) hit the 'critical' threshold"
20:37 karolherbst: ahhh crap
20:37 karolherbst: the fan is gone
20:37 karolherbst: silly tesla GPUs
20:40 karolherbst: imirkin_: spec@arb_query_buffer_object@qbo https://gist.githubusercontent.com/karolherbst/029dd155e585407140249883aa0fa1c5/raw/73bfbbc7e17751eac9afd6011ab77ad9a050b92f/gistfile1.txt
20:40 karolherbst: uhm...
20:40 karolherbst: wrong test I guess
20:40 imirkin_: int64 fails.
20:40 imirkin_: it's expected.
20:40 karolherbst: ohh no, it's the right one
20:41 imirkin_: er
20:41 imirkin_: int64 + any_samples
20:41 karolherbst: ahhh
20:41 imirkin_: i got lazy when implementing qbo
20:41 imirkin_: "nah, no one will care about this"
20:41 imirkin_: :)
20:41 karolherbst: right
20:41 karolherbst: so back to those gtf fails then
20:42 imirkin_: could you do a NV50_PROG_DEBUG for the int64 shift fail?
20:42 karolherbst: can't imagine that those "!opengl 1.1" fails are related to that
20:42 karolherbst: yep
20:43 karolherbst: https://gist.githubusercontent.com/karolherbst/e13a646474f1693861e947925453b4a7/raw/554888411c7ae4109bee0de2b159eaf201adc00d/gistfile1.txt
20:43 imirkin_: thanks
20:44 imirkin_: oh ffs. i think nha changed the shift argument from u32 to u64
20:45 karolherbst: duh...
20:46 imirkin_: d10fbe5159ce1f7e05e959bb44e50f40a2402fb5
20:46 imirkin_: grrrr
20:47 karolherbst: you seem to like it
20:48 imirkin_: ?
20:48 karolherbst: that patch
20:48 imirkin_: how so?
20:48 karolherbst: just a feeling I got
20:49 imirkin_: try changing
20:50 imirkin_: line 4031, src1 = fetchSrc(1, c / 2); -> src1 = fetchSrc(1, c);
20:50 karolherbst: in that file?
20:50 imirkin_: nv50_ir_from_tgsi.cpp
20:50 karolherbst: would have been my second guess
20:51 karolherbst: pass
20:51 karolherbst: both tests
20:51 imirkin_: yep
20:51 imirkin_: makes sense.
20:51 imirkin_: urgh.
20:52 karolherbst: should I do a full rerun with that change?
20:52 imirkin_: no
20:55 karolherbst: meh, those opengl1.1 depthstencil fails are indeed most likely related to the gtf fails I found
20:57 karolherbst: or related to those ext_framebuffer_multisample fails?
20:57 karolherbst: maybe both
20:59 karolherbst: anyhow, that gtf test tests glBlitFramebuffer