01:11karolherbst: imirkin: mhh, the only difference I can find so far is, that with TGSI the immediates are directly where they are used and with NIr there are all in BB:0
01:11karolherbst: and those values who doesn't get a phi nodes are assigned from those
01:35karolherbst: it makes no sense... I am sure pretty much everything is the same, and still it isn't
02:34karolherbst: imirkin: I don't update the loopNestingBound value
02:34karolherbst: and this one seems to be important for the ssa translation
02:35karolherbst: mhh, intersting, it tells us the max depth of loops
02:38karolherbst: meh, now it works... it had to be a stupid mistake, it had to
02:43rhyskidd: karolherbst: I'll get the Pascal temp register patches cleaned up and into envytools. Has been sitting on my TODO list for a while now after you mentioned it
03:18bazzy: Gah, I'm on a MacbookPro 5,4 Geforce 9400m and (aside from awesome job nouveau!) when I plug in a 2nd monitor via mini displayport, that new monitor experiences interspersed flickering. Sometimes it goes away for several seconds, a minute, other times it comes back with a vengeance, and goes into making me borderline want to stop. It is fun though if I'm in "rave mode" to techno
03:20bazzy: I'm using Gentoo on a 4.9 kernel, -- i don't have this problem with legacy nvidia-drivers -- don't even let me tell you part that if I actually unplug the mini-display port cable, how i basically have to hard reset because my system becomes inoperable (and the main screen becomes a rave flicker scene)
03:21bazzy: I use XFCE4.12, but right now I'm in i3 (no compositing)
03:25gnarface: bazzy: just a shot in the dark type guess, but what if you set drm_kms_helper.poll=0 on the kernel command-line? i'm wondering if this might be related to a similar problem i experienced
03:26bazzy: gnarface: I'll try it now, rebooting
03:29bazzy: I definitely saw it flicker a little since I've booted. but I'm going to wait to see more of this activity.
03:30bazzy: once I put some load (opening google-chrome) it's begun flickering like crazy.. seems to have calm done after the chrome-bringup
03:30bazzy: it can tend to flicker when I'm not driving the system either
03:30gnarface: hmm. maybe not related to kms polling then
03:30bazzy: it's sporadic, from my sense
03:31gnarface: could be power management related
03:31gnarface: or perhaps compositing
03:31bazzy: compositing is off
03:31gnarface: you say it only happens while in X?
03:31bazzy: i thought so let me go back to VT for a bit
03:31gnarface: if the virtual terminals flicker even when Xorg is not running, that might be significant information
03:32bazzy: ok I'm in VT. we'll see what happens. Of course this is slightly different setup too. Here is the 2nd monitor mirroring the primary.
03:32bazzy: In X, the 2nd monitor is extending the primary
03:32bazzy: oh it just flickered!
03:32bazzy: (in VT)
03:32bazzy: but not yet as radically as in X
03:33gnarface: hmm. weird
03:33bazzy: there it is again..
03:34bazzy: thanks for trying.
03:34gnarface: sorry i'm not really one of the ones in the know here
03:34bazzy: well you did help me diagnose further
03:34bazzy: you know what
03:34gnarface: someone else might still have a workaround in mind
03:34bazzy: i should shut down X
03:35bazzy: i'm in VT but X is still running..
03:35gnarface: it might make a difference
03:35gnarface: mostly just about isolating the problem
03:35bazzy: ok X is down now. I'll be on the lookout for that flicker. BAM it flickered. So it's not because of X
03:36bazzy: maybe I'll try rebooting without starting X at all just to be sure
03:36gnarface: i wonder if it could be an issue with the displayport driver
03:36gnarface: i'm not even sure there is a displayport driver
03:43bazzy: yeah it flickers in VT too
03:44bazzy: from reboot
03:45bazzy: at the moment the non-flicker time is outweighing flickering by about 80%, but against all logic it could come back with a vengeance, like before. We'll see
03:45gnarface: is there a displayport driver?
03:45gnarface: i'm not familiar with displayport use on linux
03:45gnarface: if it has a kernel module maybe there are some debug options
03:46bazzy: Erm, not sure, would have to revisit my kernel config,
03:47bazzy: not getting anything searching strings in `make menuconfig`
03:50bazzy: someone having a similar problem: https://unix.stackexchange.com/questions/167433/macbook-pro-mini-displayport-flickering-over-debian
03:50bazzy: sadly no answers
03:50gnarface: well it might interest you that my initial search results on google suggest there was a well-known displayport bug that caused flickering, and there's a linux.com article claiming that they made a patch that will go into kernel 4.12
03:50bazzy: is that so? Well I have kernel 4.12.12 on my box, i could try that out
03:50gnarface: worth a try
03:55gnarface: i had to roll back to 4.9 due to unrelated alsa problems, but ymmv
04:07bazzy: could you look me once more to that article?
04:07bazzy: gnarface: ^
04:07bazzy: I accidently booted into 4.12 without rebuilding my kernel modules (i made some significant changes in 4.9), so that was a big NONO. now I'm rebuilding.
04:45gnarface: bazzy: sorry, i had wandered away, here it is from my scrollback: https://www.linux.com/news/event/open-source-summit-na/2017/3/fixing-linux-graphics-kernel-true-displayport-compliance-or-how-upstream-patch
04:46gnarface: bazzy: i inferred that it would be a patch that would appear in the changelog but i didn't actually look for it to verify it made it into 4.12.12
04:47gnarface: you might want to double-check that it didn't get delayed until 4.13 or something like that after that article was written
04:47gnarface: it might be possible to apply the patch directly to 4.9 though, i don't know
05:13bazzy: if anyone said anything to me the past hour, i never got it. :( I have another issue where the screen sleeps permanently if in VT afk
05:13bazzy: so i had to blind reboot
05:14bazzy: damn screen is still flickering even in 4.12.12
05:54bazzy: I think I fixed it!
05:55bazzy: runpm=1 seems to have fixed it :D
05:55bazzy: (pass to nouveau module)
05:56bazzy: gnarface: it was you I was talking to earlier, right? You gave me the hint about power management, thanks!
05:57bazzy: display has been stable for a few minutes now :D
05:58bazzy: I'm not sure how to pass this parameter at bootup
06:11bazzy: ok I found the location for my machine! Sweet!
06:32ylwghst: bazzy: sudo nano /etc/default/grub
06:32ylwghst: bazzy: add it to
06:33ylwghst: bazzy: GRUB_CMDLINE_LINUX_DEFAULT="runpm=1"
06:33ylwghst: bazzy: then
06:33ylwghst: bazzy: sudo update-grub
06:35bazzy: oh.. no.. the dreaded flicker has returned .-.
06:35ylwghst: which gpu?
06:36bazzy: nvidia geforce 9400m (legacy) ~2009
06:36ylwghst: what driver do you use?
06:37ylwghst: well i got similar one a geforce 320M
06:37bazzy: well there's no flicker on the mini-display port with nvidia-drivers, but with nouveau (which *would* be my preferred choice if i can get it working)..
06:37bazzy: the 2nd monitor will exhibit some flickering occasionally / sporadically
06:38ylwghst: i see
06:38ylwghst: i havent used external display with nouveau yet
06:38ylwghst: ask on #nouveau
06:38ylwghst: what says dmesg?
06:38bazzy: um.. this is #nouveau
06:39ylwghst: oh yes :-)
06:40ylwghst: I occasinally get MMIO write errors
06:41ylwghst: which desktop env?
06:42bazzy: guys here is my dmesg surrounding the video stuff: https://paste.pound-python.org/show/8eVc2l40F5J7tC5O4o29/
06:43ylwghst: there are no erros
06:43bazzy: I'm on i3 atm
06:43ylwghst: are you using compton?
06:44bazzy: no, no compositor atm
06:44ylwghst: btw. are you on macintosh?
06:44bazzy: yes macbook pro 5,4
06:46ylwghst: try gnome3 with wayland works best on my system with nouveau
06:46ylwghst: just test it if it will be better
06:47bazzy: unfortunately i've already found that the flicker is even present in VT
06:47bazzy: (Virtual Terminals)
06:47bazzy: so it's not an X issue
06:47ylwghst: i see
06:47ylwghst: i have no idea
06:47bazzy: i also just found out i actually haven't tested 4.12.12 kernel yet :3
06:48ylwghst: i switched to 4.14 and its working quite good for several days without any issue
06:48ylwghst: until i run Atom, editor
06:48ylwghst: then i get lots of MMIO errors and later ma screen completely freezes
06:49ylwghst: im on macbook 7,1 mcp89 gefore 320m
06:49ylwghst: but its very strange that your problem is present even in VT
06:50ylwghst: that should be something different
06:51bazzy: *shrug* ... we think it's the mini display port. even though nvidia-driver handled it fine..
07:11bazzy: ugh, 4.12.12 is also featuring the screen flickering issue I'm having
07:52ylwghst: i wish i could test mine
07:53gnarface: bazzy: did you also try the runpm thing with 4.12.12?
07:54gnarface: bazzy: (probably worth testing the drm_kms_helper.poll=0 on it separately too, if you haven't)
07:54gnarface: bazzy: also, not knowing anything more about it i'd as readily imagine "runpm=0" might be worth testing
07:55gnarface: just because i'm not sure which is actually the default
07:56gnarface: if HDMI is involved, unfortunately you can't even be sure this isn't a physical problem with the cables or connectors, even if they were working fine before
07:56gnarface: the kernel upgrade may have been merely coincidental
07:57gnarface: if you can try some other cables/hookups/displays it might be worth it at this point too
07:57gnarface: just to rule out those cursed cheap HDMI cables
07:57gnarface: (the most expensive ones on the shelf may not be always necessary, but the cheap ones are NEVER worth it)
08:24ylwghst: Well the DP doesn't work on mine machine at all...
08:24ylwghst: If plug in the display in the main display gets freezed
08:24ylwghst: then i get [ 57.919389] nouveau 0000:02:00.0: DRM: DDC responded, but no EDID for DP-1
08:48sooda: did y'all notice these yet? http://download.nvidia.com/open-gpu-doc/Display-Class-Methods/2/
08:49sooda: ah looks like robert announced that in the mailing list as well
10:35karolherbst: imirkin: the dp instructions are already in the manual: http://docs.nvidia.com/cuda/parallel-thread-execution/index.html#integer-arithmetic-instructions-dp4a
12:32pmoreau: bazzy: Have you tried to reclock the card? It’s quite possible it won’t improve things though. runpm=0/1 shouldn’t change things, unless you also have a 9600M in your laptop. But still, Nouveau won’t power off that other card by default.
12:34pmoreau: But external monitors have been an issue on those laptops; I have a mid-2009 with MCP79+G96 (is that a 5,3?), and I could only get something to show up on the external screen using a mDP to VGA adaptor (IIRC). HDMI or DVI wouldn’t work.
12:34pmoreau: I wanted to fix it, but I haven’t really looked into it yet.
16:48bazzy: pmoreau: I wonder what the cause of the issue is?
16:49pmoreau: I am not sure.
16:49bazzy: pmoreau: did you experience lockup when unplugging the mDP cable "hot" ?
16:50pmoreau: Probably something misconfigured on the GPU, maybe?
16:50pmoreau: I think I remember the screen no longer updating in some cases, but I am not sure whether the whole computer locked up or not.
16:51bazzy: pmoreau: I'm pretty good at "blind" rebooting, and it wouldn't work for me after unplugging/replugging.
16:57pmoreau: bazzy: Does https://bugs.freedesktop.org/show_bug.cgi?id=88272 sound similar to you?
17:02bazzy: sorta, cept I'm using my mDP -> DVI right now. It's just that I get intermittent "jump" / flicker on the 2nd monitor. LVDS has flickered and apparent system lockup when unplugging the adapter without warning xrandr. Not sure what will happen if I tell xrandr to stop it itself.
17:03bazzy: sometimes I will get no flicker for minutes at a time, but it's rare
17:03bazzy: I just dumped my vbios, would that help?
17:03pmoreau: Feel free to open a new bug and post there all the information you have and different things you tried.
17:04pmoreau: I won’t be able to look at it over Christmas/New Year as I won’t have an external monitor with me, but I’ll try to spend some time after that. Maybe a bit tonight as well.
17:04pmoreau: That could potentially help
17:05bazzy: well my problem does sound like the bug, just not your own tests filed in that thread.
17:06bazzy: I am using a mDP -> displayport/DVI/HDMI adapter. works fine with nvidia-drivers. I'll try to assemble some kind of report for the bug thread
17:06bazzy: Note: I've only tried this with DVI end of the adapter
17:06pmoreau: I should be able to try that tonight, see how it goes.
17:07bazzy: I hope we find the source
17:08pmoreau: Yeah, that was the last thing I wanted to fix on that laptop, but never got to it.
17:08bazzy: i also tried it with displayport mts (multistream) disabled (kernel param). not sure what that does but it didn't help this issue
17:09pmoreau: Some kind of power/clock-gating could be nice as well (I think they had some version of it), but I no longer use that laptop as my main one, so motivation to get it work as well as possible is fading away.
17:10bazzy: Oh no
17:10pmoreau: I had that issue before multistream got merged.
17:11pmoreau: At least the laptop boots rather than lock up while Nouveau is trying to initialise the GPU. :-D
17:18karolherbst: *sigh* texturing is quite complicated
17:33karolherbst: first texture test passing :)
17:43karolherbst: yay \o/
17:44karolherbst: pmoreau: all the gputest tests are running except those tesselation things :)
17:46imirkin_: bazzy: you have a MCP79 right?
17:46bazzy: imirkin_: ^
17:46imirkin_: ok, so then DP-MST should be of no concern - that wasn't a thing until kepler i think
17:46imirkin_: did you end up trying to increase the clocks?
17:47bazzy: I tried via sysfs to the 2nd-highest setting, no visible change
17:48imirkin_: what about highest?
17:48imirkin_: you mean debugfs, presumably?
17:48bazzy: erm yes,
17:48bazzy: could you remind me where to set it?
17:49imirkin_: assuming you have debugfs mounted at /sys/kernel/debug
17:50bazzy: when i cat it i get a bunch of pstates like "0f: core..." and after trying `echo "0f" > pstate` from /sys/kernel/debug/dri/0 directory I'm still getting the flickering.
17:50bazzy: any way to confirm the pstate change?
17:51imirkin_: look at the last line
17:51imirkin_: and confirm that it looks close to the desired line
17:51imirkin_: (sometimes it'll be off by a few MHz)
17:51imirkin_: and check dmesg for any nouveau errors
17:51bazzy: ah yes, and i'm also now seeing an asterisk next to the mode I set
17:51imirkin_: the asterisk is a lie
17:51imirkin_: meant to lull you into a false sense of safety
17:52bazzy: AC (last line) matches 0f (highest)
17:52bazzy: and it didn't before..
17:52imirkin_: ok cool
17:52imirkin_: you can clock it down if you want
17:52bazzy: yeah I'll add that to my notes
17:52imirkin_: anyways, either we miss some clock domain
17:52imirkin_: or there's more to it
17:52imirkin_: i vote for "both"
17:52karolherbst: imirkin_: is there an easy way to get the right TexFormat if you have like three fields: glsl_sampler_dim, bool is_shadow, bool is_array and I am sure I missed a flag
17:53imirkin_: karolherbst: what's the context?
17:53bazzy: oh my gosh, if I clock 2 settings down, my 2nd monitor flickers like CRAZY
17:53imirkin_: i meant more like ... what's the operation
17:53karolherbst: imirkin_: well, I get that nir_tex_instr thing
17:53bazzy: 1 setting down and I'm back to square 1
17:53karolherbst: imirkin_: ohh I just want to parse the TexFormat out of that nir_tex_instr
17:53imirkin_: and why do you need the TexFormat (and wtf is the TexFormat... do you mean TexTarget by any chance?)
17:53karolherbst: ohh right
17:54bazzy: so in summary: pstate 03, 05 produces incredible constant flicker on the 2nd monitor, and settings 0e and 0f are the intermittent flickering I've always been experiencing.
17:55karolherbst: bazzy: I think we do something wrong here regarding this on mcp79 in general
17:55karolherbst: bazzy: I have the same problem on mine basically, just that it works on the highest level
17:56bazzy: yours is also mcp79? can I have more info on your setup?
17:56karolherbst: imirkin_: skeggsb suggested it might be related to one of those clocks we don't know what they do basically
17:56karolherbst: bazzy: mac mini
17:56imirkin_: you'll need to write a function, but it should be easy to convert between them
17:56karolherbst: I don't use it with a display though, soo
17:56imirkin_: basically sampler dim + shadow + array == TexTarget
17:56karolherbst: imirkin_: yeah, just wondered if there is already one... well guess not
17:56imirkin_: the existing stuff is mapped around the tgsi ones
17:57karolherbst: I saw
17:57imirkin_: you can look at st_glsl_to_tgsi to see how it does it
17:57imirkin_: should be mostly cut & paste
17:57karolherbst: but sadly not
17:57karolherbst: because I need those silly ifs or something ;)
17:58karolherbst: I guess a macro will help
17:58imirkin_: i mean for how it goes from the glsl stuff (which is largely what the nir stuff has) to the tgsi info
17:58karolherbst: ohh right
17:58karolherbst: but that part I already got kind of
17:58imirkin_: then what's the question
17:58karolherbst: just without the shadow+cube thing
17:58imirkin_: right so ... not the full thing
17:59imirkin_: so just take the thing that st_glsl_to_tgsi does
17:59imirkin_: which has everything.
17:59imirkin_: or type it out - i don't care.
18:12pmoreau: Hum, I thought I had mDP -> DVI, but apparently not. :-/
18:15imirkin_: bazzy: the realistic prospects for getting your issue fixed are grim. they're happening on specialized hardware which is relatively old. chances are this will have to be something you fix yourself. or find someone who is interested in doing an in-depth investigation (e.g. pmoreau)
18:20pmoreau: bazzy: Have you tried mDP to VGA? I just tried that as I couldn’t get my hand on a mDP to DVI, and the LVDS just went black.
18:21bazzy: pmoreau: I haven't. I don't have such an adapter/cable atm
18:22bazzy: I might be able to try mDP -> DVI -> VGA
18:23josef__: karolherbst: do you have a specific patch suggestion for https://lists.freedesktop.org/archives/nouveau/2017-December/029337.html ?
18:23pmoreau: I’ll try mDP -> HDMI as well
18:24josef__: karolherbst: actually the safe-guard I attached does not seem to be as stable as the first one I did... :)
18:30bazzy: pmoreau: i added my notes and attachments to the bug: https://bugs.freedesktop.org/show_bug.cgi?id=88272#c5
18:30bazzy: pmoreau: I can also try mDP -> DP -> DVI
18:31bazzy: which, also has flicker
18:33bazzy: I tried with a different brand (same layout) mDP adapter, and result is the same for mDP -> DVI
18:34pmoreau: It’s interesting that you could use the card before 3.19 (with hw acceleration and with Nouveau).
18:37bazzy: why is that?
18:38pmoreau: Something like this happened to others: https://bugs.freedesktop.org/show_bug.cgi?id=27501#c48
18:39pmoreau: Though it looks like having just the 9400M was not as bad as when you also had a 9600M, where the laptop would lockup on boot.
18:40bazzy: maybe I wasn't using acceleration..?
18:42bazzy: I also used 3.18.11 until a month ago. Although I largely used nvidia-drivers during that time
18:43bazzy: most of my willingness to fix this comes from a desire to have VT. Nouveau has that part working seamlessly.
18:43pmoreau: Oh wow, that was quite the update jump then! :o
18:44bazzy: while nvidia-drivers legacy just breaks the VT support. and it seems difficult getting support for that as well
18:44bazzy: pmoreau: you're telling me!
18:45bazzy: I'm not sure if it was a good idea or not, seems on my old machine I may have made my last big update
18:45bazzy: (from a distro point of view)
18:45bazzy: but O
18:45bazzy: I'm getting off topic
18:46bazzy: so on a personal fork in the road 1) figure out noveau issue here 2) figure out nvidia-drivers VT support
18:47bazzy: I like nouveau and foss, I grit my teeth as much as possible
18:47bazzy: metaphorically speaking
18:48imirkin_: well, the reality is that nouveau tends to be improved largely by people who like foss and dislike something in the current implementation
18:48bazzy: hm, well all fingers seem like they're pointing at the nouveau module needing internal fixing, amirite?
18:49imirkin_: there's like a 99.99973% chance of that
18:49imirkin_: we're missing fiddling with some clock
18:50imirkin_: which makes the TMDS not able to keep up with the high pixclk requirements
18:50bazzy: so the next question would be what sort of knowledge / tools are required to pinpoint the issue? I've used bus sniffers and stuff in the past to get a protocol. I just need some idea of what we got to do first
18:50imirkin_: or CRTC, depending on the exact issue
18:50imirkin_: oh, nothing that complex
18:50imirkin_: you do need to have nvidia up and running, at which point you use mmiotrace to see what it does
18:50imirkin_: and then ... do that.
18:51bazzy: I hope i won't need VT-d for that
18:51imirkin_: mmiotrace captures all mmio reads/writes from the kernel module
18:51imirkin_: i dunno if it'll work all the way back to i386, but i'm sure it'll be fine with whatever hw you have
18:51bazzy: I think I enabled that already in past work
18:51bazzy: for some PCI wireless card reversing
18:52imirkin_: it's a page mapping hack
18:52imirkin_: it tries to access the page mapped to pci memory, gets a fault, and in the fault handler it single-steps the op
18:52imirkin_: not guaranteed to work in all cases, but good enough for what we use it for
18:53bazzy: by single-step you don't mean "logs the access" ?
18:53imirkin_: i mean the CPU "single step"
18:53imirkin_: used by debugging things generally
18:53imirkin_: but yes, at a high level it logs reads and writes on a particular mapping
18:54imirkin_: i was just explaining a bit the mechanism via which it does that
18:54bazzy: so would I be tracing the nvidia and nouveau and looking for differences?
18:55imirkin_: yeah, that's one way to go
18:55imirkin_: another is to look at the nouveau code and comapre it to the trace
18:55bazzy: that's the one
18:55imirkin_: of course nouveau isn't always identical to what the blob does
18:55imirkin_: so a literal diff won't get you too far
18:56bazzy: of course
18:56bazzy: unfortunately, this whole line of development is outside my comfort zone. I expect to have a lot of questions along the way
18:56imirkin_: that's something we can help with
18:57bazzy: video, xf86, gpu stuff in general
18:57imirkin_: what we can't help with is having your hardware ;)
18:57imirkin_: the nice thing is that display stuff is generally pretty well-isolated
18:57imirkin_: it has nothing to do with acceleratoin or any of that jazz
18:57imirkin_: so it's a much better constrained problem space
18:58imirkin_: unfortunately it's all handled in the kernel, so trying stuff out is something of a pain
18:58imirkin_: once you get good at it, you can unload/reload kernel module
18:58imirkin_: assuming you don't screw it up too badly
18:58imirkin_: and if you get _really_ good, you can play with skeggsb's userspace stuff which drives the hw directly using the same codebase
18:58bazzy: Then I will make notes of what my next moves will be (mmiotrace, compare with nouveau source, problem isolated to display not acceleration)
18:59bazzy: imirkin_: well i at least realized the hardware that `rmmod -f nouveau; modprobe nouveau` from inside X = reboot
19:00imirkin_: yeah, lots of bad ideas out there
19:00bazzy: s/hardware/hard way/
19:00imirkin_: here's another hint - don't attach with gdb to an X server from a shell running in an xterm against that same X server :)
19:01imirkin_: seems like such a good idea at first, but then you do it, and ... "oh oops"
19:01feaneron:did that a couple of hours ago :P
19:02imirkin_: it's one of things that you have to do once to learn to never do that again
19:02feaneron: s/xtem/gnome-terminal/ and s/x server/gnome-shell/
19:02imirkin_: yeah, the compositor thing is good too
19:02imirkin_: i ^Z'd xcompmgr running in fg to put it in bg.
19:02imirkin_: that didn't work out too well either.
19:03bazzy: just to be clear, is it safe to `rmmod -f nouveau; modprobe nouveau` from VT after killing X? is there a recommended way?
19:03imirkin_: coz guess what the VT is using.
19:04imirkin_: Look for "Deactivating KMS and unloading Nouveau"
19:04imirkin_: esp be cognisant of the "NOTE" in there relating to non-ancient hw, which you are the proud owner of.
19:08bazzy: hm there's a call trace in my dmesg after messing around plugging in different DVI adapters and DP adapter
19:08bazzy: related to hotplug
19:11bazzy: incase you're interested: https://paste.pound-python.org/show/JKJLGGtSToKYrqEJXdz8/
19:12imirkin_: was anything printed above it relating to nouveau?
19:12imirkin_: there may have been some bugs in the MST logic leaking through to things that didn't support MST, but i don't think this is it...
19:14bazzy: imirkin_: only https://paste.pound-python.org/show/W4TECQBnpoZ6tqLKrC8z/
19:14imirkin_: yeah that's unrelated
19:15imirkin_: file a bug with more details (like what you did, whether you can repro)
19:17bazzy: hey on the bright side, for unknown reasons (pstate change?), I've been able to unplug the mDP adapter without locking my system
19:20bazzy: ok i reproduced it. when unplugging the DVI cable from the mDP -> DVI/DP/HDMI adapter's DP -> DP/DVI adapter
19:22bazzy: i'm having trouble reproducing for mDP -> DVI/DP/HDMI's DVI -> DVI cable. but if I really rub the connector around as I unplug it I can get nouveau to say stuff like "EDID is invalid"
19:23imirkin_: oh, that sounds familiar
19:23imirkin_: we had some issues with zero-sized transactions
19:23imirkin_: which aren't supported by your hw at all
19:23imirkin_: but that the shared dp infra insists on emitting
19:23imirkin_: i thought a fix went into a 4.12.x kernel
19:24bazzy: I get the call stack for the mDP adapter -> DP->DVI adapter every time I unplug the DVI cable. doesn't seem to matter how i move it around when unplugging
19:25bazzy: from now on I will call the mDP -> DVI/HDMI/DP adapter Adapter A
19:25bazzy: and the DP->DVI adapter is B
19:26bazzy: laptop -> A -> B -> DVI cable is where the problem occurs
19:26bazzy: anyways I normally just go straight from A. that was just experimenting
19:27bazzy: I ought to file the bug, huh
19:30imirkin_: so this is a mini-dp adapter that has 3 different outputs
19:30imirkin_: and if you chain it with another DP -> DVI adapter, then it goes boom?
19:32bazzy: yes it has 3 outputs, if I chain it with another DP->DVI adapter it works. then if I unplug the DVI cable the kernel spits out that trace
19:32bazzy: I suppose if I unplugged the base adapter rather than DVI cable it wouldn't cause that issue
19:33imirkin_: well, all this stuff is generally pretty transparent
19:33imirkin_: unless it's an active adapter
19:33imirkin_: which it might be if it supports dual-link
19:33bazzy: my supposition is true (just tried it)
19:33bazzy: none of these adapters require ext power, if that's what u mean
19:34imirkin_: even active adapters pull power off the wire nowadays
19:34imirkin_: passive = round hole, square peg
19:34imirkin_: active = transistors that are cleverly arranged :)
19:36bazzy: I'm not sure if these adapters are transparent or active. the triple output one is a RadioShack subbrand, and the DP->DVI adapter just says HP
19:36imirkin_: you can't realy tell just by looking at it
19:38bazzy: I can't tell, but I'd like to wrap up this new bug report in 15 minutes so I can refocus on the original one
19:44bazzy: and it's late lunch time for me. (no new bug report yet) - hey i want to thank everyone for their time so far supporting my efforts with Nouveau
21:15bazzy: well I can't seem to unload nouveau without it causing a reboot, even using the script at https://nouveau.freedesktop.org/wiki/KernelModeSetting/ I'm not exactly sure what happens after the rmmod nouveau. will check the logs
21:19imirkin_: you disconnect the vtcon first?
21:19imirkin_: it helps to have a second machine
21:19bazzy: script does it. and i checked the it's the one with the framebuffer (not dummy)
21:20imirkin_: i assume X isn't still running?
21:20bazzy: right, i was testing the script right from a reboot into VT
21:20imirkin_: dunno then
21:20imirkin_: used to work
21:20imirkin_: but i probably haven't done that in ... ages
21:22bazzy: i was just hoping for a faster way to test rebuilds of the module
21:23bazzy: that's all the time i have for this today. see you later
21:56karolherbst: ... tex projections... now it gets a bit ugly
21:56imirkin_: txp is only a thing for a handful of things
21:56imirkin_: you can just lower them away in nir - i'm sure there's an option in nir_lower_tex
21:56imirkin_: there's no support for it in nvir either
21:58karolherbst: I get a txb
21:58karolherbst: that's not the issue
21:58imirkin_: yeah, so that's texture(bias)
21:58karolherbst: the issue is, that the txb just has a "varying" amount of sources
21:58karolherbst: and I have to iterate over all to know what kind of sources I got
21:58imirkin_: that's true of all texture instructions in nir
21:58imirkin_: there are various helpers.
21:58karolherbst: ohh, nice, let me check those out
21:59karolherbst: ahh, nir_tex_instr_src_index sounds nice
22:32NSA: hey, i forgot the answer to this; does nouveau support 4k@60hz?
22:51imirkin_: NSA: hdmi or dp?
22:51imirkin_: doubtful, but i dunno if it's been tried yet.
22:51imirkin_: would require HDMI 2.0-compatible hw, i.e. GTX 950 or later
22:51NSA: i got a 1070
22:51NSA: hw works, tested on windows
22:52imirkin_: yeah, i think there's more we have to do in our modesetting logic
22:52imirkin_: but i don't think anyone's RE'd it
22:52imirkin_: i do have a 4k@60-capable display at home, but no GPU that supports it
22:52imirkin_: (my inventory maxes out at a GT 730)
22:54NSA: is there anything i can do to help you by testing stuff or something like that?
22:54imirkin_: you could send a patch which enables the HDMI 2.0 support :)
22:54karolherbst: imirkin_: silly question maybe, but woud a pasiv mini DP to HDMI adapter do the trick? I don't really know if they do hdmi or DP over such a setup
22:55NSA: my screen only has hdmi
22:55imirkin_: karolherbst: on an appropriate GPU that supports HDMI 2.0, i think so yeah
22:55NSA: my gpu has some free dp ports though
22:55imirkin_: NSA: you can get an active DP -> HDMI adapter
22:55karolherbst: imirkin_: okay, then I could look into it next year
22:55karolherbst: imirkin_: just tell me what I should looking for :)
22:55NSA: i got a dp -> hdmi adapter
22:55NSA: not sure if active
22:55imirkin_: NSA: active? which can do 4k@60 with hdmi 2.0?
22:55NSA: not sure about that either
22:56NSA: but i can test and see what it does
22:56karolherbst: active shouldn't work
22:56imirkin_: anyways, if so it'll just look like a regular DP screen and everything should work
22:56karolherbst: the GPU does DP and the display gets HDMI
22:56karolherbst: to use it yes
22:56karolherbst: to RE it, no
22:56imirkin_: right :)
22:56imirkin_: i meant to use it ;)
22:56karolherbst: I have an active adapater though
22:56karolherbst: as well
22:56imirkin_: i.e. what NSA wants to do
22:56NSA: how do i know whether it's active?
22:57karolherbst: NSA: it probably isn't
22:57imirkin_: plug it in, see if the screen comes up as DP-n or HDMI-n
22:57karolherbst: because otherwise you knew
22:57NSA: it's just a cable with hdmi one side and dp on the other side so i guess passive
22:57karolherbst: NSA: and the active ones usually cost around 20$+ maybe more like 30
22:57karolherbst: NSA: well my adapter also doesn't look like much
22:58karolherbst: electronics are pretty small these days
22:58imirkin_: cost is a better indicator than size
22:58karolherbst: NSA: but usually the cheap ones are passiv and everbody who doesn't know better buys the cheap ones
22:58NSA: yeah i just checked
22:58NSA: it's for 1080pm only
22:58NSA: according to where i bought it
22:58karolherbst: so it does 1.4 at most
22:58karolherbst: HDMI that is
22:59karolherbst: it should be able to do 4K at 30Hz
22:59NSA: but that's cancer
23:00karolherbst: just saying
23:00NSA: i guess i'll just stick to fullhd on that screen
23:00NSA: dpi scaling on linux sucks anyways
23:01imirkin_: fwiw, that's what i do with my 4k screen too -- not like i have 4k content anyways
23:01NSA: when i used windows i had it set to 150% scaling
23:01NSA: which gives me a lot more space
23:01NSA: which is absolutely worth it
23:02imirkin_: mine's a tv, so ... really just for watching movies.
23:02NSA: mine's basically a tv too
23:02NSA: i don't use it as tv tho
23:02NSA: 28" 4k
23:02NSA: next to me 24" 1080p screens
23:03imirkin_: 65" for me :)
23:03imirkin_: i.e. a lot more like a TV :)
23:03NSA: you can easily use 65" without input scaling
23:04NSA: 4k on 28" without scaling is basically unusable
23:05NSA: oh, seems like gnome actually does have fractional scaling as experimental feature
23:05NSA: now the question is should i buy an active 4k hdmi dp adapter
23:06imirkin_: depends on whether you want to use nouveau with that screen or not. i suspect that this will be working in less than 6 months time with regular HDMI 2.0.
23:06NSA: it's €16 for such an adapter
23:06NSA: i do want to use nouveau with it
23:07NSA: wayland + nvidia is cancer
23:07NSA: awful performance
23:07imirkin_: yeah, but wayland means you _really_ need accel to operate it, and i dunno if nouveau on the 1070 will really get you enough of a working situation
23:07imirkin_: esp since the only way to do X things is to use glamor
23:08imirkin_: using GL to implement all the X operations
23:08NSA: i've already been using wayland for about 2 months
23:08imirkin_: it's a sound concept, just nouveau's 3d stuff can sometimes fall short of the mark
23:08NSA: with 3x1080p on a gtx750ti
23:08NSA: i often had xwayland eat 100% cpu on one core
23:09NSA: xorg is unable to do fractional dpi scaling tho
23:09imirkin_: i think pascal has some extra bugs (or same bugs as maxwell, just more visible)
23:09NSA: and it isn't able to scale only one screen
23:09NSA: oh wow
23:10NSA: fucking sellers
23:10NSA: put 4k support in product title
23:10NSA: only 30hz in desc
23:10imirkin_: very little effort has gone into making maxwell and pascal work perfectly
23:10karolherbst: NSA: actually scaling isn't that bad anymore
23:10NSA: karolherbst: what do you mean?
23:11karolherbst: well my laptop has a 4K screen internally
23:11NSA: scaling can't do per-screen scaling in xorg afaik
23:11karolherbst: and most of the stuff just looks fine
23:11karolherbst: NSA: mhh, well, right. This is one of the painful things
23:11NSA: yeah, that's my problem
23:12imirkin_: yeah, you can only have one DPI setting per X Screen
23:12NSA: first one i found with 4k60hz is €35
23:12karolherbst: I doubt that gets fixed like ever
23:12karolherbst: I think such things are left for wayland
23:12imirkin_: thoroughly unlikely
23:12NSA: yeah that's why i'm using wayland
23:12karolherbst: but, is this even solved in wayand?
23:12NSA: per screen dpi? yes
23:13NSA: i've tested with 4k30hz 200% scaling
23:13NSA: other screens weren't scaled
23:14karolherbst: only variable indexing and I am done with the glsl-1.10 tests for nir :)
23:14NSA: what's nir?
23:14karolherbst: some fancy stuff
23:15karolherbst: kind of required to get vulkan support for nouveu
23:16NSA: i can find mini-dp to hdmi 2.0 4k60hz for just €12.38
23:16NSA: that'd need another dp->minidp though
23:17karolherbst: you won't
23:17karolherbst: the one I bought cost 30€
23:17NSA: i won't what?
23:17karolherbst: but it was an active one as well
23:17NSA: this is active mini-dp -> hdmi 4k60hz
23:17karolherbst: I am sure you won't find a good adapter for that price, you really want an active one if you want to use it with nouveau
23:18karolherbst: good luck with it then :) sometimes they have crappy quality, but you should check how good they are
23:18NSA: 2 ratings claiming it works
23:18imirkin_: and 10 claiming it doesn't? :)
23:18NSA: only 2 total
23:18karolherbst: there are just 2 ratings
23:19karolherbst: well most of the time it is fine
23:19karolherbst: but sometimes it isn't
23:19imirkin_: coz the vendor paid to have them taken down...
23:19karolherbst: and sometimes you have really odd issues
23:19imirkin_:has a lot of trust in reviews, as you can see
23:19NSA: i don't trust reviews either
23:20NSA: i'm pretty sure amazon will refund though if the product doesn't do what it's supposedly doing
23:20NSA: *supposed to be
23:21karolherbst: ahh crap.. I actually need to implement that mask things for textures now... :( I hope too much that I can ignore the more complicated things for much later
23:21NSA: actually for €1 more i can get regular dp to hdmi https://www.amazon.de/dp/B07548RVLR/
23:21imirkin_: karolherbst: nvir should auto-figure-out the masks iirc
23:22karolherbst: that would make it easier
23:22feaneron:starts to actually wonder if karolherbst ever sleeps, or is a bot, or perhaps advanced ai
23:22karolherbst: allthough I didn't saw something related to masks
23:22imirkin_: feaneron: probably does, in the same timezone as you
23:23karolherbst: feaneron: I decided to not comment on your "wondering"
23:23NSA: should be arriving on the 23th
23:23NSA: i'll report back whether it works
23:24feaneron:doesn't know if that's an automatic bot response, a converged nlg response, or a honest comment
23:25NSA: i'm really too tired
23:27karolherbst: feaneron: but seriously, why do you think that :O
23:27feaneron: because, in all honesty, no matter when i look in this channel, there is a message of yours
23:28feaneron: my sleep schedule is completely broken, and i often pop up at weird times
23:28NSA: feaneron: maybe it's just that other people don't talk enough to push away his messages
23:28NSA: what's sleep?
23:28feaneron: (didn't mean any offense)
23:29karolherbst: mu sleep schedule got totally weird as well though...
23:30NSA: someone wants a layers of fear steam key? 9CTWV-F4XX3-ZQZXP
23:30NSA: it's currently free on humblebundle
23:30NSA: incl soundtrack (extra key)
23:31NSA: saturday i can tell you whether the active adapter works :)
23:37karolherbst: mhhh, mhhh interesting
23:37karolherbst: TGSI has TXP for the projection stuff
23:37karolherbst: but nir has no special opcode for that
23:37karolherbst: ohhh wait, I think I did a mistake somewhere, let me check
23:37imirkin_: that means it's pre-lowered
23:38imirkin_: i thought it did though
23:38imirkin_: might just be a regular texture with a projector argument
23:38karolherbst: I totally didn't check the writemask of the projector
23:39karolherbst: allthough, it doesn't make sense in this case, weird
23:39imirkin_: projector is divided into the s,t,r arguments
23:39karolherbst: I have to apply the projector only to the cords in the test I fail
23:40karolherbst: not the biars
23:40karolherbst: ohh wait
23:40karolherbst: it never gets applied to the bias, right?
23:42imirkin_: no it does not.
23:42imirkin_: projector is for the coords
23:43karolherbst: okay :)
23:43imirkin_: i'd highly encourage you to peruse the various texture man pages
23:43imirkin_: and try to gain an understanding of wtf all this stuff is
23:43imirkin_: it's ... wildly complicated at first
23:43imirkin_: but eventually you kinda get the gist of wtf all this stuff is talking about
23:44karolherbst: yeah, at some point I really should do that
23:46robclark: fwiw, maybe it was pointed out already (I didn't read whole scrollback) but nir_lower_tex has lower_txp (and various other things that may or may not be useful)
23:47imirkin_: i did point it out, but not sure if karolherbst saw it.
23:47imirkin_: all this stuff gets pretty confusing when you have no idea wtf a projector is :)
23:47robclark: (and if it misses something, let me know what other sorts of lowering that nv needs.. I can take a stab, I've written a bit of nir lowering bits before)
23:47karolherbst: robclark: yeah, I saw the lower function and all teh options
23:47karolherbst: I don't need those until now
23:48karolherbst: or so I think
23:49karolherbst: imirkin_: the comparator needs the projector applied as well
23:49imirkin_: for shadow?
23:49imirkin_: that's ... surprising.
23:50karolherbst: tgsi does it as well
23:50imirkin_: The texture coordinates consumed from P, not including the last component of P, are divided by the last component of P.
23:50imirkin_: so ... yeah.
23:50imirkin_: since the shadow ref comes in via P
23:51imirkin_: karolherbst: docs.gl is nice :)
23:51karolherbst: there aren't many texture tests in the glsl spec tests, are there?
23:52karolherbst: well there are a few
23:52karolherbst: I should include tests/texturing then in my piglit run
23:53karolherbst: but first I want to fix the spec@glsl ones, because I am nearly finished with that
23:53karolherbst: except for compute and geometry shaders that it
23:54karolherbst: ahh glsl 1.30 texture fun
23:54karolherbst: miplevels :)
23:54karolherbst: and all the other fancy features
23:54karolherbst: robclark: it is kind of fun to work with nir :)
23:55karolherbst: and when looking at the stuff done for the tgsi pass, I am wondering if tgsi is really that horrible to work with or I just leave out a lot of the required complexity
23:58imirkin_: you leave out a lot of the required complexity.
23:58imirkin_: but there's definitely some dirt in tgsi too