00:00 imirkin: fwiw all this stuff currently works ok on nouveau kepler+
00:00 skeggsb: yep, i know
00:00 skeggsb: we do the right thing there
00:01 imirkin: ok :)
00:01 imirkin: skeggsb: btw, i guess in the end GM108 == GM107? based on your patch at least...
00:01 skeggsb: yeah, after i fixed the missing-PPC stuff
00:01 imirkin: cool
00:05 imirkin: gnurou: i guess you can close this one: https://github.com/Gnurou/nouveau/issues/15
00:05 karolherbst: imirkin: this UNFUCKUP is intentionally? :D
00:05 imirkin: karolherbst: probably not the *official* name
00:06 karolherbst: yeah well, that far I already got
00:06 imirkin: ;)
00:06 imirkin: that should fix a whole bunch of dEQP tests out of the box
00:06 karolherbst: mhh maybe those "official" names are all kind of crazy
00:06 imirkin: i had a horrid patch to do it "by hand", but it was horrid
00:06 karolherbst: and that's the reasony they can't just release it
00:07 gnurou: imirkin: yeah, sorry for not providing useful information on this one :/
00:07 imirkin: gnurou: no worries
00:07 gnurou: I think we should adopt the same name internally
00:07 imirkin: hehe
00:07 karolherbst: skeggsb: any opinions on my reclocking stuff?
00:07 imirkin: that does seem like the sole purpose of the register...
00:07 skeggsb: airlied: fix is in the same branch, want an explicit pull req?
00:07 skeggsb: karolherbst: i haven't had a chance to properly review it yet
00:07 imirkin: to fuck up the offset queries
00:08 karolherbst: skeggsb: okay, so most likely it won't land in 4.7 then because there isn't much time left, and you most likely would like to test the code a bit
00:09 skeggsb: i've been following it, and it's looking pretty good so far - since it's become a lot less magic ;)
00:09 imirkin: yeah... a lot fewer random numbers being multiplied
00:09 karolherbst: skeggsb: I know it is a lot, and it touches all kind or trouble makers: volt/base, clk/base, therm/base ... so either way is fine by me :D
00:09 airlied: skeggsb: nope all good, grabbed it now
00:10 skeggsb: airlied: thanks!
00:10 karolherbst: skeggsb: but currently I am sure with those new coefficients we have the same formular as nvidia has :)
00:10 karolherbst: nouveau behaves exactly the same as nvidia does on 4 cards where I tested the new ones
00:11 karolherbst: voltage related
00:18 imirkin: skeggsb: have you made any progress in hardening nouveau against multiple processes doing rendering?
00:19 imirkin: (aka piglit without -1)
00:19 skeggsb: the worse of them should already be fixed i believe
00:19 skeggsb: but no, i haven't finished off what i was working on there yet
00:19 imirkin: ok
00:20 skeggsb: i generally run piglit without -1 these days fwiw
00:20 imirkin: and live in fear? :)
00:20 skeggsb: a patch from gnurou for that extra channel kick helped a lot
00:20 imirkin: ah ok
00:26 imirkin: skeggsb: separately, i assume no movement on DP-MST since... 2 years ago when you started a branch?
00:28 imirkin: robclark: so did you end up determining that mesa on GM107 was fine in your case, or something was off?
00:28 imirkin: karolherbst: do you happen to know what's in reator?
00:29 karolherbst: last time I checked it was a gk104 and gk208 I think, but this was like two days ago
00:29 robclark: imirkin, you mean for the nv117 thing? We concluded that it was a display-side issue..
00:29 imirkin: robclark: aka not-nouveau?
00:29 robclark: well, nouveau kernel driver was driving the display.. but not mesa ;-)
00:29 imirkin: oh
00:30 imirkin: karolherbst: thanks
00:30 imirkin: robclark: well, let skeggsb know if you haven't already. he's the display master.
00:30 robclark: I think Lyude sent some screenshots to skeggsb.. and if needed we might be able to ship him the laptop (but it is a loner.. but we can sort that out internally ;-)
00:30 robclark: yup
00:31 robclark: (err, not screenshots, but fuzzy cameraphone pics of what is seen on screen)
00:31 imirkin: hehe ok
00:31 imirkin: so you're gonna short the laptop? :)
00:32 robclark: if we can get permission to ship it to another site/country (and if skeggsb thinks it is necessary) we will
00:38 skeggsb: robclark: are you talking about the gradient thing?
00:38 robclark: yeah
00:38 skeggsb: imirkin: i have to do that in the next few months now actually, so, it'll move
00:39 skeggsb: robclark: hopefully a patch airlied just took will fix it
00:39 robclark: skeggsb, fwiw, it's a bit hard to tell in the pictures but look at bottom part of screen
00:39 robclark: ahh, cool
00:39 skeggsb: be good if yourself or Lyude can confirm that :)
00:40 airlied: should be drm-fixes now
00:40 robclark: sure, no prob, we have the laptop still, so one of us can try it on Mon
00:42 imirkin: skeggsb: ah neat
00:43 imirkin: apparently people are starting to get it in docks (surprise surprise)
00:43 robclark: yeah, groan..
00:44 imirkin: and some of the "fancy" laptops are nvidia-only
00:44 robclark: yup
00:45 robclark: (or nv only driving the dp to the dock)
00:45 imirkin: i thought that more recent laptops were shifting all outputs to intel, but apparently not
00:45 robclark: nope ;-)
00:46 karolherbst: by the way, I found some more scripts in the vbios which look like the other display scripts, but never looked into it
00:48 airlied: imirkin: one laptop has an option to have intel or nouveau drive it
00:48 airlied: so you can have 4 monitors
00:49 imirkin: but 2 of them better be mirrored if you plan on using intel?
00:49 airlied: yup hence why you get nouveau
00:49 airlied: or nvidia wired up
01:10 martm: grr, there was a game called metro last light that did not run, can someone look into this one too?
01:11 martm: it did run but had a bug to be more precise
01:11 martm: bug triggered inside nouveaus code that is
01:32 martm: anyways gotta a laptop again, was thinking of going over the links for programs that help to pinpoint multithreading issues in code level, but actually should apply the atomics pass too, to see if only such issues are present
09:23 martm: pq: hei hei, when was the last thing you worked on nouveau's code?
11:14 CodeKing: I had an issue updatng from nouveau to nvidia driver. I have mnaged to move back to nouveau but have a display problem.
11:14 CodeKing: It is in 4:3 resolution only. Any ideas?
12:09 naptastic: kernel: [80560.711725] nouveau 0000:01:00.0: fifo: PBDMA0: 04000000 [ACQUIRE] ch 5 [007f898000 chrome[3537]] subc 0 mthd 001c data 00001004
12:10 naptastic: /var/log/kern.log is filling my disk with messages like this
12:10 naptastic: what do I do?
12:14 RSpliet: naptastic: is the system usable otherwise? have you tried updating your kernel?
12:15 naptastic: RSpliet, it's been a week since I updated the kernel, and I've seen this happen twice, yesterday and today. I'm looking at a bug report in libdrm that seems promising.
12:16 RSpliet: naptastic: which kernel is that?
12:17 naptastic: It's one I compiled. Upstream 4.4.7 + BFS + BFQ + -march=native
12:18 naptastic: The bug report I found is for libdrm* 2.4.60 and was fixed in 2.4.61... I'm on 2.4.67... so that's out :)
12:20 RSpliet: okay, this patch landed in kernel 4.5 that might be relevant: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=b4c5fc4b853a1d508cbd3133f5d363037bfd5844
12:20 naptastic: oooooh
12:21 naptastic:starts downloading things
12:21 RSpliet: yeah, if it's not too much trouble try and 4.5 or even 4.6RC kernel (but I understand if you're not comfy with RC kernels ;-))
12:22 naptastic: I usually use the latest version for which there's a BFS patch. Which there wasn't for 4.5 last I checked, but there is now, so HERE WE GO! :D
12:23 RSpliet: if it doesn't help, double-check the nouveau debug settings, I can't quite tell from that single message whether it's harmful or not
12:23 RSpliet: (the full log could be helpful, usually the first message gives the best indication of the real error, the rest could just as well be collateral)
12:23 naptastic: I'll double-check those. I thought I turned them all off, but...
12:24 RSpliet: keep it printing warnings and errors
12:24 RSpliet: but spam, debug and even info is probably too much
12:24 naptastic: well, / got full so I had to sacrifice one log :'( but as this has happened twice, I might have info from the previous occurrence.
12:24 RSpliet: try the 4.5 kernel and get its logs if things still go wrong
12:25 naptastic: Definitely, and I'll post results here either way. (It will be a while before I know.)
12:25 naptastic: (Steps to reproduce: Open Chrome; open Cookie Clicker; lock screen; go to bed.)
12:29 hansg: imirkin, good morning. Did you see my last mail about the add instructions which get folded into the offset of the subsequent load, but the add itself is not being removed ?
12:29 hansg: I've been looking into this and making some progress, but I could use a hint how to continue from here :)
12:37 karolherbst: mupuf: there is an issue in your env_dump: you can't rely on the fact, the required libraries being loaded already :/
12:37 karolherbst: mupuf: while trying to start heaven without env_dump preloaded, env_dump can't resolve xcb_dri3_open_reply_fds because libxcb-dri3.so isn't loaded at that point
12:38 karolherbst: and preloading it additionally to env_dump helps
12:51 mupuf: karolherbst: what the heck, this function should not be called unless there has been a xcb_dri3_connect call
12:51 mupuf: so, that would mean the library is open
12:51 mupuf: and I run heaven with env_dump
12:51 mupuf: well, maybe I did not for some time, let me check
12:52 karolherbst: mupuf: I've added a printf inside env_dump when the symbol can't be resolved
12:52 mupuf: oh, you are right
12:52 karolherbst: it prints this symbol and then segfault
12:52 mupuf: well... debug time, it is serious :D
12:53 karolherbst: well my first idea was to implicitly state which library to load (or libraries)
12:57 mupuf: well, hooking is a delicate process, you really want to avoid any loops
12:57 karolherbst: right
12:57 karolherbst: usually you also call dlsym with a dlopen reference
12:58 mupuf: xcb has been giving me some pain
12:58 mupuf: yop
12:58 mupuf: but you need to use the same dlopen reference as what the app is using ;p
12:58 karolherbst: well you can always do dlopen(NULL, LOCAL); and pass this
12:58 mupuf: and the app may also simply link to you
12:58 mupuf: can you? I doubt it
12:58 karolherbst: you can
12:59 mupuf: well, what if there are local and glbal symbols
12:59 karolherbst: but then I am not quite sure _what_ you get exactly
12:59 mupuf: and the app wants the global one
12:59 mupuf: seriously, I try to avoid being smart here
12:59 karolherbst: but with NULL you get at least your executable
12:59 karolherbst: I already used it once for a plugin system
12:59 mupuf: be transparent, that's my goal
12:59 mupuf: which is local to an app
12:59 mupuf: so, cheating :p
13:00 karolherbst: yeah well, but with dlopen(NULL) you can get exported symbls out of an executable for example
13:01 karolherbst: but yeah, well you have all the dlopen references anyway, and maybe with dlopen(NULL) you get also those symbols from already loaded libraries
13:01 karolherbst: just a thought
13:02 karolherbst: but yeah, in the end how do you want to deal with the issue if you hit a symbol which isn't in the context yet
13:36 mupuf: karolherbst: I get what you are talking about now
13:36 karolherbst: :)
13:36 mupuf: did not know it was legal to dlopen a library and then just use a symbol without calling dlsym and using function pointers
13:36 mupuf: if not legal, at least accepted
13:37 karolherbst: yeah dlopen really adds the library to the current dl context
13:37 karolherbst: that't why you have all kind of RDTL? flags
13:37 karolherbst: *RTLD
13:38 karolherbst: like you could dlopen("libsome.so", RTLD_NOW) and if it fails, you know some deps aren't loaded yet
13:39 karolherbst: and if just want a handle, you pass RTLD_NOLOAD
13:39 karolherbst: then it won't be "loaded"
13:39 karolherbst: "Don't load the library. This can be used to test if the library is already resident (dlopen() returns NULL if it is not, or the library's handle if it is resident). This flag can also be used to promote the flags on a library that is already loaded. For example, a library that was previously loaded with RTLD_LOCAL can be reopened with RTLD_NOLOAD | RTLD_GLOBAL. This flag is not specified in POSIX.1-2001."
13:41 karolherbst: and then you also have that LOCAL/GLOBAL thing to specify if every binary will see it or just yours
13:42 karolherbst: like if you would open with LOCAL, the application would trigger a GLOBAL load later if it would call an unresolved symbol
13:42 mupuf: yeah, but you are missing the point
13:43 mupuf: the application is not using dlsym to find the symbol for dri3
13:43 mupuf: err, xcb
13:43 karolherbst: and?
13:43 karolherbst: the symbol will be resolved at some point in time
13:43 mupuf: and, there are no flags given aside from the one given with dlopen
13:43 karolherbst: if there is no library loaded for this unresolved symbol and no lookup was made, the runtime should look it up and load the required library
13:44 mupuf: by load, you mean only if it was dlopened with LAZY
13:44 mupuf: it is not going to open all your libraries on your system to find the symbol
13:44 karolherbst: right
13:44 karolherbst: well _env_dump_resolve_symbol_by_name was called for that xcb function
13:45 mupuf: yep
13:45 mupuf: and it returns NULL
13:45 karolherbst: right
13:45 mupuf: that means that the application never looked the symbol up
13:45 karolherbst: well you use _dl_sym
13:45 karolherbst: it just returns the function pointer to that symbol
13:46 mupuf: and _dl_sym(RTLD_NEXT, symbol, _env_dump_resolve_symbol_by_name) failed
13:46 karolherbst: it won't load any libraries
13:46 mupuf: well, it is loaded DYNLINK,/usr/lib/libxcb-dri3.so.0,1624047c67518e052720261f844562d82f9ead96
13:47 karolherbst: right, but that doesn't mean it is loaded yet
13:47 mupuf: it is a dependency of the libgl
13:47 karolherbst: it just means, dl would check inside this library for this unresolved library
13:47 karolherbst: at symbol resolve time
13:47 karolherbst: *symbol
13:48 mupuf: and dlsym would fail too to find it then?
13:48 karolherbst: you can dynlink a lot of libraries, but that doesn't mean all are loaded before main()
13:48 karolherbst: right
13:48 karolherbst: because the library isn't loaded
13:48 karolherbst: what you could do is this
13:48 mupuf: that sounds entirely retarded
13:48 karolherbst: just to try it out
13:49 karolherbst: dlopen(NULL, RTLD_NOW); and dl_sym again
13:49 karolherbst: well I try that
13:50 karolherbst: mhh okay, something else is missing
13:52 karolherbst: mhh right I think dlopen also don't load new libraries :/
13:53 karolherbst: funny though, before that lookup "calling init: /usr/lib64/libxcb-dri3.so.0"
13:56 mupuf: I guess the issue is that the symbol is already existing, so either it would return envdump's hook
13:56 mupuf: or it would look for other libs
13:56 mupuf: and this is what I wanted to do with RTLD_NEXT
13:57 mupuf: but I apparently failed to identify one case :s
13:57 karolherbst: yeah I know
13:57 mupuf: hooking xcb has not been working really great with mesa
13:57 mupuf: dri3 works, but not dri2
13:58 karolherbst: mhh but you want something like this: when symbol lookup is triggered from !symbol, return env_dumps reference or dlsym
13:58 karolherbst: as far as I understand the situation
13:58 karolherbst: and when symbol lookup is triggered from symbol (from env_dump), return RTLD_NEXT reference through dlsym
13:59 mupuf: well, ld already returns envdump's sumbol
13:59 mupuf: yes, this is what should be happening
14:01 karolherbst: mhh I should check if with LD_PRELOADing xcb3 I still get the XCB_CONNECTION,DRI3 print
14:02 karolherbst: yeah.. XCB_CONNECTION,DRI3,unknown
14:02 mupuf: depends on the order
14:02 karolherbst: right, but if I preload xcb3 after env_dump
14:03 karolherbst: it works and prints it
14:03 mupuf: yep
14:04 karolherbst: ohhhh
14:04 mupuf: maybe I should get the dlopen ID of libGL and try to dl_symp with it
14:04 karolherbst: ldd heaven_x64 :D
14:04 karolherbst: ohh wait
14:04 karolherbst: it loads libUnigine
14:04 karolherbst: ohh crap
14:04 karolherbst: I think they dlopen libGL
14:04 mupuf: yes, they do
14:05 karolherbst: but link against libxcb.so though
14:05 mupuf: do they link against libxcb?
14:05 mupuf: can't see it
14:05 karolherbst: ldd bin/libUnigine_x64.so
14:05 karolherbst: libxcb.so.1 => /usr/lib64/libxcb.so.1
14:05 mupuf: oh right
14:06 mupuf: missed it
14:06 mupuf: but it is not xcb-dri3
14:06 karolherbst: no, because why should they care?
14:06 mupuf: exactly
14:07 karolherbst: do you save how applications are dlopening?
14:07 mupuf: I save the handles, yes, IIRC
14:07 karolherbst: with the flags?
14:08 mupuf: hmm, actusally, no
14:08 mupuf: I do not save it
14:08 karolherbst: I have a great idea now :D
14:09 karolherbst: dlopen file: libGL.so.1, flags 1
14:10 karolherbst: mhh RTLD_LAZY
14:11 mupuf: we could replace LAZY with NOW
14:11 karolherbst: nope
14:11 karolherbst: can't do
14:11 karolherbst: GLWrapper::init(): can't load "libGL.so.1" library
14:11 karolherbst: :D
14:13 karolherbst: ahh I have an idea
14:13 karolherbst: yep
14:13 karolherbst: you add | RTLD_GLOBAL
14:13 karolherbst: then it works
14:14 karolherbst: because of reasons :D
14:14 karolherbst: RTLD_LOCAL is default
14:15 mupuf:fears it will break some things
14:15 karolherbst: so 1: RTLD_LAZY | RTLD_LOCAL
14:15 karolherbst: well
14:15 karolherbst: you could try to only change if neither is set
14:15 karolherbst: if RTLD_LOCAL is explicitly set, then don't add GLOBAL
14:15 mupuf: I doubt I can find it out :D
14:15 karolherbst: you can
14:16 karolherbst: as I said: LOCAL is default
14:16 mupuf: #define RTLD_LOCAL 0
14:16 karolherbst: ohhh
14:16 karolherbst: ...
14:16 karolherbst: ....
14:16 mupuf: hence why it is "the default" :p
14:16 karolherbst: why.. why :D
14:16 karolherbst: well
14:16 karolherbst: the standard says it is default
14:16 karolherbst: "This is the converse of RTLD_GLOBAL, and the default if neither flag is specified. Symbols defined in this library are not made available to resolve references in subsequently loaded libraries."
14:16 karolherbst: :/
14:17 karolherbst: at least man page says that
14:17 mupuf: Zero or more of the following values may also be ORed in flag:
14:17 mupuf: and yoiu can OR both GLOBAL and LOCAL :D
14:17 karolherbst: :D
14:17 karolherbst: awesome
14:17 karolherbst: well
14:17 karolherbst: LOCAL is 0
14:17 mupuf: which meant one was a noop
14:17 karolherbst: so yeah
14:17 karolherbst: you always give both
14:17 karolherbst: what a crap :/
14:18 mupuf: well, we have not lost everything ye
14:18 mupuf: t
14:18 karolherbst: right
14:18 mupuf: I can always keep a list of opened SOs
14:18 mupuf: and do a linear search there
14:18 mupuf: should work, right?
14:18 karolherbst: yeah, but you have to dlopen them again
14:19 mupuf: if I do this, it won't solve naything
14:19 karolherbst: dlopen(lib, RTLD_NOLOAD)
14:19 karolherbst: well
14:19 karolherbst: dlopen(lib, RTLD_NOLOAD | RTLD_GLOBAL)
14:19 mupuf: nope, I don't want to do this
14:19 mupuf: once I have a handle, I can dlsym there
14:19 karolherbst: well you have to when you don't have the library handle
14:19 karolherbst: ahh right
14:20 karolherbst: if you have the handle it is alright
14:20 mupuf: so, I just need to store handles and search through them
14:20 mupuf: this way, we do not change the behaviour
14:20 karolherbst: you know something funky?
14:20 mupuf: ?
14:20 karolherbst: guess what happens if there is a library like gameoverlayrenderer.so :D
14:21 mupuf: well, hopefully, everyone will point to the same xcb version :d
14:21 karolherbst: I more like meant the situation if they already intercept other stuff
14:22 karolherbst: and then you call the original one for one or two things, but the application itself calls that wrapper
14:22 karolherbst: and then the wrapper is confused, because stuff is missing
14:23 mupuf: yep, but this is why I call _NEXT
14:23 mupuf: so we can chain hooks
14:23 karolherbst: right, but how d you call _NEXT wit the handle?
14:24 mupuf: I can't
14:24 karolherbst: imagine you hook something, which was LOCAL locaded, then you search this symbol, allthough it is also hooked by the application_wrapper
14:24 mupuf: I have to do it before
14:24 karolherbst: mhh but that should like never happen, just an theory what else could wrong
14:24 mupuf: yeah... let's fix this and wait for the next bug :D
14:26 karolherbst: I hate those cards which can have multiple chipsets
14:28 imirkin: hansg: saw the email, don't know what's going wrong offhand, will have a look over the weekend probably
14:29 imirkin: hansg: i don't remember if it's in the email, but in case it's not, a full tgsi program that repros the issue would be great
14:31 DebianLinuxero: Hello.
14:32 DebianLinuxero: Is it normal that mmiotrace takes more than 40 min?
14:32 karolherbst: DebianLinuxero: to start X?
14:32 karolherbst: check dmesg
14:32 DebianLinuxero: Yes.
14:32 karolherbst: check dmesg
14:33 DebianLinuxero: https://bugs.freedesktop.org/show_bug.cgi?id=95044
14:33 imirkin: no. a few minutes is not unusual. 40 minutes is unusual.
14:33 karolherbst: DebianLinuxero: again, check dmesg
14:33 karolherbst: I have an idea what issue you might have triggered, but dmesg will tell you
14:33 DebianLinuxero: The system got freeze and can't switch to console to see dmesg.
14:34 karolherbst: mhh
14:35 karolherbst: DebianLinuxero: I guess you don't compile your kernel yourself?
14:35 karolherbst: DebianLinuxero: this might fix it: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86/mm/kmmio.c?id=cfa52c0cfa4d727aa3e457bf29aeff296c528a08
14:35 DebianLinuxero: I've got to push the reset button to leave.
14:35 karolherbst: but without the kmsg output I can't be sure it is this issue or something else
14:36 DebianLinuxero: It was a distro packaged kernel.
14:38 DebianLinuxero: That patch, what kernel version is meant for?
14:39 karolherbst: this is for 4.6, but it should also apply for much older ones
14:39 karolherbst: last change to that file was like in 2014-01-07
14:39 karolherbst: and before that 2010-06-18
14:39 karolherbst: mhh
14:39 karolherbst: maybe it might make sense to add it to stable kernels as well...
14:39 hansg: imirkin, I posted the full TGSI program (minus DCL TEMP statements) in the thread
14:40 imirkin: hansg: full program i can just paste into nouveau_compiler would be great
14:41 hansg: imirkin, I'm seeing this problem with my fix to avoid the undesirable combining of loads / stores
14:41 hansg: imirkin, let me get that for you and pastebin it
14:41 imirkin: NV50_PROG_DEBUG=1 should print it, among other things
14:42 imirkin: bbl
14:52 karolherbst: what should I do when somebody send an email to the mmiotrace account and explicitly stated he wants his email to remain private?
14:53 hansg: imirkin: https://paste.fedoraproject.org/358619/ Problem is at the end of the sub starting at pc==25
14:53 hansg: I reproduced the problem with that one with nouveau_compiler -a e4
14:54 hansg: thanks you for looking into this
14:57 mupuf: karolherbst: Found the symbol 'xcb_dri3_open_reply_fds' in a local library!
14:57 mupuf: it works :)
14:57 karolherbst: :)
14:58 karolherbst: awesome
14:58 karolherbst: mupuf: but maybe you should check all libraries
14:58 karolherbst: and if you find it more than once print a warning or something
14:58 karolherbst: or notice it in the env_dump
14:58 mupuf: oh, right
14:58 mupuf: sounds like a good idea
14:58 mupuf: if they do not all resolve to the same addr, then it seems like a good idea to warn
14:59 karolherbst: and also save those flags passed to dlopen, just in case :)
14:59 karolherbst: actually
14:59 mupuf:will only add the ones added with LOCAL
14:59 karolherbst: there might be reasons it can resolve to different ones
14:59 mupuf: otherwise, we are wasting time
14:59 karolherbst: if multiple libraries open the same library with LOCAL
14:59 karolherbst: it should resolve to different ones, right?
14:59 mupuf: I don't think so
14:59 karolherbst: well easy to find out
15:00 mupuf: it is search trees that are local
15:00 karolherbst: mhh okay
15:00 mupuf: not the actual code
15:00 karolherbst: okay
15:00 karolherbst: we really should look more often in the mmiotrace account
15:00 karolherbst: there are some who wants to offer tests on hardware and stuff
15:01 mupuf: oh, cool!
15:01 karolherbst: some with SLI setups
15:01 karolherbst: but it is like form 2013
15:01 mupuf: for some reason, I cannot open it anymore :s
15:01 fishxz: he, is this something i need to worry about
15:01 fishxz: [ 22.310634] nouveau 0000:01:00.0: clk: failed to raise voltage: -22
15:01 fishxz: [ 22.310638] nouveau 0000:01:00.0: clk: error setting pstate 3: -22
15:01 karolherbst: fishxz: not really, just wait until my patches land :D
15:01 karolherbst: fishxz: fermi?
15:02 fishxz: gtx 760 so assume maxwell?
15:02 karolherbst: ohh
15:02 karolherbst: right
15:02 karolherbst: 3 is 0xf in that case
15:02 karolherbst: ...
15:03 karolherbst: mupuf: ^ see how the index as pstate is a bad idea :D
15:03 karolherbst: fishxz: it is the 0xf pstate right?
15:03 mupuf: karolherbst: that is indeed a fair point
15:03 fishxz: 0f
15:03 fishxz: i set
15:04 karolherbst: okay
15:04 karolherbst: 760 is kepler
15:04 fishxz: ye, i was wrong
15:04 fishxz: sorry
15:04 karolherbst: I just though it was 0x3 pstate
15:04 karolherbst: this isn't a thing on kepler and newer
15:04 karolherbst: mhh okay
15:04 karolherbst: fishxz: do you compile your kernel yourself?
15:05 fishxz: nope, im on 4.5 debian kernel
15:05 karolherbst: ohh well 4.5 is fine too
15:05 karolherbst: if you are up to
15:05 karolherbst: you could compile my branch
15:05 karolherbst: https://github.com/karolherbst/nouveau.git branch: stable_reclocking_kepler_v5
15:05 karolherbst: cd drm; make
15:05 karolherbst: you just need all those kernel source packages and stuff
15:06 karolherbst: and reinstall this module on every kernel update and regenerate initramfs
15:06 karolherbst: if not, you can always wait until 4.8 hits debian
15:06 karolherbst: so 2 years
15:06 fishxz: im on testing ;)
15:06 fishxz: u think it will take 2 years?
15:06 karolherbst: testing is before sid, right?
15:06 fishxz: yes
15:06 fishxz: sid is unstable
15:07 karolherbst: I don't know how much testing gets updated shortly after a release was done
15:07 fishxz: ok after make, what i have to do? sorry im not rly used to this stuff.
15:07 karolherbst: mhh
15:08 karolherbst: there is /lib/modules/$kernel-version-tage/kernel/drivers/gpu/drm/nouveau/nouveau.ko(.xz)
15:08 karolherbst: just delete it and copy nouveau/nouveau.ko where it was
15:08 fishxz: so its just a replace for the nouveau module?
15:08 karolherbst: yeah
15:08 fishxz: kk i see
15:08 karolherbst: but beware of the file ending
15:09 karolherbst: and then you regenerate initramfs
15:09 karolherbst: and after you reboot you should see a file called "boost" inside /sys/kernel/debug/dri/0/
15:10 fishxz: sorry for the stupid question. i dont have to recompile the kernel, right?
15:10 karolherbst: fishxz: just to confirm this. After you set the pstate to 0xf, the last line of the pstate file still contains a low core clock, right?
15:10 karolherbst: fishxz: no
15:11 fishxz: 0f: core 405-1293 MHz memory 6008 MHz AC DC *
15:11 fishxz: AC: core 405 MHz memory 6007 MHz
15:11 karolherbst: k
15:11 fishxz: i will try to compile ur stuff ;)
15:11 karolherbst: k :)
15:16 imirkin: hansg: just fyi, you can do DCL TEMP[0..31]
15:16 karolherbst: RSpliet: by the way, I add a bunch of fermi traces to the repository :)
15:16 imirkin: a little nicer to read... same underlying functionality
15:18 fishxz: karolherbst: http://pastebin.com/zbtpZsPd was does this mean?
15:19 karolherbst: fishxz: you need your kernel source packages
15:19 imirkin: hansg: anyways, i've saved it off. will try to remember to look at it over the weekend.
15:19 karolherbst: or maybe linux-header package as awell
15:19 fishxz: header i installed already
15:19 fishxz: is it the linux-source package on debian?
15:20 karolherbst: fishxz: well you need it for your current running kernel as well
15:20 karolherbst: something like linux-headers-4.2.0-16-generic just for your version
15:20 fishxz: yep, just installed the right one
15:21 karolherbst: so it compiles now?
15:21 fishxz: im installing source now. takes a few sec
15:21 fishxz: to dl
15:22 fishxz: still same error
15:22 karolherbst: ahh right
15:22 fishxz: http://pastebin.com/qYJXGcJJ
15:23 karolherbst: mhh okay /lib/modules/4.5.0-1-amd64/source
15:23 karolherbst: go into that directory
15:23 fishxz: i am
15:23 karolherbst: then the output of ls -lah
15:23 fishxz: http://pastebin.com/1Jrge3UE
15:25 karolherbst: and I guess there is no include/generated/autoconf.h or conf.h
15:26 fishxz: there is not even a generated folder
15:26 karolherbst: do you have linux-headers-4.5.0-1-amd64 installed?
15:27 fishxz: linux-headers-amd64/testing,testing,now 4.5+72 amd64 [installiert]
15:27 fishxz: thats the only headers i can even find
15:27 karolherbst: mhh
15:27 fishxz: for amd64
15:27 karolherbst: odd because: https://packages.debian.org/search?searchon=contents&keywords=include%2Fgenerated%2Fautoconf.h&mode=exactfilename&suite=testing&arch=any
15:29 fishxz: i was wrong. this file is there
15:29 fishxz: as it shown there
15:29 fishxz: /usr/src/linux-headers-4.5.0-1-amd64/include/generated/autoconf.h
15:29 karolherbst: okay
15:29 karolherbst: then something else is fishy, good
15:29 karolherbst: go into /usr/src/linux-headers-4.5.0-1-common
15:30 karolherbst: and give me ls -lah
15:30 fishxz: https://paste.gnome.org/prwczcmvy
15:30 karolherbst: is there a file include/generated/autoconf.h ?
15:31 karolherbst: it should be, because it is the same :D
15:31 fishxz: https://paste.gnome.org/pldgwvzrm
15:31 fishxz: nope
15:31 karolherbst: :O
15:31 karolherbst: ...
15:32 karolherbst: what does uname -r give you?
15:32 fishxz: 4.5.0-1-amd64
15:32 karolherbst: mhh no idea what is wrong then :/
15:32 mupuf: karolherbst: fix pushed
15:32 karolherbst: mupuf: awesome
15:33 mupuf: actually, wait a sec
15:33 fishxz: ERROR: Kernel configuration is invalid.
15:33 fishxz: include/generated/autoconf.h or include/config/auto.conf are missing.
15:33 fishxz: Run 'make oldconfig && make prepare' on kernel src to fix it.
15:33 fishxz: maybe this karol?
15:33 fishxz: :o
15:33 karolherbst: usually you don't need to run this
15:33 mupuf: ok, now it is done
15:33 karolherbst: and shouldn'
15:33 fishxz: hm
15:34 karolherbst: mupuf: yeah, seems to work
15:35 fishxz: some one says "ln -s /usr/src/linux-headers-2.6.38-1-686/include/generated/autoconf.h /usr/src/linux-headers-2.6.38-1-686/include/linux/"
15:35 fishxz: so a symlink
15:35 fishxz: and he mean it worked
15:36 mupuf: karolherbst: good! You are credited by the way, thx a lot!
15:36 karolherbst: :)
15:38 karolherbst: fishxz: yeah, well you should symlink the entire generated directory
15:38 karolherbst: and not into include/linux
15:39 karolherbst: so ln -s include/generated to $kernel-headers/include/
15:39 karolherbst: ohh wait
15:40 karolherbst: no, loooks okay
15:40 karolherbst: fishxz: but in the end you shouldn't need to do it
15:41 karolherbst: mupuf: by the way, how much space is left for the traces?
15:47 fishxz: karolherbst: https://paste.gnome.org/p6pcnashz
15:48 karolherbst: fishxz: yeah it will get messy when something is broked here :/
15:48 karolherbst: *borked
16:41 hansg: imirkin, wrt DCL TEMP[0..31] good to know, I'll update the llvm backend accordingly. Time for me to call it a day now. ttyl
17:19 chunky_: Evening
17:21 chunky_: I'm trying to get at the kernel driver which supports GM200?
17:21 chunky_: I've tried linux-4.6 from the git, I'm not having much success
17:22 chunky_: Am I being a bit dense?
17:23 karolherbst: chunky_: you also need the firmware files
17:24 karolherbst: chunky_: could you please paste your entire dmesg output somewhere?
17:24 chunky_: with the module inserted or not - I can't get the module to insert, the machine hangs and I don't appear to end up with a kernel log from that boot
17:25 chunky_: I'm just about to try and setup a console to get at what is happening, but I thought I'd check I have the right version first
17:25 karolherbst: well if you can't provide us with any error, there isn't much we can do :/
17:26 chunky_: nope, there isn't, but I'd like to try and get at the error for you if I can
17:30 imirkin_: chunky_: you need the nvidia firmware, although the module should load without it. that firmware is only needed for acceleration
17:30 imirkin_: chunky_: that said, i don't remember if GM200 support went into 4.6 or not
17:30 imirkin_: it was a "late" addition...
17:30 chunky_: OK
17:31 chunky_: I'm working off the note on the site - it suggests that it went in
17:31 imirkin_: yeah, looks like it should be there in 4.6...
17:31 chunky_: but, what I'm seeing suggests that it didn't, my machine behaves the same as it did with an historical version
17:31 imirkin_: get a dmesg :)
17:32 chunky_: Ha! So far that's proving easier said than done
17:32 chunky_: but I'll try
17:32 karolherbst: when anybody wants traces for specific chipsets, please tell me so, because then I would add them first
17:32 imirkin_: modprobe nouveau; dmesg > foo.txt
17:34 chunky_: hello again
17:35 chunky_: ok,it gives an error about the firmware
17:35 karolherbst: that was fast
17:35 chunky_: has left the screen locked
17:35 karolherbst: mhh yeah maybe the kernel messes up switching the fb or something
17:35 karolherbst: chunky_: you could try if you can still ssh into the machine
17:36 chunky_: i am :-)
17:36 karolherbst: ahh okay
17:36 karolherbst: so just the display is messed up
17:36 chunky_: i think that is what happened, no firmware so nouveau hasnt loaded properly but kernel hasnt got fb back
17:37 karolherbst: yeah, sounds about right
17:37 karolherbst: still shouldn't happen
17:37 chunky_: i'll grab the firmware and try, are there any instructions?
17:37 karolherbst: linux-firmware repositry
17:37 karolherbst: *repository
17:37 chunky_: ok
17:37 karolherbst: maybe your package is new enough
17:37 chunky_: one sec,ill reboot so i can use the pc,this laptop is a faff
17:37 karolherbst: firmware was added 2016-02-23
17:41 karolherbst: mupuf: do you mind when I rename gm206 to nv126?
17:55 karolherbst: ohhh nice
17:55 karolherbst: nvf0 trace
18:34 chunky_: thanks for the help folks - up and running now
18:35 fishxz: karolherbst: got it compiled after hours of research. i copied the file to the right place and run update-initramfs -u but there is still no boost file
18:35 karolherbst: fishxz: did you copy it also to the right place?
18:35 fishxz: /lib/modules/4.5.0-1-amd64/kernel/drivers/gpu/drm/nouveau/
18:36 fishxz: drwxr-xr-x 2 root root 4096 Apr 22 20:30 .
18:36 fishxz: drwxr-xr-x 24 root root 4096 Apr 21 12:03 ..
18:36 fishxz: -rw-r--r-- 1 root root 113339648 Apr 22 20:30 nouveau.ko
18:36 fishxz: -rw-r--r-- 1 root root 2336312 Apr 14 17:57 nouveau.ko_old
18:37 fishxz: there i way to check if its loaded?
18:37 fishxz: the right one
18:39 karolherbst: fishxz: dmesg output then
18:40 fishxz: http://pastebin.com/5dK5hZQ8
18:43 karolherbst: fishxz: ohh wait
18:43 karolherbst: fishxz: did you change the branch?
18:43 fishxz: git checkout and what u have told me earlier
18:43 karolherbst: mhh
18:43 RSpliet: karolherbst: thanks. I haven't had time to look into Fermi reclocking recently... I'll make sure to make good use of them once I find some free time again :-P
18:44 karolherbst: fishxz: could you check what is the newest commit in git log?
18:44 karolherbst: RSpliet: :)
18:44 fishxz: where to find this git log?
18:44 karolherbst: RSpliet: if there are trace for specific chipsets I could try to check if there are some missing in the repository
18:44 karolherbst: fishxz: "git log"
18:48 fishxz: this file is so huge and im not sure what i have to look for :|
18:48 fishxz: https://paste.gnome.org/pe7zzakk5
18:48 fishxz: this is the last one
18:49 fishxz: https://paste.gnome.org/pk74h62fz
18:49 fishxz: this looks more right :)
18:49 fishxz: hehe
18:49 karolherbst: still old
18:49 karolherbst: well wrong
18:49 RSpliet: karolherbst: just pushed my nvf0 trace, in case you wanted to have a crack at the PLL regs
18:50 karolherbst: do git checkout stable_reclocking_kepler_v5
18:50 fishxz: Bereits auf 'stable_reclocking_kepler_v5'
18:50 fishxz: im already there
18:51 karolherbst: odd
18:51 karolherbst: git log commits is wrong though
18:51 karolherbst: let me check
18:51 fishxz: cd /usr/src/linux-headers-4.5.0-1-amd64/
18:51 fishxz: make M=/home/daniel/Downloads/nouveau/drm/nouveau KCPPFLAGS="" modules
18:51 fishxz: this is btw how i compiled it now
18:52 fishxz: i think this should be fine?
18:52 karolherbst: fishxz: top of git log should show you "volt: add NvVoltOffsetmV option"
18:52 karolherbst: fishxz: then do this: git reset --hard origin/stable_reclocking_kepler_v5
18:52 karolherbst: and check if git log has changed
18:52 RSpliet: karolherbst: assuming the remote is named origin
18:53 karolherbst: right
18:53 RSpliet: git remote -v should help determine that
18:53 fishxz: daniel@daniel-debian:~/Downloads/nouveau$ git reset --hard origin/stable_reclocking_kepler_v5
18:53 fishxz: HEAD ist jetzt bei a298024 volt: add NvVoltOffsetmV option
18:53 karolherbst: yay
18:53 karolherbst: recompile and install again :)
18:53 fishxz: ;)
18:56 fishxz: i gonna reboot. brb
18:58 fishxz: boost file is there ;)
18:58 karolherbst: k
18:58 karolherbst: then you should be able to reclock the pstates
18:59 karolherbst: the boost file is just there to change the upper clock limit, but it defaults to the lowest one, because we don't cap the power usage for now
18:59 fishxz: http://www.phoronix.com/scan.php?page=article&item=nouveau-boost-perf&num=1
18:59 fishxz: so like here in this guide?
19:00 karolherbst: "guide"
19:00 fishxz: hehe
19:00 fishxz: ye ;)
19:01 karolherbst: well does sensors show you the power consumption?
19:01 fishxz: let me install sensors
19:03 fishxz: wow
19:03 fishxz: fps with boost is like 2 times better in cs go
19:03 fishxz: 200fps
19:04 karolherbst: fishxz: you should encounter big fps drops when a much of shooting is going on
19:04 fishxz: power1: 27.96 W
19:04 karolherbst: ahh okay
19:04 fishxz: the thing with boost is, my fan goes crazy
19:04 fishxz: ;)
19:04 karolherbst: this might be another bug
19:04 karolherbst: temperature?
19:05 karolherbst: okay, nvidia says 170W can be drawn out of your gpu
19:05 fishxz: temp1: +56.0°C
19:05 karolherbst: if you get too close to that while running at boost 2
19:05 karolherbst: you should rather use boost 1
19:05 karolherbst: and so on
19:05 fishxz: im on 1
19:06 karolherbst: 1 is usually safe, but 2 is most likely not, well it should be under normal load
19:06 karolherbst: just it might be that sometimes too much powr is drawn for weird reasons
19:06 fishxz: im 56 °C is pretty cool
19:06 karolherbst: right
19:06 fishxz: fan shouldnt go that high
19:06 karolherbst: but the fans are at around 50 or 60% I would assume?
19:08 karolherbst: mupuf: you know what? I think I will try to RE those fan bits in the meantime :) or at least I write the implementation for using that one table
19:08 fishxz: fan1: 2100 RPM
19:08 karolherbst: too many users are complaining now :D
19:08 fishxz: dunno if this is high, but i never seen my fan going this high
19:08 fishxz: never
19:08 fishxz: not even in benchmarks
19:08 karolherbst: fishxz: could you upload your vbios somewhere? /sys/kernel/debug/dr/0/vbios.rom
19:08 fishxz: sure
19:09 karolherbst: fishxz: yeah I know. In the kepler vbios' is a fan table with non linear growth
19:09 karolherbst: it is mostly like this: 40°C 10%, 80°C 25%, 90°C 100% :D
19:09 karolherbst: but we don't use it yet
19:09 karolherbst: because we don't know when
19:10 fishxz: u know a place where i can upload files?
19:10 karolherbst: anywhere you can usually find something just by searching
19:10 fishxz: http://195.93.242.155/~quake2test/vbios.rom
19:10 karolherbst: I use most of the time this: http://filebin.ca/
19:10 karolherbst: no idea if there are ads or not
19:12 karolherbst: this is the table I mean: https://gist.github.com/karolherbst/6fd3bf39fa8406286ddfbac73284eae1
19:12 karolherbst: so 2100 rpm should only be reached above 79°C
19:12 karolherbst: if this is right
19:12 karolherbst: we didn't really verified it yet though
19:13 fishxz: so something is wrong ;)
19:13 fishxz: u seen my vbios link?
19:14 karolherbst: this is from your vbios
19:14 fishxz: yes
19:14 fishxz: its my file
19:15 karolherbst: no, I meant my link
19:15 karolherbst: the table
19:15 karolherbst: is from your vbios
19:15 karolherbst: hakzsam: will you need reator again today?
19:15 fishxz: ah
19:15 fishxz: isee
19:15 fishxz: lol
19:17 karolherbst: mupuf: and another thing: for me gputest just simply doesn't quite, even after the benchmark is done
19:18 karolherbst: mupuf: maybe you want to add a timeout whenever you know the benchmark should be done by now
19:23 karolherbst: mupuf: :'( ./bin/heaven_x64: symbol lookup error: /usr/lib64/libudev.so.1: undefined symbol: drmGetPrimaryDeviceNameFromFd
19:26 karolherbst: it worked like a few hours ago...
19:29 karolherbst: ohh that might be mesa
19:32 fishxz: my fault. even without boost my fan is louder than usual
19:33 karolherbst: yeah,
19:33 karolherbst: it doesn't depend on boost
19:33 fishxz: ah i see
19:33 karolherbst: just depends on the temperature
19:33 karolherbst: but it isn't that bad
19:33 karolherbst: having slower fans would be bad
19:34 fishxz: sure :D
19:34 SaveTheRobots: hey karolherbst, is _v2 still the best kepler reclocking branch to use, or shall i switch to _v5? i just noticed its existence...
19:34 karolherbst: mhh the most tested one is v4 but v5 should be fine too
19:34 SaveTheRobots: i'm all up for bleeding-edge, i'd go v5 :]
19:34 SaveTheRobots: i'll*
19:37 fishxz: one more question karolherbst. can i harm my gpu with the boost option?
19:37 karolherbst: I am not sure because nobody ever reached the point where the gpu used too much power
19:37 karolherbst: the GPU should just turn off by itself as it does on high temperatures
19:38 karolherbst: but maybe also your PSU could take a damage when the GPU draws too much power
19:39 karolherbst: with this patches we do the same as nvidia when boost is set to 2
19:39 karolherbst: but
19:39 karolherbst: we don't downclock on high power usage, that's all I think
19:39 fishxz: so better not testing it on a 980ti lol
19:39 karolherbst: well the 980ti can't reclock memory yet
19:39 karolherbst: so it doesn't matter
19:39 fishxz: ah ye, but it was anyway a joke ;)
19:39 karolherbst: well
19:39 karolherbst: some tested it on a 780 ti
19:40 karolherbst: there is usually no danger because you have to do a lot by exceeding the power budgets
19:40 karolherbst: I am just saying this, because we don't know what happens
19:40 RSpliet: nothing beats the TDP of a Titan Z
19:40 karolherbst: not even the pcie specs :D
19:41 RSpliet: but the GTX 590 Ti gets darn close :-P
19:41 karolherbst: ohh
19:41 karolherbst: the 590 ti also isn't pcie conform, good to know
19:42 karolherbst: *compliant
19:42 karolherbst: ...
19:42 karolherbst: conform is really an ugly word
20:20 Riastradh: Fallthrough intended in nv40_fifo_init switch case for device->chipset in {0x47, 0x49, 0x4b}?
20:21 imirkin_: probably... let's see
20:22 imirkin_: Riastradh: i think so, yes... both 2230 an 2220 get written
20:22 imirkin_: except for the "old" nv4x's
20:22 imirkin_: (i don't think 0x48 is even a thing... dunno)
20:23 imirkin_: and not sure about 0x45 either
20:24 imirkin_: and 0x47,0x49,0x4b are the G7x's
20:24 imirkin_: which leaves the IGP's which are handled by the default case
20:24 imirkin_: and a few others like nv44/nv4a
20:29 Riastradh: OK, thanks!
20:29 Riastradh: Coverity doesn't like it. So far every complaint Coverity has made about our import of nouveau in NetBSD has been spurious.
20:30 Riastradh: That is, Coverity doesn't like an unmarked fallthrough.
20:30 imirkin_: yeah
20:30 imirkin_: i'm not a fan either
20:30 imirkin_: i'd encourage you to send patches marking them
20:36 karolherbst: okay, I think we should really send the mmiotrace fix to stable kernels so that mmiotracing doesn't fail on older kernels
20:36 karolherbst: 4.5, 4.4 and 4.1 should be fine I think
20:59 karolherbst: mupuf: and I think it would be also nice to generate the report before every recompile of projects (maybe even while compiling)
21:47 karolherbst: yay, another nvf1 trace :)
22:29 mupuf: karolherbst: it is generating the report between every recompile
22:30 karolherbst: ohh really?
22:30 karolherbst: mhh
22:30 karolherbst: I can't access it though
22:31 karolherbst: yeah, no html files inside the log
22:40 karolherbst: mupuf: but it seems to run the stuff fine though. But I think there is still another issue left now with your fix
22:40 mupuf: karolherbst: do you use ./core.sh to run stuff or ezbenchd.py?
22:40 karolherbst: ezbenchd.py
22:40 mupuf: WTF
22:41 mupuf: there is supposed to be a index.html
22:41 karolherbst: I did this: ./ezbench -b unigine:valley:1080p:window -b unigine:heaven:1080p:window -b xonotic:1080p:window -r 2 -c "master..nouveau_opts" -p mesa nouveau_opts_xonotic_unigine run
22:41 karolherbst: then DRI_PRIME=1 utils/ezbenchd.py --http_server=0.0.0.0:8080
22:41 mupuf: btw, the normal way to do stuff is to have a systemd unit running ezbenchd
22:41 karolherbst: yeah I noticed
22:42 mupuf: so as, as soon as you run ./ezbench nouveau_opts_xonotic_unigine run
22:42 mupuf: it would start
22:42 karolherbst: but this has to wait until I write that ebuild :D
22:42 mupuf: :p
22:42 karolherbst: anyway, I am done with adding fermi+ stuff for today
22:43 karolherbst: the repository looks much better now anyway
22:43 karolherbst: a lot more stuff is there
23:35 mupuf: yeepee!
23:38 karolherbst: yay
23:38 karolherbst: :D