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