07:23 pmoreau: Phew, I thought I had created an infinite loop in my code somehow, but no, it’s only the GPU locking up due to the code being run.
07:47 Tom^: is that a good or bad thing? =D
08:09 pmoreau: Tom^: Well, good thing, cause finding where the infinite loops happens would have been a real PITA
08:10 pmoreau: Now, I just need to understand why the GPU does not like that code.
08:51 pmoreau: And I broke everything that was already working, but now I know (at least partly) why.
09:56 t-ask: siro__: hi, did that patch work at your place (Gw2 name hiding)?
09:57 siro__: t-ask: I check my apitrace file and GW2 itself, it's fixed for me
09:58 t-ask: siro__: then I assume, I did something wrong
10:22 t-ask: siro__: Do you have time to investigate this via pm?
10:42 siro__: t-ask: yes of course
11:02 siro__: is it possible to read current clock frequency on kepler using sysfs ?
11:03 karolherbst: siro__: only through debugfs pstate
11:03 karolherbst: currently
11:04 siro__: karolherbst: the pstate shows min / max value. how do I know which one is used ?
11:04 karolherbst: last line
11:07 siro__: AC: core 405 MHz memory 7009 MHz
11:07 karolherbst: you are on stock nouveau, right?
11:08 karolherbst: you should get some volting fails in dmesg
11:08 siro__: i've set pstate 0f
11:09 siro__: nouveau is spamming dmesg, wait a sec
11:09 karolherbst: current nouveau code can't volt kepler cards without errors, so you need a branch of mine
11:10 karolherbst: git: https://github.com/karolherbst/nouveau.git
11:11 karolherbst: "reclocking_part_1" or "stable_reclocking_kepler_v5" branch
11:11 karolherbst: the latter contains some more experimental things, like dropping voltage on higher temperature and such stuff
11:55 pmoreau: I really need that temporary register to properly split a 64-bit MUL/MAD it seems…
11:55 pmoreau: So, split64BitOpPostRA is not the place to do it.
11:59 karolherbst: pmoreau: is there any reason not to do that while in SSA form?
12:02 pmoreau: Probably not, I put it over there in the first place, since it was there that other 64-bit operations are split.
12:02 pmoreau: (Or at least some of them)
12:02 karolherbst: mhh
12:03 pmoreau: But those others don’t need extra registers, so it’s all fine.
12:03 karolherbst: well, afaik this is much easier to do in SSA, cause you don't need to mess with register usage
12:03 pmoreau: Definitely! :-)
12:05 pmoreau: Should I do the splitting before or after the constant propagation pass? It doesn’t matter too much I guess
12:05 karolherbst: mhh
12:05 karolherbst: I would say as early as possible, but late enough to catch all apperances
12:06 karolherbst: but not that you end up splitting mul64 imm0 imm1
12:07 karolherbst: or split before merging mul64 $r0 $r1 imm0; mul64 $r2 $r0 imm1;
12:08 karolherbst: otherwise you end up with less optimized code, because some passes won't detect this in the end, but maybe they do, I don't know for sure
12:08 pmoreau: :-D
12:08 pmoreau: So, just roll a dice and pick one pass?
12:08 karolherbst: well there is always a hack I wrote
12:08 pmoreau: I should check the logs, I think imirkin suggested another pass when I started working on it.
12:08 karolherbst: pmoreau: https://github.com/karolherbst/mesa/commit/3df2976a496fa010dca261b6484550aaf2865658
12:09 teto: hi, tried the troubleshooting page / FAQ but still have troubles getting a GTX 970 working on ubuntu 16.04. First in my log, X tries "nvidia" first while I should have removed everything related to nvidia (how does X chhose the order ?) https://transfer.sh/dx73i/xorg.0.log . Then it loads nouveau which seems ok but https://transfer.sh/SWS3E/unity-support-test.log tells me support 3D=no (steam games are slow,
12:09 teto: sway on wayland is fricking slow) I start X as non root if that can be a pb ?
12:09 karolherbst: teto: update your stuff
12:09 karolherbst: and remove nvidia the right way if you want to use nouveau
12:11 pmoreau: Also, it is a 970 with 4GB or VRAM right? You won’t be able to do much with Nouveau for now: https://bugs.freedesktop.org/show_bug.cgi?id=94990
12:11 pmoreau: teto: ^
12:11 teto: karolherbst: I purged nvidia*, grepped for anything with nvidia in the name and removed the directory etc... I would like to know how X finds the drivers in order to find the nvidia related leftover "Matched nvidia as autoconfigured driver 0"
12:12 teto: pmoreau: shit I have the same motherboard as the tester xD but I stay on an older kernel that should be ok?!
12:12 karolherbst: it won't :p
12:12 karolherbst: there are only dirty hacks to get that gpu working
12:12 karolherbst: one dev is working on it though
12:13 teto: so if I fix my current pb so that nouveau loads first, it means my screen will remain black :'( ?
12:14 pmoreau: Additionaly, for the day Nouveau works on that card, you should remove xf86-video-nouveau and use modesetting (which should be directly packaged with xorg-server) instead
12:15 karolherbst: teto: do you have a file like this? (path my be different) /usr/lib64/xorg/modules/drivers/nvidia_drv.so
12:15 karolherbst: seems like it is /usr/lib/nvidia-352/xorg/nvidia_drv.so under ubuntu
12:16 karolherbst: or whatever silly path they use
12:17 teto: how come it's still here after apt removed *nvidia* :'( I find /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so and /usr/lib/x86_64-linux-gnu/directfb-1.2-9/gfxdrivers/libdirectfb_nvidia.so
12:17 karolherbst: no clue
12:17 karolherbst: ask ubuntu devs
12:22 pmoreau: teto: Even after fixing all the previously mentioned stuff, you still won’t get good performance for gaming. For that you will need the ability to reclock your card, which is still completely hacky right now.
12:23 pmoreau: So for the time being, you would be better of using the NVIDIA driver.
12:28 teto: I would like to try sway with wayland before going back to the nvidia drivers if that's reasonable. To enable modesetting, I just add "nouveau.modeset=1" to my kernel parameters ?
12:28 karolherbst: teto: modesetting is enabled by default
12:28 karolherbst: but that's not the point
12:31 teto: ok, i stop troubling you further, will switch back to nvidia drivers while keeping a close look at nouveau news. Thanks for your help here and your great job on the drivers
12:31 karolherbst: thing is, without nvidias signed pmu firmware, we can't control the fans
12:32 karolherbst: so the gpu would get pretty hot over time
12:32 karolherbst: when reclocked
12:32 teto: to paraphrase someone "fuck you nvidia!"
12:32 karolherbst: nah, that would only work if we would get the private key somehow :p
12:32 karolherbst: then that would be a clear statement
12:35 teto: I see maybe "Anonymous" can make themselves useful :)
12:35 karolherbst: sure :D
12:36 siro__: t-ask: I'm using karolherbst branch to reclock the card. core frequency is now 3times higher, but no fps increase at all
12:36 karolherbst: siro__: I hope it isn't stuck at 60 fps?
12:37 t-ask: siro__: haha 60FPS .. a dream ,)
12:37 t-ask: siro__: no effect at all?
12:37 karolherbst: siro__: with what are you testing by the way?
12:38 siro__: GuildWars 2 on NVE4
12:38 karolherbst: mhh, that's through wine, right?
12:39 t-ask: siro__: btw. loading GW2 takes a long time with nouv (single threded).. the same for you?
12:39 siro__: t-ask: that's due to shader compilation at game start
12:39 t-ask: siro__: I mean the loading process uses only a single thread, then switches back to multi
12:39 karolherbst: that can have various reasons: 1. cpu bottlenecked, 2. vsynced at 60fps, 3. silly game engine
12:39 siro__: wine compiles them on the fly, that's why you got massive fps drop in some scenes
12:39 t-ask: Didn't take that long with Wine CSM fyi
12:41 siro__: karolherbst: I would like to have a GPU load in gallium hud, this way it's easy to tell if you are gpu or cpu limited
12:41 t-ask: Lions Arch: echo 07 = 4FPS and Echo 0f = 7FPS
12:41 siro__: I'm not CPU limited on r600, so I guess I'm not CPU limited on nouveau too
12:42 karolherbst: siro__: yeah, and for that we have to put some stuff into the kernel first as well, it is all ready, but we still have to think about a proper interface for that
12:42 t-ask: htop shows 15020% CPU load
12:42 t-ask: lol 15-20% :)
12:43 karolherbst: siro__: well, it should make a difference then
12:44 karolherbst: siro__: output of glxinfo please
12:45 siro__: karolherbst: https://paste.fedoraproject.org/411866/14717835/
12:46 karolherbst: siro__: do you get a difference in performance running glxgears?
12:46 siro__: karolherbst: I'll try a benchmark
12:53 siro__: karolherbst: gpu frequency increased by factor 2.8 and unigine heavon score increased by factor 2.6
12:54 karolherbst: expected :p
12:54 karolherbst: so it seems to work
12:54 siro__: I guess it's another bug in nouveau / strange engine behaviour causing it to throttle
12:54 karolherbst: maybe something is odd with your 32 bit libraries and nouveau isn't used in 32bit wine
12:55 karolherbst: can you install a glxinfo32 or something like that?
12:55 karolherbst: or do a 32bit benchmark?
12:55 siro__: there's a 32bit version of glxinfo ?
12:55 siro__: the benchmark was done on 32bit
12:55 karolherbst: mhh, k
12:55 karolherbst: sure the benchmark was 32bit=
12:55 karolherbst: ?
12:56 siro__: yes, I've used 32bit wine
12:57 karolherbst: ohh, you run unigine within wine
12:57 karolherbst: siro__: did you compare the fps in the game with the previos reclocking state of compared to 07?
12:58 karolherbst: because some games don't need high engine clocks, high memory clocks might be enough already
12:59 siro__: no I didn't compare it to 07
12:59 karolherbst: you can do this
12:59 siro__: I'll do some profiling to see what's causing the bottleneck
12:59 karolherbst: compare with 07,0a and 0f
13:00 karolherbst: and if 07->0a gives a huge boost, it might be simply gpu memory bandwith bottlenecked
13:05 t-ask: karolherbst: whats the difference of 0a and 0f?
13:06 karolherbst: t-ask: should be memory clocks
13:06 siro__: 07 5fps, 0a 6fps, 03 12 fps
13:06 karolherbst: ohh yeah, that looks right
13:06 karolherbst: I wrote something stupid
13:06 siro__: there's no difference between 0e and 0f
13:06 karolherbst: the core clocks don't icnrease much from 0a and 0f
13:06 karolherbst: siro__: most likely same clocks
13:06 karolherbst: seems like indeed memory limited
13:09 t-ask: if I set to 07 my whole system os like it's running with 300MHz :)
13:09 t-ask: even typing somehting is heavily delayed. I don't remeber I had this some weeks ago
13:10 siro__: karolherbst: this card is about 50% faster in unigine heavon than my AMD BARTS, so I'd expect it to be 50% faster in GuildWars2 too
13:10 siro__: but it's like 5 times slower than amd barts
13:12 siro__: there's a single draw call that takes more than 100msec every frame
13:12 karolherbst: can have several reasons, maybe nouveau just does something really stupid there
13:16 t-ask: siro__: fyi Rata Sum is fast, too
13:22 t-ask: siro__: you may try to use the GW2 switch "-32" or "-dx9single"
13:23 t-ask: while they don't seem to have any effect for me anymore. with CSMT -32 gave a 15FPS boost
13:28 siro__: dmesg shows ILLEGAL_SPH_INSTR_COMBO errors
13:29 karolherbst: mhh, might slow down things
13:29 karolherbst: imirkin: any ideas?
13:31 siro__: how do I debug this kind of errors ?
13:39 t-ask: oh, my dmesg looks liek ... https://0bin.net/paste/9mypp1hADM7sixoV#YmoX-QNVFuaPfTf1vKSQC3UQ/ftBetl0/gehqtvayI4
13:40 karolherbst: t-ask: yeah, some bug in mesa most likely
13:40 karolherbst: siro__: starring at shaders for weeks to find the one thing which is wrong :p
13:45 t-ask: karolherbst: you've seent he first two lines? Those I get when setting 0f eg. So it looks on boot it happens, too?
13:46 karolherbst: you have to use one of my branches as I said before
13:46 t-ask: karolherbst:
13:46 t-ask: am I not?
13:46 karolherbst: seems that way
13:47 t-ask: so it reclocks even if I supposedly don't have it? I wonder bc. so far I think I applied your branch
13:47 karolherbst: it only reclocks memory
13:47 karolherbst: well, you also have to install it right
13:48 t-ask: ok, then Did it once and didn't the last time
13:48 karolherbst: you have to repeat it after a kernel upgrade :/
13:49 t-ask: I put the module in updates
13:49 t-ask: then it shouldn't or?
13:49 karolherbst: no clue
13:49 t-ask: I mean I do it on each kernel change, but it should work that way I suppose
13:50 karolherbst: maybe you forgot to regenerate initramfs?
13:53 t-ask: actually I use mkinitcpio and checking with modinfo Kernel seems to use the rigth module "filename: /lib/modules/4.7.1-1-ARCH/updates/nouveau.ko.gz"
13:54 t-ask: modules in updates folder overwrite the standard ones
13:54 karolherbst: I see
13:54 t-ask: thta's why I move your patch into that folder
13:54 karolherbst: are you sure you also switched the git branch?
13:56 t-ask: karolherbst: I better repeat that now. I fiddled around with to many stuff
13:56 karolherbst: check "git branch -l"
13:57 t-ask: which is the branch to use?
13:58 karolherbst: you should make sure to use the stable_reclocking_kepler branch
13:58 t-ask: ok, I start from scratch with that
14:21 t-ask: ok, now time for reboot .)
14:21 t-ask: I used * stable_reclocking_kepler_v5
14:27 t-ask: issue persists ..
14:27 t-ask: modinfo nouveau | grep ko => filename: /lib/modules/4.7.1-1-ARCH/updates/nouveau.ko.gz
14:32 t-ask: Is it ok to just make + gzip the ko and then copy it to the target folder?
14:32 t-ask: or do I need to make install... while I'm not sure if that is working with th eupdates/ folder
14:34 karolherbst: fun, mmiotracing is also broken when tracing nouveau
14:34 karolherbst: but works with nvidia
14:36 MoDaifallah: Any developers reading this?
14:36 MoDaifallah: I have feedback to post
14:39 t-ask: I take a walk ... :)
15:30 sandisufiandi: Hello world, anyone can help me to config xorg the detail is at https://devtalk.nvidia.com/default/topic/923782/jetson-tk1/hdmi-display-for-raspberry-pi-on-jetson-tk1/2
16:30 pmoreau: Ah, looks way better now. And the code looks way cleaner when you can just create new instructions and variables, rather than messing around with the existing ones. :-)
16:30 karolherbst: :)
16:31 pmoreau: Sadly, looking nice && compiling && generated code looking good does not mean that it will actually work
16:32 karolherbst: sure it does :p
16:41 t-ask: kernel 4.7.2 :)
16:42 imirkin: pmoreau: yeah, you can only pick 2 of those at a time
16:42 karolherbst: then I always choose looking nice and generade code looking good :p
16:43 karolherbst: *generated
16:43 imirkin: compiling's overrated
17:05 Guest_84857: allah is doing
17:05 Guest_84857: sun is not doing allah is doing
17:05 Guest_84857: moon is not doing allah is doing
17:05 Guest_84857: stars are not doing allah is doing
17:05 sandisufiandi: What are you doing?
17:07 orbea: huh, that bot has been bothering ##slackware too :\
17:08 imirkin: welcome to the world. there's jerks in it. who knew.
17:10 Yoshimo: tor was flooded earlier, mozilla irc in general as well. At least this guy doesn't highlight everyone in the channel
17:14 karolherbst: :D
17:14 karolherbst: imirkin: you are joking, right?
17:15 imirkin: about what?
17:15 Tom^: wat
17:16 karolherbst: your last sentence, nvm then
17:20 Calinou: karolherbst: "Nouveau is not doing NVIDIA is doing" :D
17:29 sandisufiandi: Hahahaha LoL
17:42 Namidairo: poor guy actually sits there and types it me thinks
17:42 Namidairo: saw him get called out on capitalization and it got fixed in the later sentences
17:43 Namidairo: but it seems he forgot
17:51 pmoreau: Now, let’s see if it actually works, or if it still locks up the GPU…
17:53 karolherbst: Namidairo: writing a bot ain't that hard
17:54 Tom^: with existing irc librarys it would take like 40 lines of code.
17:54 Namidairo: and yet there he is using a web irc client
17:55 Namidairo: enough, off topic.
17:55 Tom^: true heh
17:56 karolherbst: Tom^: 10 with python
17:56 Tom^: karolherbst: 1 with C
17:56 Tom^: just a very long one. :P
17:56 karolherbst: ...
17:59 Tom^: made me think of iocc and code like this http://www.ioccc.org/2015/dogon/prog.c =D
18:01 karolherbst: there is an error :O
18:01 karolherbst: crap code
18:04 Tom^: perhaps does some magic in the makefile it provides
18:04 Tom^: *shrug*
18:06 karolherbst: I meant the code is alligned badly
18:06 karolherbst: search for XPutImage
18:18 t-ask: LISP :)
18:20 night199uk: hrm
18:20 night199uk: anyone good with crtc calcs?
18:21 night199uk: i’m looking at some of the crtc calcs in nv50_display and the names don’t make sense to me right now
18:22 night199uk: kind of semantic point because the calcs work, just wondered if there was a reason for the naming
18:33 t-ask: weiss ich nciht steht doch sicher in der mail
18:33 karolherbst: skeggsb: I need some map regarding nvkm_instmem. I want to read paged memory from a given location from userspace
18:34 karolherbst: skeggsb: like, I have an address pointing into virtual vram address space and I want to read out what is there through the nouveau userspace code
18:34 karolherbst: t-ask: wrong channel?
18:34 t-ask: sloppy window focus :P
18:35 karolherbst: sure, blame the others, as always
18:36 t-ask: yes, my mouse is guilty *g
18:44 t-ask: Now my mouse feels ashamed. I think, I better forgive her, before I have to glue the buttons again :)
18:57 clb: hey, I wonder if someone might have tips on how to debug nouveau drivers not giving 1920x1080 display mode on a GTX 980 Ti graphics cards and an Asus VG278H display (which is native 1920x1080@120hz)?
18:58 clb: it locks me in to 1280x1024 display mode instead. I'm trying on a fresh install of Linux Mint 18 Cinnamon which has xserver-xorg-video-nouveau 1:1.0.12-1build2 driver
19:01 clb: dmesg gives me the following:
19:01 clb: [ 7.501607] nouveau 0000:02:00.0: unknown chipset (120080a1)
19:01 clb: [ 7.501612] nouveau: probe of 0000:02:00.0 failed with error -12
19:02 clb: this is on a dual Xeon SuperMicro X10DAx and a Asus GTX980 Ti DC3OC 6G Gaming setup
19:15 clb: oh, replacing "quiet splash" with "nomodeset" in grub boot options hides that log message from occurring, however it does not give 3D acceleration or 1920x1080 option still
19:24 t-ask: Is setting /proc/sys/kernel/yama/ptrace_scope = 0 in any kind influencing nouveau d3d9?
19:25 pmoreau: clb: nomodeset ends up disabling Nouveau
19:26 pmoreau: Which kernel do you have?
19:27 mwk: clb: your GPU chipset (GM200) is just not supported by the kernel you have, sorry
19:28 pmoreau: 4.6 should be good though, with acceleration support
19:35 clb: pmoreau: mwk: looks like 4.4
19:36 pmoreau: Try upgrading to 4.6/4.7
19:36 clb: mwk: well, that sounds conclusive then.. I wonder if it's possible to upgrade via Mint itself, or if I have to compile kernel from source
19:37 clb: (it's been several years since I've poked on this stuff, and first time on poking Mint, I'll have to look around a bit to figure that out)
19:37 pmoreau: If you have xf86-video-nouveau, you should remove it. And make sure you have the firmware installed as well. It is part of linux-firmware, or however it is called for Mint.
19:38 clb: thanks, good pointers
19:42 clb: mwk: pmoreau: btw, do you guys know if there is a generic "vga" driver that it should fall back on if the chipset is unknown? I.e. even if the GPU was unsupported, that it'd be able to query via HDMI the supported display modes the HDMI display is capable of?
19:42 clb: or some kind of "generic-nvidia" type of mode?
19:43 karolherbst: clb: you also need linux-firmware installed
19:43 karolherbst: and newet then june 2016
19:43 karolherbst: *newer
19:43 karolherbst: *than
19:44 karolherbst: clb: also, as long as you don't want to roast your GPU, there is no reclocking support
19:45 karolherbst: clb: efifb if you have uefi
19:45 karolherbst: vesafb otherwise
19:46 karolherbst: but vesafb sucks, so you are better of with efifb
19:50 clb: karolherbst: hmm thanks
19:51 pmoreau: Grrr, the GPU continues to lockup… even with the blob gr firmware.
19:52 karolherbst: pmoreau: yep, there is an issue somewhere, ben knows more I think. At least he told me he has some gpus which won't reclock
19:52 karolherbst: pmoreau: does the gpu also lockup without being reclocked?
19:53 pmoreau: Hum… I think so
19:53 pmoreau: But I haven’t tried without reclocking + blob fw
19:53 karolherbst: shouldn't matter I guess
19:54 karolherbst: so that means we do something odd which isn't reclocking related, what a surprise
19:55 pmoreau: Or miss something. This is an Apple laptop, so I wouldn’t be surprise if this one’s VBIOS also thinks different, like my old one did.
19:55 karolherbst: those vbios are the worst
19:55 karolherbst: you would think there is some really smart gpu boost going on
19:55 karolherbst: but no, just low clocks
19:55 karolherbst: and stable voltage
19:56 t-ask: btw is there a way to read GPU voltage, GPU clock and mem clock?
19:57 karolherbst: sensors for voltage and pstate file for clocks
19:57 karolherbst: pmoreau: fact is, stock nouveau can't do anything wrong on your gpu I think :D
19:58 karolherbst: except vid table parsing
19:58 karolherbst: pmoreau: https://github.com/karolherbst/nouveau/commit/b22b53063eb4abe8a5b93966e59bc656f81599d8 and https://github.com/karolherbst/nouveau/commit/3da0fc61b6589112494700b5a5885690d855321b
19:58 karolherbst: that's what you need
19:58 karolherbst: ;)
19:58 pmoreau: Well, I still get lockups with stock Nouveau. So, depends on your definition of "do anything wrong". Sure it won’t burn my laptop
19:59 karolherbst: ohh, actually those higher csteps have a too high voltage too
19:59 karolherbst: ...
19:59 karolherbst: so you need more
19:59 karolherbst: bothersome
19:59 karolherbst: huh
19:59 karolherbst: "-- ID = 0, mode: 1, link: 53, voltage_min = 1118750, voltage_max = 1118750, volt = 1100000 [µV]"
19:59 karolherbst: do I have to understand this?
20:00 t-ask: karolherbst: I'm using cat /sys/kernel/debug/dri/0/pstate to see the clock range. Is there a way to see the 'real clock spped'?
20:00 karolherbst: t-ask: last line
20:00 pmoreau: Aren’t those in your reclock_stable_branch?
20:00 karolherbst: they are
20:00 karolherbst: just other gpus need a lot more to actually work
20:01 karolherbst: mhh
20:01 karolherbst: this voltage map table troubles me a bit now
20:01 karolherbst: the actual voltage value is below voltage_min
20:01 karolherbst: maybe there is a flag in the header to ignore the min/max values?
20:02 karolherbst: pmoreau: mind switching over to nvidia and run my nv_cmp_volt tool?
20:02 pmoreau: Hum
20:02 pmoreau: Sure
20:02 karolherbst: it is in the awesome_tool branch
20:02 karolherbst: run make in top level
20:02 karolherbst: LD_LIBRARY_PATH=lib bin/nv_cmp_volt
20:03 karolherbst: brb
20:04 pmoreau: k
20:32 karolherbst: bsck
20:32 karolherbst: *back
20:45 imirkin: clb: note that without reclocking, you'll only have a small fraction of your card's performance available. if you want good open-source support, definitely go with amd (or intel)
20:45 imirkin: calim: nice little surprise you left behind - https://patchwork.freedesktop.org/patch/106232/
20:47 calim: happens :P
20:47 imirkin: yep :)
21:13 karolherbst: pmoreau: any results so far?
21:16 pmoreau: karolherbst: No, I had a late dinner + trying to get my other laptop to connect to the internet
21:16 karolherbst: I see
21:16 pmoreau: Which repo is it btw? You only said the branch
21:17 karolherbst: nouveau
21:17 pmoreau: Oh ok
21:23 pmoreau: Hum… can’t find drm.h
21:23 karolherbst: you can remove that include
21:23 karolherbst: doesn't work on arch, no clue why
21:23 karolherbst: it works here
21:24 pmoreau: Where is it located on your computer?
21:24 karolherbst: you can simply remove that include, though
21:25 karolherbst: it should include only kernel header files
21:25 karolherbst: I think
21:25 pmoreau: Cause I have a drm.h, but it is in /usr/include/libdrm, so the extra drm/ makes it fail I guess
21:25 karolherbst: ohh
21:25 karolherbst: mine is at /usr/include/drm/drm.h
21:25 pmoreau: Removing the drm/ did help
21:25 karolherbst: -I/usr/include/libdrm is part of CFLAGS though
21:26 karolherbst: now I get it...
21:26 karolherbst: k
21:26 pmoreau: Right, but the include is `#include <drm/drm.h>`
21:26 karolherbst: yeah, for the kernel header file I think
21:26 pmoreau: Most likely, yes
21:27 karolherbst: yep, /usr/src/linux/include/uapi/drm/drm.h or /usr/src/linux/include/uapi/drm/drm.h
21:28 karolherbst: ...
21:28 karolherbst: I meant /usr/src/linux/usr/include/drm/drm.h
21:28 karolherbst: nvm though
21:35 pmoreau: karolherbst: It fails to create a device, with error -12
21:35 pmoreau: (as root)
21:35 karolherbst: uhhh, right, you need that iomem thing
21:36 karolherbst: boot with iomem=relaxed
21:36 karolherbst: they though it is a good idea to prevent access to iomaped memory
21:36 karolherbst: even from root
21:36 karolherbst: *thought
21:38 pmoreau: How long does it need to run?
21:38 karolherbst: put some load on the gpu
21:38 karolherbst: and let it clock to max
21:39 karolherbst: then it should be fine
21:39 karolherbst: it should start printing stuff if something changes
21:44 pmoreau: karolherbst: https://phabricator.pmoreau.org/P102
21:45 karolherbst: mhhh
21:45 karolherbst: seems like there is no flag and the vbios just sucks
21:45 karolherbst: first coloumn is the voltage set by nvidia and the second one is what nouveau would set
21:45 pmoreau: Nouveau is below in some cases
21:46 karolherbst: yep
21:46 karolherbst: which is okay
21:46 karolherbst: step size is 12.5mV
21:46 karolherbst: and nouveau rounds up
21:46 karolherbst: so it is fine
21:47 karolherbst: gpu can't do 868750µV
21:47 pmoreau: If you round up, it should end up above, not below, right?
21:47 karolherbst: so nouveau will set it to 875000µV
21:47 karolherbst: the expected coloumn just shows what the voltage calculation code throws out
21:49 karolherbst: cstep 13 -> vmap 39 ->
21:49 karolherbst: -- ID = 13, mode: 1, link: 55, voltage_min = 1037500, voltage_max = 1037500, volt = 1018750 [µV] +
21:49 karolherbst: -- ID = 55, mode: 1, link: 60, voltage_min = 0, voltage_max = 12500, volt = 64000854 + (-69906 * T * 5^6) >> 10 [µV] +
21:49 karolherbst: -- ID = 60, mode: 1, link: 69, voltage_min = 0, voltage_max = 0, volt = 31250 [µV] +
21:49 karolherbst: -- ID = 69, mode: 0, link: -1, voltage_min = 0, voltage_max = 0, volt = 0 [µV]
21:49 karolherbst: ...
21:49 karolherbst: first one is wrong
21:49 karolherbst: silly me
21:51 karolherbst: https://gist.github.com/karolherbst/97b28bb8ea9dd5fcf04930d488a62201
21:52 karolherbst: sp iot ends up being 868750 +0 +0 +0
21:52 karolherbst: instead of 856250
21:52 karolherbst: as I thought could be a possible outcome through a header flag
21:53 karolherbst: even the ID=58 entry is odd
21:53 karolherbst: cause the formular can't get above 0µV
22:05 karolherbst: pmoreau: thanks for testing it, seems like everything is alright then
22:05 pmoreau: You are welcome
22:06 pmoreau: Then I’ll revert back to Nouveau, as NVIDIA does not let me change the brightness of the screen and does weird things with the UI.
22:06 karolherbst: k
22:26 RSpliet: for some reason a pde of 280007f1 doesn't sound feasible on a machine with 8GB of RAM and less of that in VRAM
22:29 RSpliet: nor does 000003f1 ... I must be doing something wrong in their interpretation
22:37 t-ask: Ok, nouveau.ko is loading without dmesg errors
22:38 t-ask: pstate is set to "0f: core 549-1071 MHz memory 7000 MHz AC DC *" while AC is only showing "AC: core 877 MHz memory 6999 MHz" ... or is this normal behaviour?
22:39 t-ask: it's almost 200MHz less
22:42 RSpliet: t-ask: that probably depends on whether "boost" is enabled or not
22:43 t-ask: "boost"?
22:43 t-ask: isn't oxof the highest clockrate setting?
22:43 RSpliet: http://www.geforce.com/hardware/technology/gpu-boost-2
22:44 RSpliet: that stuff (higher clocks) is disabled by default in nouveau
22:44 RSpliet: karolherbst is reverse engineering related things atm
22:44 t-ask: becasue he thinks its better to not risk cards overhead
22:45 RSpliet: overheating ;-)
22:45 RSpliet: well, rightfully so
22:45 RSpliet: 877 is probably the conservative clock (eg. the one that works even with a high temp)
22:46 t-ask: well sounds like my fan is at higher speed already. I guess there is no risk, at least with 780ti then
22:46 t-ask: fan1: 1860 RPM +58.0°C
22:46 RSpliet: there's also some trickery with determining the right voltage for the associated clock, and if nouveau does that wrong your card will hang
22:47 RSpliet: it's all slightly more complex than simply setting one pll, hence it's (still) not ready for prime-time
22:47 t-ask: ok, anyways it is nice to see several fixes I reported
22:49 pmoreau: Awesome! The loop samples are passing on my Tesla cards!
22:49 t-ask: well, probably I stay conserverative there too
22:49 pmoreau: Now, if only they could not lockup my Kepler…
22:49 t-ask: It looks better, but not like it is fixed. I will apply Siros mixed patch then
22:50 t-ask: btw karol has a new v6 branch?
22:51 t-ask: well, if that is the predecessor of v5 I could try it
22:58 imirkin: pmoreau: remember that join works differently on fermi than on tesla
22:59 imirkin: pmoreau: make sure you emit the join/joinat's properly
22:59 imirkin: pmoreau: there are later passes that fix it all up based on that initial expectation
22:59 imirkin: iirc the expectation is that the initial nv50 ir looks more nv50-style than nvc0-style
23:24 pmoreau: Oh, I have no joins at all IIRC. I think I added that to the code earlier, but I didn’t see any in the debug output.
23:25 imirkin: if you're using nvdisasm it'll look like a .S instruction flag
23:25 imirkin: [for fermi+]
23:25 imirkin: while technically the joins are optional for the hw, i'm pretty sure the compiler will miscompile if they're not there
23:29 pmoreau: That’s what I remember as well from when I was getting branching to work. But I can’t find any join generation in the code. I wodner what I did with those…
23:35 imirkin: alternatively you can skip generating the joinat's :)
23:35 imirkin: you'll get shit perf, but afaik it should work
23:37 pmoreau: I should hopefully be able to insert them back :-)
23:38 pmoreau: I *think* I might have had some similar issues before I added them, but I could be wrong.
23:38 pmoreau: Thanks for reminding me about those.