03:45 mangix: so, reclocking
03:46 mangix: i have a stupid idea to get it working under nouveau
03:46 mangix: set a custom resolution with the vertical blank turned way down
03:47 mangix: on windows, this makes the GPU unable to clock down
03:47 mangix:has to try this sometime
04:14 librin: mangix: sorry to disappoint You, but that doesn't do anything reclocking-wise
04:14 librin: first-hand experience
07:41 dboyan: mslusarz: you are right, GET_CHIPSET method call didn't work. To make it worse, demmt will override manual chipset selection with wrong data. Have to hack demmt to make -m input take precedence now.
07:41 dboyan: No idea how the blob know about chipset. With PCI ID?
08:49 karolherbst: dboyan: most likely with reg 0x0
08:49 karolherbst: mangix: well, engine reclocking works on most GPUs pre pascal
09:57 pmoreau: RSpliet: Shouldn’t you put those thoughts in a Trello card, so that you can easily find them back? Otherwise you’ll have to scroll through the entire logs to find them again… :-p
09:59 guanche: hi, is there a problem with GL_ARB_texture_buffer_object_rgb32? I can't see it on my glxinfo's output
10:55 karolherbst: guanche: depends on your gpu I would say
10:58 RSpliet: pmoreau: you're right, but I might just process them tonight straight away
11:01 guanche: the exact error I get is this one:
11:01 guanche: Mesa: User error: GL_INVALID_ENUM in glTexBuffer(internalFormat GL_RGB32UI)
11:01 guanche: I have a NVIDIA GeForce 8600M GT, nv84
11:02 guanche: all is compiled from git as of yesterday (the whole xorg), do you happen to know if the problem is my hardware, or mesa/nouveau or what karolherbst?
11:03 guanche: that error I get it with MESA_DEBUG=1
11:03 karolherbst: guanche: it's simple: nouveau doesn't support GL_ARB_texture_buffer_object_rgb32 on pre fermi hardware
11:03 guanche: ok, so any software that uses it from now on, I couldn't use it?
11:05 karolherbst: guanche: basically, yes. You could set MESA_EXTENSION_OVERRIDE=GL_ARB_texture_buffer_object_rgb32 and check if the application still works though
11:06 guanche: thanks, let me try
11:06 karolherbst: guanche: do you happen to know if nvidia supports this extension for your GPU?
11:06 guanche: no, I don't know karolherbst
11:06 karolherbst: but I think imirkin_ knows more about how easy/difficult it would be to add support for that
11:07 guanche: the program I'm trying to run, which is kitty (an opengl terminal) before it didn't show up anything, just a black window
11:08 guanche: now, with that option you gave me, shows some garbled blue cells instead of text
11:09 pmoreau: RSpliet: Ah, ok. I thought your future you would be a bit more “futuristic”. ;-)
11:11 karolherbst: guanche: is there an option to disable OpenGL 3.x stuff?
11:13 guanche: on kitty karolherbst? no that I've seen
11:16 RSpliet: pmoreau: I'm being optimistic I'm afraid
11:17 RSpliet: On the other hand, documenting it for reals in the kernel sources has no major implications, so fairly trivial little patch
11:26 pmoreau: RSpliet: Booh, don’t be optimistic, that’s bad! :-D Though I tend to do the same about my clover serie… and there is always something that comes along and destroys my plans. :-/
11:26 dboyan: karolherbst, my system always hangs when I try to mmiotrace programs using nvenc. Any ideas about why or how to find out the problem?
11:27 dboyan: even initializing will hang the system. sysrq magic can work at least for the first few seconds
11:27 dboyan: but all the log are gone after reboot
11:32 pmoreau: RSpliet: That article looks interesting! I’ll have a read over the week-end. :-)
11:32 RSpliet: pmoreau: it's on my to-read list now as well...
12:38 karolherbst: dboyan: could you try without the X server?
12:38 karolherbst: dboyan: there might be some odd bug I couldn't find in the mmiotrace code, but it still works
12:38 karolherbst: a few threads just stop for odd reasons
14:02 dboyan: karolherbst, I tried without X, and it still hangs
14:22 karolherbst: dboyan: what ist your kernel version?
14:22 karolherbst: ohh wait, you are using nvidia, there shouldn't be any issues left I hope
14:22 karolherbst: odd
14:24 dboyan: karolherbst: I did get some mmiotrace this time, and fyi my kernel version is 4.9.11
14:24 dboyan: Nothing left in the journal though
14:24 karolherbst: mhhh
14:25 karolherbst: anything in dmesg?
14:25 dboyan: No, it stopped at "mmiotrace: enabled."
14:26 dboyan: The Fn-lock light on my keyboard stops responding when system hang happened, but I'm able to reboot with sysrq magic
14:27 karolherbst: mhh
14:27 karolherbst: maybe there is a new issue now, odd
14:27 karolherbst: dboyan: could you give me in detail how you trigger that issue?
14:27 karolherbst: I might have some times this weekend to look into it then
14:27 karolherbst: but
14:28 karolherbst: did you take a look at the mmt traces already?
14:28 dboyan: only mmio ones
14:28 karolherbst: because I suppose that most of the magic is there and the mmiotrace just contains some host <-> NVENC interactions
14:28 karolherbst: okay, then you could look at the mmt stuff already
14:28 karolherbst: there you also will see the input and the output
14:29 karolherbst: and stuff like it
14:29 karolherbst: and I will try to figure out what's wrong with the mmiotracer
14:31 dboyan: yeah, mmt tracing works all right. But when mmiotrace is on, it hangs very soon
14:32 dboyan: Even before that NvEncOpenEncodeSessionEx finishes
14:32 karolherbst: could you list all the things you do while mmiotracing so I can reproduce this issue?
14:36 dboyan: I have a little program at https://people.freedesktop.org/~dboyan/encdemo.tar.xz compile it and run under mmiotrace, and that's enough to hang my system
15:01 karolherbst: dboyan: okay, nice thanks
15:35 karolherbst: and now that we like maybe most likely have to sent our nouveau changes to linus directly, maybe I should just setup all the travis-ci things I planed to do anyway
16:09 karolherbst: "Trying Nouveau With HITMAN On Linux Doesn't Get Too Far" :D that optimism
16:19 RSpliet: karolherbst: well, compared to linus' language it's not too bad
16:19 RSpliet: and yes, I'm all in favour of CI, but don't underestimate the complexity ;-)
16:23 imirkin_: did i accidentally something?
16:37 Echelon9: karolherbst: What additional CI were you thinking of? Lower down in the stack? Currently we mesa-based nouveau and libdrm through travis-ci
16:40 RSpliet: Echelon9: does travis-ci actually test on actual real actual nvidia HW?
16:41 RSpliet: And an actual representative subset of nvidia hardware :-P Compile checks are simple, regression tests are hard
16:44 karolherbst: RSpliet: I already have a travis.yml to compile test nouveau as a module :p
16:44 karolherbst: Echelon9: kernel module
16:45 karolherbst: whow as this feral person?
16:45 Echelon9: RSpliet: No real hw testing, just compile test and then potentially any IR-level conversion
16:46 Echelon9: karolherbst: interested to see the travis.yml to compile test nouveau as a module!
16:46 karolherbst: I actually wanted to buy the new hitman game when it had the discount, but now it hasn't
16:46 karolherbst: Echelon9: https://github.com/karolherbst/nouveau/commit/d9318d66b5c1a94c62c4efa50fd0b9c56f394b29
16:47 karolherbst: and it generated a 6GB+ cache :D
16:47 karolherbst: for the linux tree
16:47 karolherbst: Echelon9: one run which passed: https://github.com/karolherbst/nouveau/commit/d9318d66b5c1a94c62c4efa50fd0b9c56f394b29
18:40 Echelon9: karolherbst: thanks
18:56 karolherbst: mupuf: I get a few "makssh_dispatch_run_fatal: Connection to port 2222: message authentication code incorrect" too often, any idea why that is?
18:57 karolherbst: ...
19:00 mupuf: never seen this message before :o
19:04 karolherbst: ohh, you didn
19:04 karolherbst: 't replace the fermi gpu
19:18 mupuf: karolherbst: want me to?
19:19 mupuf: what do you want? the cf?
19:19 mupuf: I have a c0 and a c1 too
19:19 mupuf: the c4 does not work on this machine though, oddly-enough
19:19 mupuf: works on my main machine
19:21 karolherbst: mhh
19:21 karolherbst: doesn
19:21 karolherbst: 't really matter as long as it is a different one
19:22 karolherbst: maybe nvc4?
19:22 karolherbst: yeah, the nvc4 would be good
19:36 mupuf: I can't :D
19:37 mupuf: the c4 does not work in reator "S
19:37 mupuf: I will put a c0
19:38 karolherbst: ohhh true
19:38 karolherbst: k
19:40 mupuf: c0 and cf plugged
19:40 karolherbst: thanks
19:58 karolherbst: uhhh
19:58 karolherbst: the c0 doesn't appear as well
20:02 karolherbst: mupuf: the nvcf 3 points in pixmark_piano on 0x3 :D
20:02 karolherbst: 20sec benchmark 1024x640
20:02 mupuf: holy shit :D
20:03 mupuf: I will move the c0 to the other pcie port
20:03 mupuf: and I can plug the c1 on the side
20:03 karolherbst: wait a second
20:03 karolherbst: uiuiui
20:03 karolherbst: 0xf worked
20:04 karolherbst: hum, odd
20:04 karolherbst: 3 points on 0xf
20:05 karolherbst: pstate reporst 950 MHz
20:05 karolherbst: I think something is _terribly_ wrong
20:05 imirkin_: memory is slow perhaps?
20:05 karolherbst: pixmark_piano
20:05 karolherbst: memory has 0 effects
20:05 imirkin_: maybe not 0 ;)
20:05 karolherbst: yes, 0
20:05 karolherbst: it doesn't matter
20:05 imirkin_: i mean, if it's clocked at like 50mhz
20:05 imirkin_: heh
20:05 karolherbst: 0x7 produces 72 points
20:05 imirkin_: it does generate an output image eventually
20:06 karolherbst: 0x3 3 points
20:06 imirkin_: huh. odd.
20:06 karolherbst: and 0xf should be above 72 ;)
20:06 imirkin_: seems like a reasonable assumption
20:06 karolherbst: and it booted at 0x7
20:06 imirkin_: unless it generates annoying memory conditions for the hw
20:06 karolherbst: so memory is 324 MHz
20:06 karolherbst: maybe
20:06 karolherbst: which would make it messy to fix
20:06 imirkin_: very.
20:06 imirkin_: were cstates a thing pre-kepler?
20:07 karolherbst: 0xf has a 2150MHz memory clock
20:07 karolherbst: not really
20:07 karolherbst: some fermi have a handful
20:07 imirkin_: maybe there was a reason for that :)
20:07 karolherbst: mine previous laptop had like ~10 cstates
20:07 karolherbst: *my
20:07 karolherbst: maybe
20:07 karolherbst: okay, something is wrong
20:07 karolherbst: did 0xf -> 0x7 -> 0xf
20:08 karolherbst: and still got 3 points from 0xf
20:08 karolherbst: mupuf: you can switch now, thanks
20:08 imirkin_: yay for consistency!
20:08 karolherbst: :)
20:08 mupuf: karolherbst: this is super odd though
20:08 mupuf: but yeah, I can switch
20:09 karolherbst: well
20:09 karolherbst: it fits what I experienced before
20:09 karolherbst: 0x7 seems to work on all fermis
20:09 karolherbst: but 0xf like on none
20:10 mupuf: here we go, new batch
20:10 mupuf: this time, both are plugged
20:11 karolherbst: awesome, thanks
20:11 RSpliet: Damn... for a second I thought I could have some fun with the DDR3 Fermi in my cupboard tonight
20:11 mupuf: I can try that nvc4 again ;)
20:11 RSpliet: turns out it just has two DP connectors
20:12 RSpliet: Teletubbies don't support DP... can't plug it in :-(
20:12 karolherbst: somebody broke nouveau again :D
20:12 RSpliet: I try on a regular basis...
20:13 karolherbst: why
20:13 karolherbst: that's not nice
20:13 karolherbst: can't even use lspci on reator after nouveau is loaded
20:13 karolherbst: ....
20:14 mupuf: ah ah, indeed
20:14 mupuf: it crashes the machine :D
20:14 mupuf: sorry, will reboot it :D
20:14 karolherbst: ........
20:14 karolherbst: well
20:14 karolherbst: when _I_ did it, the machine didn't crash
20:15 mupuf: the machine is up, I will not interfere this time
20:15 mupuf: sorry
20:16 karolherbst: you could bisect the module then to figure out who did this :p
20:16 mupuf: lol
20:16 mupuf: yep
20:17 karolherbst: I bisected the other issue already
20:18 karolherbst: 26 on 0x3, nice
20:19 karolherbst: RSpliet: mupufs nvc0 is nice for REing memory reclocking
20:19 karolherbst: RSpliet: 0c: core 405 MHz memory 1674 MHz
20:19 karolherbst: and the core clock works
20:20 karolherbst: okay
20:20 karolherbst: mupuf: reclocking works on your nvc0
20:20 karolherbst: 303 points on 0xf
20:21 mupuf: goody!
20:21 karolherbst: yeah
20:21 karolherbst: core clock is 607MHz
20:21 karolherbst: so that's why
20:21 karolherbst: I assume we do something wrong for rather high clocks
20:21 imirkin_: btw, that guy who wanted tbo_rgb32 isn't here anymore, but that's a DX11 feature. not available on DX10 GPUs
20:21 karolherbst: imirkin_: I figured
20:26 karolherbst: \o/ nvidia doesn't crash whiel mmiotracing
20:30 karolherbst: done for today
20:31 karolherbst: I got a trace, this should help
20:31 karolherbst: will redo it tomorrow I guess anyway, cause I think I messed up
20:32 victoroux: hello, i'm having trouble setting up nouveau after removing the nvidia proprietary drivers
20:32 victoroux: i'm not sure what to be looking for journalctl -b | grep nouveau looks fine to me
20:32 imirkin_: victoroux: pastebin dmesg and xorg logs
20:33 victoroux: sure
20:34 victoroux: dmesg: ptpb.pw/6Ws7 and xorg log: ptpb.pw/2AcJ
20:34 imirkin_: second link is empty
20:35 imirkin_: btw, unrelated to your issues, but i recommend updating to 4.10 as that will allow you to (manually for now) change the perf state of your GPU
20:35 victoroux: the log is empty actually, that's weird
20:35 imirkin_: well, not sure how your distro is set up
20:35 imirkin_: i think with systemd craziness it ends up in .local somewhere?
20:36 victoroux: yes, it was filled last time i looked at it
20:36 victoroux: i'm guessing this boot i switched tty early enough that it didn't even try?
20:36 victoroux: idk how it all works actually
20:36 victoroux: here is the one from before: ptpb.pw/htm6
20:37 victoroux: but after that log, i fully removed nvidia, added nouveau to MODULES in mkinitcpio, and created a file in x11/xorg.conf.d for nouveau
20:37 imirkin_: that all looks perfectly happy
20:37 victoroux: ok
20:37 imirkin_: what's the problem exactly?
20:38 victoroux: well if i try startxfce4 it shows the cursor for a short moment, screen turns off because there is no signal, and i'm hard locked (unable to switch ttys)
20:38 imirkin_: can you ssh into the machine and check if there are additional logs as a result?
20:38 victoroux: i'm on the machine right now
20:38 victoroux: which logs?
20:38 imirkin_: dmesg
20:39 imirkin_: i meant when the problem happens
20:39 imirkin_: ssh into it
20:39 imirkin_: and run 'dmesg'
20:39 victoroux: oh interesting, yeah i can try that
20:39 victoroux: i'll brb
20:39 imirkin_: (and grab the xorg log for good measure)
20:40 victoroux: sure thing
20:44 victoroux: @imirkin_: okay, this is what I have now. dmesg: https://ptpb.pw/hsTx and xorg: https://ptpb.pw/ILNl
20:45 imirkin_: victoroux: you have just one 2560x1440 screen connected via DP - correct?
20:45 victoroux: yes
20:46 imirkin_: perhaps nouveau is getting stuck somewhere? check bakctraces on cpu's...
20:46 imirkin_: echo something into sysrq-trigger... if only i remembered what
20:46 imirkin_: echo l > /proc/sysrq-trigger (as root)
20:46 imirkin_: and then grab dmesg again
20:46 victoroux: ok, i was gonna say i have no idea how to do that lol
20:47 victoroux: thank you, one sec
20:47 victoroux: I tried "sudo echo 1 >" but it still says permission denied
20:48 imirkin_: lowercase L
20:48 imirkin_: and sudo won't work
20:48 imirkin_: you have to be root
20:48 victoroux: oh ok, one sec
20:48 imirkin_: since the > happens as your user
20:48 imirkin_: sudo bash is nice :)
20:48 victoroux: oh i didn't know that actually, interesting
20:49 victoroux: new dmesg: https://ptpb.pw/BMP_
20:49 imirkin_: oh heh
20:49 imirkin_: you changed the log-level with your 1 thing
20:49 victoroux: lmao, i'm literally clueless, sorry
20:49 imirkin_: run 'dmesg -n8'
20:50 victoroux: sure
20:50 imirkin_: and then do the echo again
20:50 imirkin_: lowercase L, not a one.
20:50 victoroux: oh gotcha
20:51 victoroux: https://ptpb.pw/KPC7
20:51 imirkin_: ok. that worked. but didn't show the thing i was kinda hoping
20:51 victoroux: bummer
20:51 imirkin_: this shows that all your cpu's are idle (except the one that's actually dumping the backtraces)
20:52 victoroux: so what if core 3 was busy with nouveau?
20:52 victoroux: well if it were stuck, it wouldn't even work i guess
20:53 imirkin_: then it should show me what was stuck
21:07 RSpliet: [ 83.009944] nouveau 0000:01:00.0: gr: DATA_ERROR 00000004 [INVALID_VALUE] ch 7 [003f893000 Xwayland[1378]] subc 0 class 9097 mthd 2704 data 01cad060
21:08 RSpliet: ^ that's on a GF104
21:09 imirkin_: what's 2704?
21:09 RSpliet: I wish that was easy to find out... but given it's wayland I bet it's hidden somewhere in mesa
21:09 imirkin_: huh?
21:09 imirkin_: fine, i'll stop being lazy
21:10 RSpliet: hahaha
21:10 imirkin_: https://github.com/envytools/envytools/blob/master/rnndb/graph/gf100_3d.xml#L1256
21:10 RSpliet: I'd gladly try and be less lazy, but my system is busy building a kernel right now
21:10 imirkin_: ok, so, 2704 is ADDRESS_LOW for image 0.
21:10 imirkin_: this presents some interesting questions
21:10 imirkin_: like
21:11 imirkin_: (a) does wayland use images??? probably not, but i guess it could come via PBO's
21:11 imirkin_: (b) how can it be validating anything?
21:11 imirkin_: i.e. how is that a DATA_ERROR
21:11 imirkin_: hmmmm ... that address seems fishy
21:12 imirkin_: probably it has to be 0x100-aligned
21:12 RSpliet: imirkin_: the first question I had is "what is address_high"
21:12 imirkin_: this could happen with a buffer maybe?
21:12 imirkin_: the upper 8 bits of the 40-bit address
21:12 imirkin_: iirc there's an assert to make sure we don't feed it an address with the low bits set
21:13 imirkin_: and, again iirc, we had a thing fixing things up for weirdly-aligned buffers
21:13 imirkin_: and by "we" i mean hakzsam.
21:14 imirkin_: RSpliet: what's the result of getting that? and how do you achieve it?
21:14 RSpliet: imirkin_: these are all spurious messages in log from something not more specific than "desktop use"
21:15 imirkin_: but no obvious problems as a result?
21:15 RSpliet: apart from the transparency issue I had with pidgin on Kepler as well, nothing obvious
21:16 imirkin_: huh, ok
21:17 RSpliet: https://da.gd/m9IN
21:18 imirkin_: yeah ok. all misaligned.
21:18 imirkin_: but plausible that they're real addresses.
21:18 imirkin_: will have a look... at some point.
21:18 imirkin_: RSpliet: file a bug.
21:19 RSpliet: imirkin_: Will do when I have my kernel. Anything else I can try to get you?
21:19 imirkin_: a patch to fix it would be nice ;)
21:19 imirkin_: also if you can repro, an apitrace would be super
21:19 imirkin_: (using xephyr or something)
21:19 RSpliet: I fear APItraces might fill up my ("error count since last fsck: 1") hard-drive quickly, but I'll give it a try
21:21 hakzsam: imirkin_: I don't remember
21:21 imirkin_: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c#n1019
21:22 imirkin_: i guess someone might have skimped on that little detail :p
21:22 imirkin_: i wonder if we can set texture buffer alignment to 256
21:22 hakzsam: should be aligned?
21:22 imirkin_: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c#n149
21:22 imirkin_: we return 16 for now
21:23 imirkin_: should just make it 256 on pre-kepler and move on with life
21:23 imirkin_: RSpliet: can you test that? (just set it to 256 everywhere for your test)
21:23 RSpliet: imirkin_: in due time I'm sure that shouldn't be too hard to test. I'll let my kernel compile run finish first though
21:24 imirkin_: yeah, no rush
21:24 RSpliet: (while I go out and buy some bogroll... sometimes I forget I'm human)
21:24 imirkin_: if it doesn't help, file a bug. although if it doesn't help, i have no idea what the issue might be.
21:24 imirkin_: bogroll?
21:24 imirkin_: ah
21:24 imirkin_: english expression apparently.
21:24 imirkin_: urban dictionary's got me covered apparently
21:25 imirkin_: nice "use it in a sentence" example there too
22:13 RSpliet: imirkin_: I'm about to do a linus on the gpio-event-mon people for causing my kernel build to break. Might take longer to get you the information you requested
22:20 imirkin_: RSpliet: whenever ;)
22:20 imirkin_: i don't use wayland (or fermi, anymore) so ... meh
22:21 RSpliet: fair enough
22:21 RSpliet: my desktop card isn't Fermi, but I was hoping to get that reclocking code sorted one of these days