00:48 imirkin: hakzsam: do you remember maxwell+ being sensitive to texture cache contents for image reads/writes? i can't imagine it would be, but ...
01:47 rhyskidd: karolherbst: i also see the 0x82 GPIO on my GP107 vbios (with DCB 4.1, which the docs we have indicate should instead be reserved).
01:47 rhyskidd: what hints at this GPIO's function?
01:53 skeggsb: nvidia's "reserved" appears to mean "we don't want to tell you" ;)
01:53 skeggsb: or "reserved for our eyes only"
02:34 imirkin: ok, so let's see ... i need to test the plane thing with bt.701, the whole tbo-is-broken-on-nv50 now thing, and that patch on fermi.
02:35 imirkin: i think that means quadro 400, quadro fx 1700, and ... do i have a pci nv34?
02:35 imirkin: er, 3700.
02:36 imirkin: skeggsb: need anything in particular tested?
02:36 imirkin: skeggsb: btw, did you see my thing about vdpau fail?
02:47 mooch: imirkin, i know a guy who just recently built a pc with a quadro fx 1800
02:47 mooch: which i thought was a laughable choice of gpu, given that the 750ti is more powerful AND has more ram
02:47 mooch: and it's cheap
02:47 mooch: i have one
02:50 skeggsb: imirkin: did you say what broke vdpau btw?
02:50 imirkin: skeggsb: no, just what i saw when it broke
02:50 skeggsb: when was that? i think i missed it
02:50 imirkin: sec
02:52 imirkin: skeggsb: https://hastebin.com/ujimasuboh.vbs
02:58 imirkin: maybe something odd happened on this box... i dunno. i'm running your 4.16 branch + a handful of things
03:32 imirkin: skeggsb: did you repro anyhting like that?
03:33 skeggsb: my mplayer window appears to freeze, leaving everything else uneffected
03:33 skeggsb: no dmesg
03:34 imirkin: yeah, i get that too... try -nofs
03:34 skeggsb: MPlayer interrupted by signal 2 in module: flip_page
03:34 skeggsb: that's when i killed mplayer
03:34 imirkin: vdpau has just been getting more and more broken
03:34 skeggsb: will -nofs kill my machine?
03:34 skeggsb: rather not do that from the one i'm on right now
03:34 imirkin: it should kill it less than the -fs thing :)
03:35 imirkin: did you get a full screen window?
03:35 imirkin: if so, -nofs will make it windowed
03:35 skeggsb: oh, i got windowed even without that
03:35 imirkin: oh ok
03:35 imirkin: so then unrelated
03:35 imirkin: are you using wayland or something btw?
03:35 skeggsb: yeah, on wayland
03:35 skeggsb: i think
03:35 imirkin: and/or modesetting?
03:35 skeggsb:checks
03:36 imirkin: yeah ok, then you're far far far far into uncharted territory :)
03:36 skeggsb: no Xorg in "ps" output, so, i assume wayland :P
03:37 imirkin: dunno, for me it's just "X"
03:38 imirkin: /usr/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt8
03:38 imirkin: anyways, yeah ok, i dunno what happens to vdpau in the presence of wayland
03:38 imirkin: it does seem like the sort of thing that should work... just a regular ol' DRI client. but ... who knows.
03:39 imirkin: i know there's funky winsys stuff in there somewhere as well
03:39 skeggsb: skeggsb@nisroch ~ $ echo $XDG_SESSION_TYPE
03:39 skeggsb: x11
03:39 skeggsb: nope, it's X :P
03:39 imirkin: just hiding?
03:39 skeggsb:has no idea these days, it changes depending what i tested something on last
03:40 skeggsb: it's just "X" like yours
03:40 skeggsb: also have Xwayland running, but i think that's for gdm
03:40 imirkin: and simplicity :)
03:43 imirkin: gonna try it again and see what happens
03:43 imirkin: planning on rebooting anyways
03:45 imirkin: yeah, no good. i think with the last pvld failure, the whole engine's just kinda stuck
03:45 imirkin: reboot + re-hw time. bbl
04:13 imirkin: why is it that EVERY time i restart X, the cursor manages to get messed up in *some* application. who thought cursor themes were a good idea? ugh. where's the --dont-fuck-with-my-cursors option? :(
04:19 imirkin: hmmmm ... something got messed up somewhere
04:40 imirkin: mupuf: why is this even being exposed? https://hastebin.com/ranokihuge.pl (on a nv34)
05:03 imirkin: skeggsb: this is what i get with vdpau on the gf108: https://hastebin.com/rizoserohe.go
05:03 imirkin: skeggsb: note that this is *with* the change in that pull req in your repo
05:06 skeggsb: imirkin: yeah, those are all a symptom of the channel having hung
05:06 imirkin: ok
05:07 imirkin: iirc the last kernel this all definitely semi-worked on was 4.12
05:07 imirkin: maybe a change in mesa is killing it? could be...
05:22 imirkin: oh goodie. tbo's are broken on fermi too! yay!
05:22 imirkin: who was the stk guy who wanted me to look at this stuff?
05:22 imirkin: my mind's like a sieve... i've already forgotten :(
08:53 hakzsam: imirkin: I don't remember
09:24 pmoreau: imirkin: Good to know. Math flags (and rounding modes) are on a per instruction basis as well in SPIR-V. However, there is nothing about denorms.
10:57 mupuf: imirkin: interesting, I guess my condition for exposing it must be wrong
11:18 karolherbst: imirkin: isn't X responsible responsible for setting the cursor though? I thought you can only do this through X APIs?
11:20 karolherbst: mupuf: I think it was broken with the hwmon rework
11:20 mupuf: karolherbst: sounds plausible indeed
11:20 karolherbst: I have patches to fix some of it
11:24 karolherbst: https://github.com/karolherbst/nouveau/commit/281fb3ecb48d0579725b1b350d11b07d404d7b01
11:24 karolherbst: and https://github.com/karolherbst/nouveau/commit/d552a6fd9a5bde33594e0c883b0dbecf458f8695
14:56 imirkin: karolherbst: yeah, but applications can override it. i've spent a bunch of time convincing gtk & co to "not do that"
14:57 karolherbst: uhh, okay
14:58 imirkin: this time it's just chrome
14:58 imirkin: but like gtk2 and gtk3 need to be convinced separately
14:58 imirkin: not to mention gentoo, which by default sets things up that it shouldn't
15:00 karolherbst: :(
15:00 karolherbst: can those silly APIs be removed?
15:00 karolherbst: I am all for removing those APIs which just lead to unwanted behaviour
15:01 karolherbst: allowing applications to change the resolution is pretty high on that list as well
15:01 imirkin: an application like xrandr? :)
15:01 karolherbst: well, maybe we should allow the window compositor to do that
15:02 karolherbst: and if there is no compostior, then any application
15:02 karolherbst: but this would break a lot of applications :(
15:03 imirkin: btw, i tested and pushed the fix for KHR-GL45.enhanced_layouts.fragment_data_location_api on fermi
15:03 imirkin: or rather, i tested on fermi, then pushed globally :)
15:04 karolherbst: :)
15:05 imirkin: fwiw i have gf108 and g92 plugged in now (and nv34) - let me know if you need anything
15:08 annadane: so i just switched to xfce :P
15:08 annadane: no more complaining about crashes
17:21 imirkin_: crap, i need to push out my various xf86-video-nouveau changes...
17:22 imirkin_: has anyone had a chance to test out my changes to support DP-MST?
17:22 karolherbst: imirkin_: ohh crap, I could have, but I have to give away the hardware tomorrow
17:22 karolherbst: I think I can give it a quick test tomorrow
17:23 imirkin_: if you can - great. if not, i'll just push it.
17:23 imirkin_: since i think that's going to be the only way to get it some testing.
17:24 karolherbst: probably
17:24 imirkin_: patches are here: https://github.com/imirkin/xf86-video-nouveau/commits/master
19:58 danboyd1: imirkin_: what MST changes did you push out? I can test on my rig. I've got two Dell monitors that support DP1.2/MST
21:19 mupuf: danboyd1: I assume that the current nouveau ddx does not support MST at all
21:19 mupuf: his patch is here: https://github.com/imirkin/xf86-video-nouveau/commits/master
21:20 mupuf: just chain two displays together and see if you this works with his patch :)
21:31 danboyd1: ok will give it a shot tomorrow
21:49 imirkin_: danboyd1: awesome, thanks! let me know if it works.
21:49 imirkin_: the current ddx supports MST in that if the monitors are hooked up over MST it'll be none the wiser
21:49 imirkin_: the problem is that if you then unplug one of the monitors
21:49 imirkin_: the connectors go away
21:49 imirkin_: and ka-boom
21:49 imirkin_: or, conversely, connectors can appear, and won't get noticed
21:50 imirkin_: with "my" patch, that should all work properly
21:50 imirkin_: (in quotes since i just copied the code from xf86-video-modesetting)
21:55 mupuf: imirkin: cargo-culting ftw ;)
21:55 imirkin_: hey, don't mess with success
21:56 imirkin_: a generic thing that handled the kms stuff would be great
21:56 imirkin_: i.e. move all that stuff to a libdrmmode or something
21:56 mupuf: imirkin: this is what -modesetting is supposed to be. How about making the 2D acceleration pluggable?
21:57 imirkin_: coz it's a bunch of differently-broken impls =/
21:57 imirkin_: mupuf: i thought we had that. it's called EXA.
21:57 mupuf: imirkin: well, I meant inside of -modesetting
21:57 imirkin_: :)
21:57 imirkin_: conceivable.
22:07 mupuf: imirkin: it would, indeed
22:45 Yardanico: Hello everyone, I want to ask about nv110 and modern Nvidia GPUs in general - why there's a lot of new cards which don't have reclocking support in nouveau? Is that because Nvidia doesn't release firmware for reclocking?
22:48 imirkin_: GM10x should have reclocking actually
22:48 imirkin_: GM20x requires signed firmware for fan control
22:49 imirkin_: GP10x requires signed firmware and an entirely different reclocking process that we have no way to RE.
22:50 orbea: how is it impossible to RE?
22:50 imirkin_: well, maybe not impossible
22:50 imirkin_: but would require a different technique than we have used in the past
22:50 orbea: ah
22:50 imirkin_: since any single developer will only have a small number of boards, out of the thousands of different ones
22:51 imirkin_: and the vbios is largely undocumented
22:51 imirkin_: one would fuzz the vbios and see what effect it had on the reclocking scripts
22:51 imirkin_: this doesn't provide the full picture, but a good amount of it
22:52 Yardanico: So there's no near plans for fan control for gm206? Because doing RE is hard I suppose?
22:52 imirkin_: with newer drivers (and hardware), we have no good way to fake the vbios to be presented to the driver
22:52 imirkin_: Yardanico: nah, it's trivial - we just don't have signed firmware to do it.
22:52 Yardanico: So Nvidia should either give its firmware or sign nouveau firmware?
22:53 imirkin_: the firmware that nouveau developers have produced is not signed with nvidia's key, so the processor won't go into secure mode, which in turn doesn't allow us to operate the fan
22:53 imirkin_: and the firmware that nvidia has signed and released for redistribution in linux-firmware has none of the functionality necessary for reclocking or fan control
22:54 Yardanico: And is it possible to use firmware from Nvidia driver (I know this is illegal, but just for info)?
23:03 imirkin_: Yardanico: it's certainly not illegal
23:04 imirkin_: we just wouldn't be able to distribute that firmware ourselves
23:04 imirkin_: but as an end user you could do whatever
23:04 imirkin_: however as part of the whole secure thing, getting at that firmware has also gotten more complicated
23:04 imirkin_: and our previous methods for doing so also no longer work
23:06 Yardanico: Even for gm206?
23:06 imirkin_: starting with GM20x yeah
23:08 imirkin_: i wrote up a thing about it... let's see if i can find it
23:10 imirkin_: Yardanico: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-nvidia-linux-nouveau/998310-nouveau-persevered-in-2017-for-open-source-nvidia-but-2018-could-be-much-better?p=998427#post998427