00:01imirkin: heh. got pixmark piano to load by disabling LoadPropagation. sadly the shader is a pile of fail.
00:01imirkin: oh wait. i'm a pile of fail. grr
00:01enyc: imirkin: can your firmware be updated?
00:01imirkin: enyc: "my firmware"?
00:02enyc: yes, whatever part of it failed ;p
00:02imirkin: [93248.771058] nouveau 0000:04:00.0: gr: TRAP_MP - TP3: 00000010 [LOCAL_LIMIT_WRITE]
00:03enyc: raises interesting questions about 'state of nouveau' and what to expect (or not!)
00:04imirkin: odd. i don't even use that much local mem...
00:04imirkin: enyc: the state of nouveau is "get an amd gpu"
00:07Tom^: imirkin: lies, it works wonders here.
00:08enyc: imirkin: hrrm they now have fully open drivers as the rule rather than exception ????
00:10imirkin: and full time staff to support the driver, with access to docs and hw designers
00:14enyc: imirkin: im curious now... this nouveau setup drives both 'similar' gpus without xinerama
00:15enyc: imirkin: this simply will not work with e.g. nouveau + mga driver at same time ?
00:15imirkin: it should work fine
00:15imirkin: assuming that mga has a kms driver
00:25Sophira: I have what is probably a really stupid question.
00:25Sophira: For the EFI vars persistent storage to work, I'm guessing you need to have booted Linux via UEFI and not the BIOS emulation, right?
00:26Sophira: Yep. Figured as much. Time to redo the way I boot then, I guess.
00:26Sophira: (I don't like moving to new technologies just because they happen to be new, so I wait until there's a reason for me to move, generally. This is a good reason.)
00:59Sophira:converts her boot drive to GPT.
02:28Sophira: Looks like everything went well. GPT conversion, fstab update, grub recompile/install for EFI, temporary BOOTX64.EFI file because I wasn't booted into a UEFI environment to set things up... I'm happy it worked first time.
02:38Sophira: ...hmm. Odd. I'm still not seeing anything in /sys/fs/pstore after I mount it. I know I have the kernel configured for it, on both the kernel that's not working and this one.
03:42imirkin: the more i think about this the less i understand it
04:55Hydr0p0nX: running a gtx650 in rhel7 and X crashes with the nouveau driver, if I install the binary driver or put an AMD card in at the same time and use radeon and nouveau drivers, both displays work as expected ...
05:07Tom^: Hydr0p0nX: isnt rhel7 using a very old kernel and ddx ?
05:08Tom^: seeing as you are trying a relatively new gpu, it probably isnt the best combinations.
05:08Hydr0p0nX: gtx650 is at least 3 yrs old now
05:08Hydr0p0nX: maybe 4
05:10Hydr0p0nX: but yea, it's running 3.10.0-327.28.2 , which is older than i thought
05:10Hydr0p0nX: really surprised it's that far back
05:11imirkin: you'll be hard-pressed to get open-source support for anything but the latest kernels
05:12imirkin: hunting long-solved issues isn't a ton of fun
05:13Hydr0p0nX: yea, like I said, I didn't realise the kernel was that far behind for "current" redhat
05:14Hydr0p0nX: I'm just using it as a kvm host and passing the radeon through to one of the guests, since it's that far back and I haven't really gotten much else configured, i may end up moving to another distro
05:55enyc: imirkin: hrrm theres is a CONFIG_DRM_MGA in kernel for the g550... but not asfar as I can tell, modesetting ;-(
06:08imirkin: enyc: well, modesetting isn't required. the X ddx driver just has to support the relevant things for offloading to work
06:08enyc: imirkin: krenl drm driver you mean?
06:09imirkin: X ddx driver
06:09imirkin: it's all inside X ... i'm not sure that it has the concept of drm or not drm, etc
06:11enyc: what happnes as you try to mix kms-managed nouveau and non-kms mga? is it possiblo to have part of the screen not accelerated, or it tends to drag the whole 'x screen' down?
06:14imirkin: the way the output offloading works is that the whole image is rendered on a single gpu
06:15imirkin: and the remainder just provide outputs which scan out that image
06:19enyc: i wonder what approach nvidea "base mosaic" setting uses
06:20imirkin: probably something that's nvidia-only...
08:53maysha: i can't change that resolution of 640x480
09:57karolherbst: imirkin: ../nvidia_shaderdb/gputest_pixmark_piano/7.shader_test - type: 1, local: 0, gpr: 50, inst: 3591, bytes: 32832
09:58karolherbst: 50 gprs for me
10:36karolherbst: mhh, no perf changes for nouveau in bioshock between 12.0.1 and master
13:01karolherbst: mhhh okay, the upclocking after thermal downclock works differently than the downclocking :/
13:13karolherbst: this table makes less sense any second
13:33Sophira: karolherbst: Hi :)
13:34Sophira: How are things?
13:34karolherbst: bad, stupid table in vbios doesn't make much sense
13:35karolherbst: well I could also added a "to me" in the sentence :p
13:35karolherbst: luckily I asked gnurou for this table
13:38Sophira: I spent a couple of hours last night converting my OS to boot from UEFI, but pstore still isn't showing anything for me.
13:38Sophira: (I did recompile both my working kernel and the non-working one.)
13:38karolherbst: well, it will only add new things
13:38Sophira: I know.
13:38karolherbst: I see
13:38Sophira: I did boot from it.
13:38Sophira: But even after coming back, still nothing.
13:39karolherbst: and you sure boot within efi mode?
13:39Sophira: Yep. There's no MBR to boot from any more.
13:39karolherbst: dmesg | grep -i efi
13:39karolherbst: uhh, do you still have nouveau builtin?
13:39Sophira: Seven lines, want me to paste them?
13:40Sophira: I never had nouveau builtin, it was always being built as a module.
13:40karolherbst: "[ 0.887673] pstore: Registered efi as persistent store backend" something like that?
13:40karolherbst: mhh k
13:40Sophira: [ 12.839228] pstore: Registered efi as persistent store backend
13:40karolherbst: 12 :O
13:40karolherbst: when is nouveau loaded?
13:40Sophira: Yep. There's no MBR to boot from any more. 14.234482] nouveau 0000:01:00.0: NVIDIA GM204 (124020a1)
13:40Sophira: Bad paste, sorry.
13:40Sophira: 14.234482] nouveau 0000:01:00.0: NVIDIA GM204 (124020a1)
13:41karolherbst: pstore won't work if nouveau is loaded before it is registered
13:41Sophira: (missing a char too, heh)
13:41karolherbst: looks fine though
13:41karolherbst: could you once boot on 4.6 with nomodeset enabled?
13:42Sophira: Oh wait.
13:43Sophira: Actually, no, I won't be able to do that any more. Since switching to UEFI, when it boots, the screen just freezes on the grub "Loading linux-4.4.6..." or whatever it says, with the kernel still working in the background, until the modesetting driver initialises.
13:43karolherbst: enable efifb
13:44Sophira: I think I already have that builtin, but let me check.
13:45Sophira: Never mind, I didn't. Recompiling now.
13:45karolherbst: you can remove vesafb if you still have it though
13:46Sophira: I didn't.
13:48Sophira: Okay, both kernels recompiled, booting into 4.6.5.
13:54Sophira: That's odd, I mustn't have selected the right driver, since it still froze. The kernel was definitely responding with nomodeset though; I was able to use CTRL-ALT-DEL to initiate the reboot sequence, which I wasn't able to do before. (I've had to use the magic SysRq S-U-B combination before now.)
13:54Sophira: The option you want is FB_EFI, right?
13:54karolherbst: but if it booted it is good
13:54karolherbst: that means you have logs
13:54Sophira: Oh, true.
13:54karolherbst: using systemd?
13:54Sophira: No, OpenRC.
13:54karolherbst: then check your log files for dmesg :p
13:55Sophira: Okay, hang on. Anything I'm looking for in particular?
13:55karolherbst: no idea
13:55karolherbst: pasting the entire dmesg somewhere might make sense
13:56Sophira: Okay, this would be a good time to check pstore, since in 4.6 I deliberately had the kernel messages go to pstore too so I could check if that worked.
13:56karolherbst: you have to mount it though
13:56Sophira: Just did.
13:57Sophira: And still nothing :( Gah. Okay, looking at logs. I'll probably paste the entire syslog for that boot, it's easier and will have dmesg in it anyway.
13:57Sophira: (pastebin, obviously)
13:57karolherbst: mhh odd. I slowly get the feeling that pstore only works on my system...
13:58karolherbst: well, I get only kernel crashes in it, but that's all what I care about in the first place
13:59karolherbst: Sophira: do you have efivarfs mounted?
14:00Sophira: (up there for 1 week)
14:01Sophira: No. Is that necessary? I think I turned that off in the kernel because I heard about the whole thing where the kernel would interpret unlinks to mean "wipe the EFI vars completely".
14:01karolherbst: mhhh, well you need builtin efivars support for being able to save pstore stuff in efi
14:02karolherbst: odd, efifb isn't loaded in your log
14:02Sophira: That would explain it then.
14:02karolherbst: mhh maybe you miss something, let me check
14:03Sophira: I can get you my .config if you want to check that.
14:04karolherbst: I have CONFIG_DRM_FBDEV_EMULATION enabled, no idea if that's needed here
14:04Sophira: sophie@home /usr/src/linux-4.6.5-gentoo $ grep FBDEV .config
14:04Sophira: I'll pastebin my .config :)
14:05karolherbst: this sounds important
14:08Sophira: I'll enable EFIVAR_FS, anyway.
14:10karolherbst: ohhhh wait
14:10karolherbst: you have a desktop right?
14:10karolherbst: mhh maybe you have to plug in your desktop on the onboard ports to get something
14:10karolherbst: no clue how that is handled through the gpu
14:11Sophira: I'm using a desktop, yes.
14:11karolherbst: could you blacklist nouveau and remove nomodeset?
14:11Sophira: And thinking about it, I shouldn't need EFIVARS_FS to be able to get stuff from pstore. After all, efibootmgr was already able to manipulate the EFI vars so that it books from /EFI/gentoo/grubx64.efi, right?
14:11karolherbst: and then try to see if that changes anything, if not you could try out the onboard ports
14:12Sophira: I'm not sure what you mean by 'onboard ports', though.
14:12karolherbst: no clue to be honest
14:12karolherbst: aren't there any ports on your machine which aren't on the gpu?
14:12karolherbst: like a vga port or something
14:12Sophira: Oh. No, this mobo doesn't have onboard graphics.
14:12Sophira: Asus X99-S.
14:13karolherbst: do you have a second machine which you are able to use for ssh?
14:14Sophira: Yeah, good call. Yes - my phone. :) I'll set it up so I can SSH in before I reboot.
14:14karolherbst: :D, using phones for ssh is pretty annoying though
14:14Sophira: Yeah. I do have a laptop but its fan is bad, so I don't want to use it.
14:22Sophira: Okay, all set up and ready to reboot. I'll test rebooting in 4.4.6 first to make sure it's blacklisted okay, then go into 4.6.5. With luck my next line will be from in 4.6.5, though I'll be SSHing in on my phone so apologies for any slow typing :)
14:25Sophira: karolherbst: Okay, I'm in.
14:26Sophira: Screen is still stuck on "Loading Linux 4.6.5-gentoo ...", but I'm SSHed in okay.
14:27Sophira: What did you want me to try?
14:27karolherbst: do you have a directory inside /sys/class/vtconsole/ ?
14:28Sophira: Yes, vtcon0.
14:29Sophira: A symlink.
14:29karolherbst: cat vtcon0/bind
14:29karolherbst: allthough, vtcon0/name should be dummy
14:30karolherbst: mhh, could you boot with video=efifb
14:30Sophira: "(S) dummy device"
14:36Sophira: In, no change except that screen now shows " Booting a command list" before the 'Loading' bit. dmesg | grep efifb only shows matches in "Command line" and "Kernel command line".
14:37karolherbst: the hell :/
14:37karolherbst: mhh maybe that's a grub thing though
14:37karolherbst: do you use grub2?
14:38Sophira: I was editing the commands manually to include it before boot.
14:41karolherbst: do you have anything fancy in your grub config?
14:42Sophira: No, it's just straight output from grub-mkconfig.
14:43karolherbst: mhh no clue what that contains, I don't use grub
14:43Sophira: Hang on. I'll unblacklist and come back on 4.4.6 so I can Pastebin it.
14:45Sophira: Never mind, thought maybe doing a blind login/startx might help, but nope.
14:48karolherbst: I don't get why efifb won't load :/
14:49Sophira: Okay, I unblacklisted and am back on the computer on 4.4.6.
14:49Sophira: Gonna check the kernel config.
14:49karolherbst: cat /sys/module/pstore/parameters/backend
14:50karolherbst: should give you efi
14:50Sophira: It does.
14:50Sophira: (Though remember I'm booted into 4.4.6 right now)
14:50karolherbst: yeah, but it should be the same on 4.6 too, cause it appeared in the log
14:50Sophira: But I've been recompiling both my kernels to have the same options.
14:51karolherbst: mhh okay, then we have to try that over ssh, though it will get really super messy
14:51karolherbst: boot 4.6 with nouveau blacklisted
14:51karolherbst: ssh into it
14:51karolherbst: dmesg -w &
14:51Sophira: Stupid question, would tar zcvf /newsys.tar.gz /sys work? :)
14:51karolherbst: modprobe nouveau
14:52karolherbst: Sophira: uhhh, bad idea
14:53Sophira: Hmmm. Documentation/fb/efifb.txt says efifb is only for EFI booted Intel Macs.
14:53Sophira: This isn't a Mac.
14:53karolherbst: I don't have an intel mac too
14:53karolherbst: but it works
14:53karolherbst: or at least used to
14:53karolherbst: maybe somebody broke it
14:54Sophira: Thought I'd throw that out there just in case, since it seemed like it might have been the problem :D
14:54karolherbst: I highly doubt it
14:55karolherbst: I would assume grub is the problem with the fb handoff somehow
14:56Sophira: Quite possible.
14:58karolherbst: could you enable CONFIG_FB_SIMPLE: on 4.6 and boot with nouveau blkacklisted?
14:58karolherbst: still having fb_efi enabled
14:59karolherbst: "EFI Framebuffer"
14:59Sophira: Okay, one sec.
15:01Sophira: Yeah, reading the help that must be what it is.
15:01Sophira: Recompiling now.
15:02karolherbst: have to update my kernel too :D
15:02karolherbst: lucky that i915 never broke here
15:04Sophira: Okay, rebooting. Hopefully no SSH needed this time :)
15:05tobijk: karolherbst: you said you had nice general pupose benchmarks somewhere?
15:06karolherbst: tobijk: general purpose?
15:06Sophira: Woot! I'm in. I deliberately haven't used startx, I'm still in the framebuffer console for now.
15:06tobijk: in the sens of it utilizes the whole range of available instructions :D
15:06karolherbst: finally some progress
15:06karolherbst: tobijk: no clue :D
15:06Sophira: I guess now I should try modprobe'ing nouveau and taking a photo of the panic :D
15:06karolherbst: Sophira: you can startx
15:07karolherbst: efifb is quite powerfull for a fb driver
15:07Sophira: Well, I wanted to stay in the console so that I could see the panic, since it won't show up in X.
15:07karolherbst: ahh k
15:07karolherbst: best if you do this:
15:07karolherbst: dmesg -w &
15:07karolherbst: modprobe nouveau
15:08Sophira: I assume modprobe won't load blacklisted modules so I need to remove the blacklist first, right?
15:08Sophira: Oh will it just work?
15:08karolherbst: it will just work
15:08Sophira: (Well, 'work'.)
15:08karolherbst: blacklist is for auto loading
15:08Sophira: Brb, then Will take a photo if it stops responding.
15:08tobijk: karolherbst: another approch: a good benchmark software to run :D
15:09karolherbst: tobijk: gputest has several micro benchmarks
15:09karolherbst: for avrious things
15:09karolherbst: there is like everything in it
15:09Calinou: not open source though
15:09karolherbst: shader compiler, cpu overhead, fillrate
15:09Calinou: doesn't it bias for certain manufacturers too?
15:09karolherbst: no clue
15:09Calinou: we can't know :]
15:09karolherbst: it is too simple for that
15:09karolherbst: pixmark_piano has like 60 calls in total per frame
15:10karolherbst: and a badass big shader
15:10tobijk: Calinou: even if it biases for certain manufecturers, i want to test mesa against mesa with a change :)
15:10karolherbst: I highly doubt that gputest is biased
15:10karolherbst: it is too simple for that
15:10karolherbst: and to bias microbenchmarks is kind of hard
15:12Sophira: I forgot that when the hang happens, the monitor goes into a power-saving mode so I can't read the dmesg ;p I guess this is something I'll have to do over ssh anyway.
15:12karolherbst: so we get a fb handover
15:13Sophira: Unfortunately I can't screenshot on my phone for some reason, it's annoying. I'll do what I can though.
15:13karolherbst: the problem with ssh is, that the network goes down too fast
15:14Sophira: You're right, it would.
15:14Sophira: I'll see how much gets flushed anyway.
15:15Sophira: In fact.
15:15karolherbst: maybe you could just try out 4.7? .D
15:16Sophira: Thinking about it, "dmesg -w & > baddmesg.txt" is likely to contain more information, right? I'll try both, I think, we'll see whether disk I/O or network I/O gets flushed faster :)
15:16karolherbst: compile a 4.7 kernel first
15:16karolherbst: maybe it is an issue fixed already
15:16karolherbst: do you have linux-firmware 20160628 installed?
15:17Sophira: I generally don't use that package, I've been doing "make firmware_install" on the latest Linux version I compile.
15:17karolherbst: you need it for maxwell2
15:17Sophira: Should I be using the package instead?
15:17karolherbst: it is required as in required
15:18Sophira: Huh. So there's a difference between the two?
15:18karolherbst: especially this commit: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/nvidia?id=c4f6a36d694bc4dbaeb6c9edae4889b4af2659ce
15:18Sophira: Maybe I should try that then before compiling 4.7. :D
15:18karolherbst: well, don't be surprised if it works with that installed though :p
15:18karolherbst: you want 4.7 anyway
15:19karolherbst: nouveau fixes
15:19karolherbst: especially with the firmware stuff too
15:19Sophira: Going to reboot back into 4.4.6 for now because the simple framebuffer seems to be designed for a 4:3 aspect ratio and it looks stretched on my 16:9 screen.
15:19karolherbst: it shouldn't though
15:20tobijk: simplefb should modeset just fine
15:20Sophira: I guess maybe I need to tell grub the correct resolution, then.
15:20karolherbst: cat /sys/class/graphics/fb0/modes
15:20Sophira: sophie@home ~ $ cat /sys/class/graphics/fb0/modes
15:20Sophira: So yeah.
15:20Sophira: This is a 1920x1080 monitor.
15:20karolherbst: cat /sys/class/graphics/fb0/name
15:21Sophira: sophie@home ~ $ cat /sys/class/graphics/fb0/name
15:21Sophira: I'll look for something in the grub config :)
15:21karolherbst: maybe disable simplefb and disable that mark as generic framebuffer option then
15:22Sophira: Are you sure? I mean, simplefb just takes an already initialised framebuffer.
15:22Sophira: Which in this case would have been initialised by grub, right?
15:22karolherbst: you really want that efifb thing
15:23karolherbst: I think it would be also able to drive two displays
15:23karolherbst: or so
15:23Sophira: I don't have two displays right now, but yeah.
15:27Sophira: It looks like I can also force grub to switch to text mode before booting, so if I did that we'd at least get rid of the issue of it freezing.
15:28karolherbst: mhhh, might work, no clue
15:28Sophira: Will do some testing :)
16:07Sophira: Sorry about that, was called away.
16:07Sophira: I've found something really interesting though - the kernel isn't actually panicking in 4.6.5.
16:08Sophira: It's just spending a really long time in kernelspace.
16:09karolherbst: firmware loading?
16:09Sophira: The dmesg went fine to a file. Isolating out the nouveau startup now, but this looks like either a kernel bug or some firmware thing, yeah. So I'll try the firmware package soon too.
16:10Sophira: wwwThe monitor never actually comes up, but ssh was good throughout.
16:10karolherbst: could you paste the dmesg then?
16:12Sophira: Was just doing that :D
16:12tobijk: damn gputest does not contain my pattern :/
16:12karolherbst: read fault at 00ffb90000 engine 1f  client 03 [DNISO] reason 0d [REGION_VIOLATION]
16:13karolherbst: Sophira: could you upload your vbios somewhere? /sys/kernel/debug/dri/0/vbios.rom
16:13Sophira: Does it matter which kernel I'm on when I do that?
16:13karolherbst: well I doubt that you have that with 4.4
16:13karolherbst: but you could check
16:13karolherbst: does that mean anything to anybody? "fifo: read fault at 00ffba0000 engine 1f  client 12 [PMU] reason 0d [REGION_VIOLATION] on channel -1 [0000000000 unknown]" imirkin, skeggsb ^
16:14imirkin: that means you have a GTX 970 with 4GB of vram
16:14karolherbst: I feared as much already
16:14Sophira: I do have that file on 4.4.6, and the vios.rom file when copied is 180224 bytes.
16:14karolherbst: Sophira: do you have a gtx 970 with 4 gb of vram?
16:14karolherbst: I thought you had a gtx 950
16:14Sophira: Nope, it's a 970.
16:15karolherbst: imirkin: I think I know why that issue exist though
16:15karolherbst: the 970 is one of those stupid cards with 3.5GB + 0.5GB regions
16:15Sophira: Did I say I had a 950? I'm pretty sure I had said it was a 970. Hang on, checking logs just to make sure I didn't screw up. If I did, I'm really sorry.
16:15imirkin: and nouveau totally doesn't handle that properly
16:16karolherbst: workaround would be to just address 3.5GB?
16:16imirkin: i have no additional information
16:16imirkin: ben said he was working on a fix
16:16pmoreau_: Anyone can tell me why I got banned from #dri-devel?
16:16karolherbst: pmoreau_: beacuse your name most liekly?
16:16karolherbst: I think you need a registered name
16:16pmoreau_: It is a registered one
16:16Sophira: Well, honestly, all this is kinda invalid anyway since I need to start using the proper linux-firmware package.
16:17karolherbst: Sophira: yeah, but that won't help :/
16:17Sophira: So let me see if I can reproduce this with linux-firmware and 4.7.
16:17karolherbst: annoy skeggsb for a fix :p
16:17imirkin: pmoreau_: you sure you're banned? this is the ban list: http://hastebin.com/esixovexov.mel
16:17imirkin: Sophira: doesn't matter, nouveau won't work on a 970 with 4GB of vram right now. (at least not with acceleration)
16:17Sophira: It's odd how nouveau works properly in 4.4.6 but not in 4.6.5, though.
16:17karolherbst: pmoreau_: you aren't logged in
16:18imirkin: Sophira: in 4.4, no acceleration. problem solved ;)
16:18imirkin: Sophira: you can boot with nouveau.noaccel=1 nouveau.nofbaccel=1 to "fix" it
16:18karolherbst: that also expalins why pstore didn't work out
16:19Sophira: karolherbst: Not completely. Like I say, one of the things I have enabled on the 4.6 kernel is PSTORE_CONSOLE, which is supposed to log *all* kernel messages to pstore.
16:20pmoreau_: imirkin: When I wanted to change nick, I got "pmoreau #dri-devel :Cannot change nickname while banned on channel", and when I wanted to post "#dri-devel: Cannot send to channel"
16:20Sophira: But that wasn't happening.
16:20karolherbst: pmoreau_: leave dri-devel first, then change nickname?
16:20pmoreau_: karolherbst: Yeah, will try that
16:20Sophira: pmoreau_: That might actually not be a ban, just a +e on the channel. Likely the channel might also be +m?
16:21Sophira:doesn't know, isn't in that channel.
16:22karolherbst: pmoreau: you could use SASL instead to get around those issues though
16:23pmoreau: I am quite sure I had that configured. I must have messed up something while trying to add another IRC server to the bouncer, to access the LLVM channel.
16:23imirkin: karolherbst: btw, the pixmark piano shader has spilling. adjust your setup until that happens :) [hint: update shader-db]
16:23karolherbst: mhh now you are logged int
16:23karolherbst: imirkin: mhh, k..
16:24imirkin: at least i'm like 99.999% sure
16:24imirkin: you can double-check with apitrace
16:25Sophira: (Did you still want that vbios.rom file, btw?)
16:25karolherbst: 50 gprs
16:25karolherbst: Sophira: that was for imirkin
16:25karolherbst: and yeah, I still want your vbios
16:25Sophira: Ah, okay.
16:26karolherbst: imirkin: "../nvidia_shaderdb/gputest_pixmark_piano/7.shader_test - type: 1, local: 0, gpr: 50, inst: 3755, bytes: 34336" with updated shader-db
16:26Sophira: (taken from 4.4.6, but I assume it's kernel-independent)
16:26karolherbst: gm206 right?
16:26imirkin: karolherbst: ok, well make an apitrace and see what happens when replaying it
16:27Sophira: It's a GTX 970. I don't know. Is that GM206 or GM204?
16:27imirkin: it should say at the top of the nouveau messages
16:27imirkin: along with the amount of vram
16:27Sophira: [ 66.960703] nouveau 0000:01:00.0: NVIDIA GM204 (124020a1)
16:27karolherbst: Sophira: wanna try out a dirty fix?
16:27Sophira: [ 67.046603] nouveau 0000:01:00.0: fb: 4096 MiB GDDR5
16:28Sophira: karolherbst: Sure.
16:28Sophira: If it won't brick my card ;p
16:29imirkin: karolherbst: the LTC is all off on those. i doubt clamping to 3.5GB will be enough. should be enough to get a basic load going, but later stuff will probably be all b0rked
16:29karolherbst: we will see
16:29karolherbst: might the MmuDebugBufferSize option help?
16:31Sophira: (quick question - do I need to delete the contents of /lib/firmware before installing linux-firmware, or is it safe to go over the top?)
16:31karolherbst: wait, wrong place
16:31karolherbst: Sophira: should be safe
16:32Sophira: Oh, heh. Never mind, I do have it installed already. Don't remember when I installed that, but 20160331 is there. Will reinstall anyway in case I accidentally did a "make firmware_install" over the top of it at some point.
16:32karolherbst: you need the newer versions
16:32Sophira: But you said I wanted 20160628.
16:32karolherbst: 20160616 might work too
16:33karolherbst: but I would install the newest
16:33Sophira: =sys-kernel/linux-firmware-20160628 ~amd64
16:33Sophira: Installing :)
16:35imirkin: live a little... drop the version number from the unmask ;)
16:36karolherbst: Sophira: could you boot with nouveau.debug=debug the next time on 4.7?
16:36Sophira: You want me to go to -99999999 too? :P
16:36karolherbst: Sophira: <9999 ;)
16:37karolherbst: and then you could even use the savedconfig USE flag to only install what you need
16:37imirkin: Sophira: i meant just sticking "sys-kernel/linux-firmware ~amd64" into packages.keywords
16:37Sophira: imirkin: I know.
16:38imirkin: the 9999 version is hard-masked, requires an explicit unmask somehow iirc
16:38Sophira: I was just wondering if you wanted me to go right up to the edge as well as 'living a little' ;p
16:38imirkin: the 9999 versions are annoying
16:38karolherbst: it needs a ** keyword
16:38imirkin: generally not worth it ime
16:39karolherbst: ohh wait...
16:39karolherbst: nvm me
16:39Sophira: Generally when it comes to kernels I like to make sure I'm explicitly wanting the update instead of accepting all new updates.
16:39imirkin: fair enough
16:39Sophira: gentoo-sources doesn't count because you have to compile it manually anyway.
16:40imirkin:just has a separate linux git tree symlinked to /usr/src/linux
16:40Sophira: I did a shallow clone of the Linux git tree once, and even that was huge.
16:40imirkin: about 2GB iirc
16:41imirkin: you can share the .git dir between multiple workspaces
16:41imirkin: linux $ du -sh .git
16:41imirkin: 1.5G .git
16:41Sophira: If you really want to try big git repos, go clone https://anongit.gentoo.org/git/repo/gentoo.git :) (That's the /usr/portage tree as held in git :P)
16:42imirkin: thanks but ... no thanks
16:42Sophira: I wonder if anybody actually has the full git history of that anywhere.
16:43Sophira: Well, obviously there, but you know what I mean.
16:52Calinou: Xonotic Git is huge too
16:53Calinou: easily over 10-12 GB for all repos
16:53Calinou: probably 15 GB by now
17:00Sophira: Configuring 4.7.0. Do I need the PCIE_DPC option to be set?
17:01karolherbst: Sophira: I think I have
17:01karolherbst: Sophira: I doubt oyu need that option
17:02karolherbst: I don't have it
17:02Sophira: Okay. Thought I'd check that option specifically because it could potentially have made a difference, but good to know it doesn't.
17:05imirkin: Sophira: that stuff tends to be "you only need it if you know you need it" types of things
17:05s0be: lol, the xfce-sensors package doesn't deal well with dri_prime. When the discrete gpu gets put to sleep, it shows it at 1C
17:05karolherbst: s0be: xfce-sensors fault
17:05s0be: yeah, I know.
17:05karolherbst: sensors should show N/A I guess
17:05s0be: I just thought it was funny
17:06karolherbst: devs never were at the antarctica I assume
17:06s0be: "my gpu is 25C below ambient right now"
17:06imirkin: that's what i call power efficiency!
17:06s0be: imirkin, prolly charging my battery for me
17:06imirkin: using ambient heat to power itself
17:06karolherbst: a fridge is also cold, but draws a lot of power :p
17:06imirkin: karolherbst: are you sure? i thought fridges actually powered the power grid...
17:06karolherbst: pretty sure, yeah
17:07karolherbst: nobody really goes on with stuff like that :/
17:07karolherbst: of course you have to convice me, that I was wrong, duh
17:10Sophira: imirkin: Understood. I think it requires a driver, anyway. But I wanted to double-check here simply because being a PCIe-specific option there was a non-zero probability of it making a difference.
17:26Sophira: Okay, I've compiled 4.7.0 and used grub-mkconfig to put it in my boot menu.
17:26karolherbst: do not forget nouveau.debug=debug ;)
17:27Sophira: I won't :) I assume that just outputs extra messages to dmesg?
17:31Sophira: Okay, I put that as an argument to be applied to all kernels, because it seems like it'd be useful.
17:31karolherbst: it does print a lot though
17:32Sophira: I may remove it later, but for now when debugging nouveau it's just easier to have it on all the time, I'd guess.
17:33Sophira: Is there anything more I need to know before I reboot?
17:35Sophira: Okay, will reboot then :) Brb.
17:37Sophira: Okay, simplefb works. Still 1024x768, but, meh.
17:37karolherbst: ohh still having simplefb
17:38Sophira: Oh, should I have disabled that?
17:38karolherbst: you should rather remove it and disable CONFIG_X86_SYSFB
17:39Sophira: I'm still not entirely sure this is going to work, mind you, but we'll see.
17:39imirkin: oh yeah, that thing actively breaks stuff
17:39imirkin: definitely disable it
17:39karolherbst: imirkin: it works if you enable fb_simple
17:39Sophira: (efifb didn't seem to want to work properly for me on 4.4.6 and 4.6.5, hence why we enabled it)
17:39karolherbst: Sophira: it didn't work because sysfb was enabled
17:40imirkin: can you access the bios and see it on your monitor?
17:40imirkin: do you see stuff in grub?
17:40imirkin: if so, efifb should work
17:40imirkin: (or gummiboot or whatever)
17:41karolherbst: sysfb was enabled, in that case efifb won't work
17:41Sophira: Okay, will disable that too then.
17:42Sophira: Building again without simplefb and X86_SYSFB :)
17:42Sophira: Done, rebooting.
17:44Sophira: I'm in. Looks exactly the same, but fb0/name is now "EFI VGA". fb0/modes is "U:1024x768p-75".
17:44Sophira: (This is without nouveau loaded)
17:44karolherbst: weird efifb
17:45Sophira: Glad it worked though, thanks for that tip.
17:45karolherbst: does grub show stuff in your native resolution?
17:46Sophira: I don't *think* it is, but it's hard to tell.
17:46karolherbst: then most likely grub messes it up
17:47Sophira: Right, that's what I thought. I had tried messing with the options in /etc/default/grub for it though and it didn't seem to make a difference. Though it doesn't particularly matter, it's just a bit annoying. :)
17:47Sophira: In most use I'd be using nouveau anyway.
17:47Sophira: In any case, I'll look at it more closely next time I reboot.
17:48Sophira: Anyway, will log in by SSH now, set up the "dmesg -w"s, and modprobe nouveau.
17:52Sophira: Same thing happened as before. Going to pastebin the dmesg now.
17:55karolherbst: 4 memory parts each with 1GB
17:55karolherbst: I thought there would be 5
17:55karolherbst: 3x 1GB + 2x 0.5GB
17:56karolherbst: Sophira: did you update the linux-firmware package?
17:57Sophira: Yes, it's on 20160628 right now.
17:57Sophira: I haven't "emerge --sync"'d in a few days though if it matters.
17:57Sophira: Only a couple of days though.
17:58karolherbst: Sophira: drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
17:58karolherbst: around line 567 should be something like "u32 parts = nvkm_rd32(device, 0x022438);"
17:58karolherbst: could you change that to "u32 parts = 3;"?
17:59Sophira: Yep, I see that line, right on line 567. Changing it now.
17:59karolherbst: there is nearly no chance that this might work, but it is worth a shot
17:59Sophira: (This can't brick my card, right?)
17:59karolherbst: I don't think any dev here ever bricked a card through nouveau
18:00imirkin: i think the bricking tends to happen to motherboards, through excessive plug/unplug cycles
18:01Sophira: New kernel compiled and installed. Will get back to you with a new dmesg :)
18:05Sophira: karolherbst: So you know how you said there was nearly no chance it would work? Well, you got it right. It works. :)
18:05Sophira: Uploading the new dmesg from a working nouveau in 4.7.0 :)
18:06karolherbst: well it might break somewhere else, but as long as it does somewhat work
18:06imirkin: unfortunately "limps along" may be more accurate. i guess i'm not super plugged into the details...
18:07karolherbst: Sophira: you could start X and run glxinfo
18:07karolherbst: just to see what happens
18:07Sophira: Already in X. Let's see...
18:07karolherbst: should work I think
18:07karolherbst: secboot doesn't complain
18:08karolherbst: imirkin: I think we shouldn't touch the last 512MB on those gpus anyway
18:08karolherbst: imirkin: because it requires smart driver handling otherwise perf sucks big times
18:09karolherbst: huh, no nouveau in mesa...
18:09karolherbst: Sophira: did you compile mesa with the nouveau flag?
18:09Sophira: Yes. I see this in my Xorg.0.log:
18:09Sophira: [ 143.083] (II) [drm] nouveau interface version: 1.3.1
18:09Sophira: [ 143.083] (EE) Unknown chipset: NV124
18:09Sophira: [ 143.083] (II) modeset(0): using drv /dev/dri/card0
18:09Sophira: [ 143.083] (WW) Falling back to old probe method for fbdev
18:09karolherbst: also softpipe is kind of wrong
18:09Sophira: (with the first couple of lines repeated a few times)
18:09karolherbst: Sophira: remove xf86-video-nouveau
18:10karolherbst: imirkin: mesa would have to track access to the last 512MB and move rarely accessed stuff there. kind of like kernel swapping :/
18:11karolherbst: I doubt anybody here really wants to implement that
18:11tobijk: heh we do not really swap to ordinary ram, let alone swapping to a specil portion of vram :>
18:12karolherbst: the 3.5GB have a 224bit interface the 512MB only 32bit afaik
18:12Sophira: Okay, back. Going to unmerge xf86-video-nouveau now.
18:13karolherbst: Sophira: do you have libdrm 2.4.70 installed?
18:13karolherbst: what use flags are set on mesa?
18:13Sophira: Looks like I must have ~amd64'd that.
18:14Sophira: home mesa-12.0.1 # cat USE
18:14Sophira: abi_x86_64 amd64 classic dri3 egl elibc_glibc gallium gbm kernel_linux nptl udev userland_GNU video_cards_nouveau
18:14Sophira: (from /var/db/pkg/media-libs/mesa-12.0.1 )
18:14karolherbst: you can remove classic
18:14karolherbst: but otherwise it looks fine
18:15karolherbst: odd, why doesn't glxinfo picks up nouveau
18:15karolherbst: mind posting your entire Xorg.log?
18:16Sophira: BTW, in case it matters, I had made sure to unset the "llvm" and "opencl" flags because they brought in packages that conflicted; see https://bugs.gentoo.org/show_bug.cgi?id=587026
18:16karolherbst: you can enable llvm though
18:16karolherbst: that gives you faster software opengl
18:17karolherbst: softpipe is kind of slow
18:17Sophira: Unless it's required I'd rather make sure that the driver works before doing that, because of the conflicts.
18:17karolherbst: I meant without opencl
18:17karolherbst: just llvm
18:18karolherbst: but compiling llvm takes a while
18:18karolherbst: so you can do that later
18:18Sophira: I already have llvm installed.
18:18Sophira: That's the thing :)
18:18karolherbst: I see
18:19Sophira: libclc required <3.6.
18:19karolherbst: cause you don't have ~amd64 set :p
18:19karolherbst: 0.2.0_pre20160209 works with 3.7
18:20karolherbst: X log :p
18:20Sophira: Eh. I like to use stable packages except where necessary.
18:23karolherbst: ahh I know
18:23karolherbst: Sophira: rebuild xorg-server with glamor USE flag set
18:24karolherbst: and I would also suggest to update to 1.18
18:24karolherbst: 1.17 might work though
18:24karolherbst: but there were many glamor improvements in 1.18
18:24karolherbst: and you need glamor
18:25Sophira: Gah, had to restart X. Enlightenment froze again, I think.
18:25Sophira: (I may need to switch WM.)
18:25karolherbst: did you get my message regarding glamor?
18:26Sophira: I'll give glamor a go in 1.17.4 and see how it goes.
18:28Sophira: Doing an 'emerge -auDN @world' so that both the mesa -classic and xorg +glamor USE flags take effect.
18:28Sophira: Oh, right.
18:28Sophira: I should probably take 'nouveau' out of VIDEO_CARDS too.
18:28karolherbst: -classic will only save you a bit of time though ;)
18:29karolherbst: Sophira: nope, you need it for mesa
18:29Sophira: karolherbst: Ah. Because it wants to reinstall xf86-video-nouveau. Is that a problem?
18:29karolherbst: Sophira: package.use: x11-base/xorg-drivers -video_cards_nouveau
18:29karolherbst: that simple
18:30Sophira: So -classic isn't necessary, then?
18:31karolherbst: only for swrast, nouveau_viex (pre nv50 I think) and i965
18:31Sophira: Okay. Will just leave it in for now then - my computer's pretty beefy so it's not a huge add to compile time.
18:32karolherbst: well I wanted to say, classic is just needed for those above
18:32karolherbst: it just reduces code size for you if you disable it
18:33Sophira: I'm not overly concerned about removing stuff I don't need, to be honest, unless it's an actual problem.
18:33Sophira: Anyway, xorg-server and xorg-drivers are compiled now.
18:33Sophira: Restarting X, brb.
18:35Sophira: Okay, glxgears gets about 50fps maximised now. It was previously getting about 13fps.
18:36karolherbst: my intel card gives me 640 fps :p
18:36karolherbst: but even without reclocking 50 fps is kind of low
18:37Sophira: It is low, yeah.
18:37Sophira: I know for a fact it should be getting a lot better.
18:37Sophira: But hey.
18:37Sophira: I guess it's an improvement ;p
18:37karolherbst: well, it looks all good now
18:37karolherbst: nouveau is actually used now
18:38karolherbst: imirkin: got the gtx 970 with 4gb running :p
18:38karolherbst: Sophira: sadly, nouveau can't control the fans on your gpu, so trying to reclock it is pointless
18:39karolherbst: Sophira: vblank_mode=1 glxgears
18:39karolherbst: try that
18:41Sophira: Okay, that gives me figures in the 150-180fps range. But if I'd had to guess the FPS just by looking at it I'd have said it was running at 40-45fps.
18:41Sophira: Actually, maybe more like 30-40fps.
18:41karolherbst: well your display only seems to run at 50hz
18:41karolherbst: check xrandr
18:41Sophira: Maybe setting my compositor to a hardware mode now would help...
18:42Sophira: 1920x1080 60.00*+ 50.00 59.94
18:42Sophira: (from xrandr)
18:42karolherbst: mhh odd
18:42karolherbst: well maybe your compositor did stupid things then
18:42Sophira: Yeah. Going to go that up now.
18:44Sophira: Hmm. When I try to set the Enlightenment compositor to use OpenGL instead of Software, a dialog comes up saying my display driver doesn't support OpenGL, GLSL shaders, or that no OpenGL engines were compiled or installed for Evas or Ecore-Evas. *looks into it*
18:45Sophira: ( http://matrix.theblob.org/compositor.png )
18:45karolherbst: maybe you compiled it without opengl support or glx
18:47Sophira: It doesn't have a flag for that. But you know what, let me put in 'opengl' in my make.conf USE flags and see what needs recompiling.
18:48Sophira: Ah yes, that'd do it.
18:49Sophira: (cairo, efl and libwebp were the packages that needed recompiling, and efl is Enlightenment-related)
18:53Sophira: Looking at this there's actually a lot in efl I need to enable USE flags for.
18:54karolherbst: well, you could try out mesa-9999 at some point, that might rule out a lot of maxwell2 related issues you may encounter in the future and as I said: xorg-server 1.18 + dri3 might resolve other issues
18:54karolherbst: but at least it is kind of working now
18:57Sophira: Damn, efl upstream must hate the Gentoo devs. Gentoo disables so many things by default and the compile process complains about a lot of the things that are disabled.
18:57Sophira: For example:
18:57Sophira: "You have chosen to disable physics support. This disables lots of core functionality and is effectively never tested. You are going to find features that suddenly don't work and as a result cause a series of breakages. This is simply not tested so you are on your own in terms of ensuring everything works if you do this"
18:57Sophira:goes through and re-adds the stuff that should be enabled.
18:58karolherbst: everybody hates gentoo, cause those are the guys with annoying compile issues and weird configurations :D
18:58karolherbst: there were also times where everybody with gentoo in the name got an instant IRC ban
18:58karolherbst: in specific channels
19:00Sophira: To be fair, this is why the Gentoo devs keep telling people that bugs should be reported to bugs.gentoo.org, not upstream :)
19:00karolherbst: I usually don't do this, cause it isn't their fault, except if that's gentoos fault I report there :p
19:01Sophira: The Gentoo devs *want* you to report bugs there, though.
19:01karolherbst: for patches, I know :/
19:07Sophira: Not just for patches; they can report things upstream.
19:07karolherbst: well I can also report things upstream
19:08pmoreau: I’ll have to investigate this "nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]" on my GK104, it’s getting annoying!
19:08karolherbst: pmoreau: I think RSpliet tried to solve some gr firmware issues though
19:08karolherbst: pmoreau: I guess you are already running my branch?
19:09pmoreau: Indeed, I am running your branch. Maybe not the very latest version, but a decently recent one
19:09karolherbst: pmoreau: mhh, one thing: what is your clock you have set while this happens? Maybe this is the one instable high engine clocks issue
19:09imirkin: karolherbst: in #debian? :)
19:09imirkin: [the gentoo ban]
19:09karolherbst: or does it also happen randomly on 07?
19:09karolherbst: imirkin: no clue anymore :D I think there were more
19:10pmoreau: I should be on the lowest one, let me check. But I also have the issue on stock 4.7 without any reclocking.
19:10karolherbst: but gentoo guys usually start to troll in #debian I think :D
19:10karolherbst: pmoreau: I see
19:10karolherbst: pmoreau: maybe if you reclock to 07 it is better
19:10imirkin: trolling is a lot easier than fixing issues.
19:10karolherbst: pmoreau: once somebody got a super unstable gpu unreclocked, but reclocked with my branch to 07 helped
19:10imirkin: i still don't have a clear idea in my mind why the spill code is wrong
19:10pmoreau: karolherbst: Yep, 07 it is, and I did reclock to it.
19:10karolherbst: imirkin: well, you know, debian and being stable ;)
19:11imirkin: i've found a way to not break it, but the thing is that the old code should work too
19:11imirkin: so... more investigation necessary
19:11karolherbst: mhh no idea either, it doesn't spill for me, this is what I know
19:11imirkin: also even with all the various fixes, including disabling LoadPropagation, it pixmark_piano still hangs
19:11karolherbst: pmoreau: k, then I am out of ideas
19:11imirkin: i think it's hitting the watchdog
19:12imirkin: or it's hitting that "i'm gonna stop running shaders after a while for no apparent reason" issue
19:12imirkin: anyways, it's good that i'm fixing core compiler issues
19:12karolherbst: odd, pixmark_piano doesn't have that high impact on the gpu in total
19:12imirkin: but i think ultimately pixmark_piano won't run
19:13pmoreau: karolherbst: No problem, I’ll try things later. Maybe using the blob’s grctx.
19:13karolherbst: pmoreau: there are some bugs in bugzilla regarding this though
19:13karolherbst: and for some blob grctx didn't help
19:13imirkin: karolherbst: what do you mean by "doesn't have that high impact on the gpu"?
19:14karolherbst: the gpu stays usual cool
19:14pmoreau: karolherbst: I’ll browse through the bugzilla as well, good idea
19:15imirkin: karolherbst: huh odd. that means we suck at something important.
19:15karolherbst: "only" 55W here
19:16karolherbst: furmark goes above 70W
19:16karolherbst: imirkin: well it doesn't use anything memory related, at all (pixmark_piano) that is
19:16karolherbst: so that reduces the power consumption by a significant amount already
19:17karolherbst: I think, that this is the reason at least
19:18karolherbst: pmoreau: https://bugs.freedesktop.org/show_bug.cgi?id=93629
19:18karolherbst: one example
19:18karolherbst: there are more though
19:22Sophira: imirkin: There have been people wanting the Gentoo devs to make it easier for people to ban Gentoo users, too.
19:23karolherbst: Sophira: in general I don't like downstream bug trackers that much, cause the decs of the actual projects get annoyed, because they don't deal with the user having that bug directly and a lot of time is spent in communicating the entire thing
19:23karolherbst: Sophira: right :D I remeber
19:25karolherbst: that last patch though
19:26karolherbst: Sophira: do you know this already? https://fun.irq.dk/funroll-loops.org/
19:26imirkin: oh 2004.
19:26imirkin: good times.
19:27imirkin: my (limited) experience is that filing bugs in gentoo is effectively identical to sending them to /dev/null, so i tend not to bother
19:28imirkin: a few did get resolved a decade later
19:30Sophira: Okay, efl recompiled with extra goodies, and a small tweak to my kernel settings to make PulseAudio happy (apparently it prefers 2048kB prealloc buffer on HD Intel cards)
19:35karolherbst: Sophira: well if you don't need those fancy pulse features, you can always go with alsa-dmix
19:37Sophira: Okay, rebooted. glxgears is lovely and smooth now, though it could do with some vsyncing. It now seems to be capped to 60fps; I'm getting values of 59.999.
19:37Calinou: vblank_mode=0 glxgears
19:37karolherbst: good :)
19:37Calinou: Nouveau forces vsync by default
19:37karolherbst: Calinou: we know ;)
19:37karolherbst: Calinou: but before it was capped at 50 fps
19:37Sophira: Huh. I was seeing tearing when I ran it, though.
19:38karolherbst: Sophira: that's cause of the compositor
19:38karolherbst: usually you have some kind of two staged tearing prevention
19:38karolherbst: 1. application side 2. window side
19:39karolherbst: it is messy and even more annoying on prime offloaded systems
19:39karolherbst: dri3 helps
19:39Sophira: Okay, with vblank_mode=0, I see FPS values of ~400 or so when maximised.
19:39karolherbst: now we are getting somewhere
19:39tobijk_: karolherbst: dri3 makes it worse for me :)
19:39karolherbst: tobijk_: update your x server :p
19:39tobijk_: no use ^^
19:39karolherbst: on multi display systems you actually need dri3
19:39karolherbst: otherwise any besides your main display tears
19:39Sophira: (I also un-blacklisted nouveau for this reboot, since we know that the patched version works.)
19:40karolherbst: 400 fps is kind of in the range I would expect from your gpu in the current state
19:40karolherbst: so I guess it is all fixed now
19:40Sophira: Looks like it!
19:41karolherbst: I get only 640 fps with nouveau :/ stupid slow pcie bus
19:41Sophira: I mean, I'm pretty sure I've had glxgears results in the thousands years ago with the binary nvidia drivers and older cards, but still :D
19:42tobijk_: mh i never really tested glxgears with vblank off
19:42tobijk_: hey 655 fps :)
19:42karolherbst: Sophira: like this? 55871 frames in 5.0 seconds = 11174.102 FPS
19:42Sophira: Probably. I'd need to dig out my glxgears outputs to be sure.
19:43imirkin: Sophira: you're in the lowest power state for that gpu...
19:43karolherbst: I think she is already aware of that
19:43Sophira: Yeah, karolherbst mentioned that there was no point in trying reclocking, I think.
19:43karolherbst: if you like a hot GPU, we could still reclock this beast
19:44karolherbst: never actually tried to reclock memory on a maxwell2
19:44imirkin: on my very shitty GK208, at the highest perf state, i get 7.5K fps, while in its low state (which isn't that low actually), it's 3.2K fps
19:44Sophira: I'm fine for now. We'll see once I start getting around to doing actual 3D stuff on here.
19:44Sophira: But yeah.
19:44karolherbst: imirkin: we run here at fullscreen glxgears on fullhd :p
19:45karolherbst: Sophira: it might be worth keeping an eye on sensors
19:45imirkin: the other thing is that glxgears isn't exactly taxing, so it's not a great test of things
19:45karolherbst: or have a sensor applet in the task bar
19:47Sophira: Hmm, that bad? Okay.
19:49imirkin: Sophira: moral of the story: next time, buy amd.
19:49tobijk_: or intel if you dont care for high performance :)
19:50Yoshimo: imirkin: that would be too easy.
19:52tobijk_: imirkin bought the most nvidia hw to tinker with anyway, here in the channel :D
19:53imirkin: tobijk_: i think my lifetime spending on nvidia hw is in the $200 range
19:53Tom^: i dont think i even wanna know how much ive spent
19:53tobijk_: you made a good pile of hw out of that :D
19:53Sophira: Still interested in helping out the nouveau project though. This wasn't *just* an attempt to get as much FPS as I can and then leave ;)
19:54imirkin: tobijk_: and that counts the $100 i spent on a G96 back when those were cool
19:54Sophira: Definitely interested in debugging why nvkm_rd32 returns a value that doesn't work on my machine.
19:55Sophira: (unless you already know why, of course)
19:56imirkin: skeggsb is taking care of it
19:56Sophira: Ah, okay.
19:56imirkin: it's beyond the combined knowledge of everyone else in the channel
19:56Sophira: What can I do, then?
19:57tobijk_: test skeggsb's attempts and give feedback
19:57imirkin: for this specific issue? nothing. wait patiently for ben to work it out.
19:58imirkin: if you're looking to contribute to nouveau in general
19:58imirkin: there are a bunch of fairly simple-to-implement features that GM20x has added that you could work on exposing in mesa
20:00tobijk_: imirkin: do you know the specifics for the lscadd instruction or where i can read about them? :>
20:00imirkin: tobijk_: ISCADD
20:00imirkin: not L
20:01imirkin: tobijk_: it's a << b + c
20:01imirkin: where b is an immediate
20:01imirkin: very useful for implementing address calculations like a * 4 + c
20:01imirkin: or a * 16 + c
20:01Sophira: Hmm. lm_sensors only detected two things on my system, apparently.
20:02Sophira: imirkin: That sounds good to try doing.
20:02imirkin: yeah ... some of us have just been lazy
20:02imirkin: i think hakzsam was thinking of looking at it
20:02tobijk_: imirkin: actually id still like to try improving n*3 = a<<1 +a
20:02imirkin: but he has other things to do as well
20:03imirkin: tobijk_: would that really improve things?
20:03imirkin: maybe it would. not sure.
20:03tobijk_: i have found several shaders which utilize exactly that
20:03imirkin: it's moderately common for imul to be super slow, but dunno if it is on nvidia gpu's
20:04tobijk_: not sure if it improves but if an iscadd instruction is the outcome for general purpose, why not
20:04Sophira: Oh, there is actually something I meant to say earlier but didn't. I got some glitchiness on the framebuffer before running startx on this boot. Let me upload a photo.
20:05imirkin: tobijk_: shift + add comes up a lot for address calculations, so it's definitely useful
20:05tobijk_: imirkin: mul in general is as fast (or slow) as shl+add
20:06imirkin: i guess i could convert those into IMAD... dunno
20:06imirkin: i think there's some deal where IMAD is slow. or perhaps we just schedule it wrong.
20:07tobijk_: within the pipeline you mean?
20:07imirkin: mofos. 35 degC outside.
20:08imirkin: someone needs to invent a personal airconditioning unit.
20:08imirkin: like a helmet or something
20:08tobijk_: move over here (20°C) :D
20:09imirkin: greenland? :)]
20:09Tom^: 12C here
20:09tobijk_: Tom^: you have "summer" there? :D
20:09Tom^: winter is coming.
20:10Tom^: tobijk_: july and june.
20:10imirkin: 6C in yakutsk...
20:10imirkin: maybe i'll move there
20:11Tom^: im about on the same latitude as yakutsk, only i got the gulf stream
20:11Tom^: which makes it somewhat decently livable
20:11imirkin: yakutsk is a city of 200k...
20:12karolherbst: yay, my internet is back!
20:12tobijk_: too small for you? :>
20:12karolherbst: damn isp
20:12imirkin: wow. 270k in 2010
20:12Tom^: it still has like -35 to -45 temps in winter
20:12tobijk_: karolherbst: KD that bad? :/
20:13Tom^: we only have those in rare special days. the rest its hoovering around -15 to -20
20:13karolherbst: for a week I get a daily disconnect from my isp
20:13imirkin: Tom^: where are you?
20:13Tom^: imirkin: way up north in sweden
20:13karolherbst: Sophira: ohh, I know a lot of things how you could help out :p
20:13imirkin: ah ... there was a google office somewhere around those parts
20:13imirkin: some L-starting city
20:13Tom^: facebook one in luleå
20:14Tom^: right in my town :P
20:14imirkin: yeah, that's the one.
20:14imirkin: (perhaps it closed)
20:14imirkin: can't be too many large cities in northern sweden
20:14Tom^: well what do you define as large?
20:14Tom^: 20k+ ?
20:15karolherbst: my home town is 20k+ and it is frigging small
20:15imirkin: "larger than the surrounding towns"
20:15karolherbst: sure, why not
20:16tobijk_: <-- 3k and its cosidered a city :O
20:16Sophira: Here we go - there's some framebuffer glitchiness visible in this photo: http://matrix.theblob.org/fb-glitchiness.jpg . Notice how the bottom of my login username and 'startx' is cut off at the bottom, and there are blue/green bits at the center-right of the screen. (the blue/green bits are leftovers from OpenRC's bootup sequence, I'm fairly sure)
20:16imirkin: Today we are doing the same thing in Austin, Texas; Trondheim, Norway; and Lulea, Sweden
20:16imirkin: i guess i haven't been staying on top of it :)
20:17imirkin: Sophira: probably one of the results of LTC being messed up
20:17Sophira: I'm not sure what that is.
20:17imirkin: Sophira: although sometimes i've seen odd things in fbdev, so could be some genero issue
20:17imirkin: LTC = L T C. some sort of framebuffer compression thingie
20:18imirkin: nvidia calls it it LTC so we call it LTC.
20:18Tom^: i like it how they rabble bunch of countrys and then all of a sudden mentions luleå. a puny city with like 70k people
20:18imirkin: Tom^: i guess there's a good university there? i remember when that office opened in ... 2007 or so? a few people moved there.
20:19tobijk_: mh if i'd be biased, i'd say my change makes unigine valley 1% faster :D (no there is no noise at all)
20:20imirkin: tobijk_: the numbers may not support this, but i'd say my changes improve things by 100000% :)
20:20tobijk_: exactly my point, just work the numbers, until they work for you :D
20:21imirkin: when you see someone messing with confidence intervals, you know they *really* have nothing
20:21imirkin: (i mean, messing with the confidence levels of those intervals)
20:23Tom^: behold its magnificence http://www.ltu.se/cms_fs/1.106130!/img/img/lul%C3%A4%C3%A4%C3%A4.jpg_gen/derivatives/landscape_800/lul%C3%A4%C3%A4%C3%A4.jpg
20:24imirkin: that looks quite nice :)
20:24tobijk_: don't you have a really high mountain of mining overhead there? :D
20:27Tom^: nah the mountains are ~200 kilometers or so away. its quite flat at the coast
20:27tobijk_: then i misremembered that, apologies :>
20:29Tom^: tobijk_: http://imgur.com/a/JuvUE however i did go fishing with my boat two weeks ago up in the mountains. :P
20:30tobijk_: looks really nice, but cold :)
20:33imirkin: ok. CRAP. *now* i really understand the issue in the spill code.
20:33tobijk_: yaaay, if thats true an i ever meet you, one beer on me :)
20:34imirkin: the issue is that we do the stupid join thing in the coalesce logic
20:34imirkin: and then we try to spill the "main" lval, but that leaves all the joined-to lvals "in the dark" about the spilling
20:35imirkin: so then when RA fails and we try to undo it, we're left with random BS in there
20:36imirkin: i blame calim
20:37imirkin: compilers are hard
20:38tobijk_: yeah, even a trivial compiler for a c like language without optimizations gave me a hard time for a while :)
20:50tobijk_: imirkin: so you just try to fix it by splitting the values right again?
20:50imirkin: tobijk_: well, i'm debating if my current "fix" is the right one
20:50imirkin: which is ... just don't remove the instruction
20:51imirkin: remove it from the BB, but don't free it
20:51imirkin: which means that the lval->defs list for both lvals will point to a non-freed ValueDef
20:52tobijk_: just add a "dead_defs" bool and you are godo to go ;-)
20:53imirkin: the problem is that the list in LValue is to ValueDef*, and the ValueDef belongs to the instruction
20:53imirkin: so if i don't remove it from a list, then i'm pointing to freed memory
20:54imirkin: this is also why spilling from flags to regs is wonky
20:54imirkin: it's all coming together now
20:55tobijk_: a temporary list with the molten away instructions maybe
20:56imirkin: and then what
20:56imirkin: without scanning all lvalues, i don't know what the "other" lvalue is
20:56imirkin: which i can obviously do
20:56imirkin: i guess that's not the worst thing
20:57imirkin: but this issue leads to a lot of fragility everywhere, not just here
20:58imirkin:will think some more on this
21:00tobijk_: mh or just dup the complete insns and their values, try to ra, if it does not work restore (yeah ugly as hell)
21:01imirkin: well, the alternate solution is just "don't delete the instructions"
21:01imirkin: the downside is that now lvalues will have pointers to "dead" instructions in the middle.
21:01imirkin: which is easy to recognize, just ... suboptimal.
21:02imirkin: and makes me question where else i need to fix this up
21:03tobijk_: try to find it right after ra and reorder it there...where else do you mean?
21:04imirkin: yeah, that means i scan all the lvalues
21:04imirkin: like i said, not the worst thing in the world...
21:04imirkin: i might just do that.
21:04tobijk_: we dont care for fast compile times :)
21:05imirkin: yeah, by the time we're spilling, it's already not-great.
22:02Sophira: I'm noticing some really weird issues on my 4.7.0 config. When I'm in X, text will have random characters disappear when I'm scrolling around in some things. It's happening most often in Leafpad but I just had it happen in Firefox too. I just rebooted back to 4.4.6 (which of course doesn't have the hardware acceleration going) and it seems to be okay there. (It's normally really easy to see in Leafpad.)
22:03Sophira: It's probably behaviour that I can screenshot. Let me see...
22:03imirkin: accel vs not accel
22:04imirkin: until ben comes out with a proper fix, i wouldn't worry about it
22:04Sophira: No need for the screenshot then?
22:04imirkin: i mean... i definitely wouldn't know what to do with it
22:04imirkin: skeggsb should be around soonish... should be able to get a status update
22:05imirkin: (he's in AU)
22:05skeggsb: status update on?
22:05Sophira: I might ask him if he needs any data points from another card.
22:05imirkin: skeggsb: GTX 970 + 4GB
22:05Sophira: Oh, hi :)
22:05skeggsb: well, i'm still waiting on nv to answer me atm..
22:05imirkin: skeggsb: ah ok =/
22:06imirkin: skeggsb: any interim thing for people to test, or it's some core issue?
22:06imirkin: skeggsb: seems like the 4GB GTX 970 is pretty popular, so there's an increasing crowd of people with issues
22:06skeggsb: i need to know some more details to properly be able to detect the situation
22:07skeggsb: either info from nv, or more examples of such a configuration would work, but, the latter is sorely lacking
22:08Yoshimo: isn't it common for videocards to have 4gb and more these days?
22:08skeggsb: not ones where some of the vram isn't as capable as the rest
22:09Sophira: If you need any help or data, I'm also running a 970 with 4GB, which I've got working (with the help of karolherbst) on 4.7.0. (We had to adjust drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c and edit the gf100_ram_ctor function to set the 'parts' variable to 3, as it wasn't working otherwise.)
22:09Yoshimo: so it is not 4 but rather 3+1 with different types?
22:09imirkin: Yoshimo: it's a situation specific to those GTX 970's
22:09imirkin: not to 4GB in general
22:09Yoshimo: so with a 980 i am not affected?
22:09imirkin: Yoshimo: not by this issue, no
22:10skeggsb: hmm, i could probably hack something up to drop the entire partition if it has disabled ltcs i guess - for now
22:11skeggsb: i'll ping nv again today and see how that goes first
22:11Sophira: In case it helps, here's the dmesg from the unpatched 4.7.0 kernel with me modprobe'ing nouveau manually: http://pastebin.com/msJh5gRJ
22:11Sophira: But yeah.
22:12imirkin: skeggsb: i think that'd be nice... karol made a hack for Sophira to ignore the last partition, but she's still having issues. i'm guessing it's because he missed a few details around it.
22:13Sophira: Well, to be fair, it's mostly working. There's just some glitchiness.
22:14imirkin: Sophira: btw, what version of mesa are you on?
22:17imirkin: ok, that's fine
22:17imirkin: just wanted to make sure it wasn't the gentoo stable one, which tends to be quite far behind
22:17Sophira: (Sorry for the delay. For a moment I was really confused because it showed that I didn't have it installed and I knew I did, but I realised I was connected to a different computer ;p)
22:18Sophira: For the record:#
22:18Sophira: media-libs/mesa ~amd64
22:18Sophira: x11-libs/libdrm ~amd64
22:18Sophira: =sys-kernel/linux-firmware-20160628 ~amd64
22:18Sophira: =sys-kernel/gentoo-sources-4.7.0 ~amd64
22:22pmoreau: Yay, finally taking into account the opcode for defining the input(s) signedness