00:00Kevlar_Noir: it's more the 10% of oc
00:00Kevlar_Noir: no I will not try that
00:02Kevlar_Noir: it has a range of frequencies
00:03Kevlar_Noir: but I don't know if it will hit the 1241mhz
00:03imirkin_: one way to find out...
00:03Kevlar_Noir: or the minus value
00:07Kevlar_Noir: imirkin_, ok I'm going to try
00:08Kevlar_Noir: ok !!!
00:08Kevlar_Noir: I'm @ 1012mhz
00:12imirkin_: like i said, just coz a cstate is there, doesn't mean it'll get used
00:12imirkin_: some require impossible voltage settings, other times they're only available with frequency boosting
00:14Kevlar_Noir: it's fine.. now I'm searching for the kernel parameter.
00:16Kevlar_Noir: super, cool
00:16Kevlar_Noir: thank you
03:39mwk: so... address-related ops now, I guess
03:53imirkin: mwk: you probably noticed this, but /* TODO: figure out where this table came from some day. */ -- each row is 2N +/- 1
04:04mwk: imirkin: that's rather obvious, yes
04:04mwk: now try to figure out when it's -1 and when it's +1
04:04imirkin: yeah, i didn't see a great pattern
04:04mwk: I think they use yet another creative Booth multiplier variant
04:05mwk: and by "creative" I mean "having loose connection to arithmetical accuracy"
04:06mwk: I managed to RE such a thing for the main SF evaluator, have a look at xf_sf_mul
04:07mwk: but when trying to apply similar logic to the reduction multiply, I'm one bit off (in the best case, there are several possible shifts etc
04:07mwk: and since there is exactly one data point, I don't really have much to work on
04:09mwk: imirkin: FWIW, for a constant c, xf_sf_mul can be described by a similar multiplication table to the one with the TODO
04:09mwk: with a rather complex rule to decide where the +1s are
04:10mwk: ie. for even entries, take bits 14-i:14-i-3 of the multiplier constant, and apply +1 if these 3 bits are equal to 1, 2, 3, or 7
04:11mwk: for odd entries, take bits 14-i-1:14-i-4, and apply +1 if equal to 3, 5, 6, 7
04:11mwk: or something like that
04:11mwk: getting from *that* to the recovered Booth multiplication logic took me some time and lots of samples
04:13mwk: so I'm going to guess simplifying this table is going to be impossible unless you just happen to smoke the exact same blend of substances as the designed
04:14mwk: anyway, boarding a plane, see you later
04:15imirkin: see ya
07:45ClaudiusMaximus: my syslog was flooded with nouveau messages, as i have discovered after having had to hard-power-down my laptop after an Xorg lockup
07:45ClaudiusMaximus: May 30 08:11:53 latte kernel: [23511.558126] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
07:45ClaudiusMaximus: May 30 08:11:53 latte kernel: [23511.558129] nouveau 0000:01:00.0: swiotlb: coherent allocation failed, size=2097152
07:48ClaudiusMaximus: https://mathr.co.uk/tmp/nouveau/swiotlb.txt the full error, this is repeated many times with minor variations in the register contents
07:49ClaudiusMaximus: $ sudo cat /var/log/syslog | grep "swiotlb buffer is full" | wc -l
09:16ClaudiusMaximus: (crossposted form ##opengl) if i enable multisampling for the default framebuffer and glReadPixels from it, what is supposed to happen? I'm getting "one corner of the image stretched" when i expected "what i see on my screen"
09:17ClaudiusMaximus: i'm pretty sure with the nvidia evilblob on my old desktop (gtx550ti) it worked as i expected, now testing with nouveau on my laptop (G98M [GeForce G 105M])
09:56sigod: hi, what's up?
11:39ClaudiusMaximus: i solved my opengl issue by using a multisampled fbo, instead of the default framebuffer with which apparently an "implicit msaa resolve" is supposed to take place with glReadPixels
11:40kherbst: ohh yeah, nouveau doesn't do that
11:41kherbst: or not correctly or whatever
11:41kherbst: there are some piglit fails for that afaik
11:43ClaudiusMaximus: with msaa on default framebuffer, glreadpixels gave me a stretched version of a corner of the framebuffer, seemingly not resolving it - with msaa in the fbo and blitting before readpixels it worked fine
11:45kherbst: yeah, as I said, nouveau doesn't do that correctly :)
11:45ClaudiusMaximus: ok :)
11:45kherbst: imirkin: that GTX 660 I have is super nice to trigger that context switching bug. All it takes is like 2-3 glxspheres
11:45kherbst: and things start to go wrong quite fast
11:46kherbst: I am running a plasma session though...
11:48ClaudiusMaximus: https://mathr.co.uk/tmp/nouveau/swiotlb.txt any ideas on this? guessing wildly, gpu memory fragmentation?
12:23gdepoire: hello, my system freezes when I start the Minecraft game with nouveau drivers: https://pastebin.com/raw/5Kj91Ru2 uname: "4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux", I have a GTX 1060
12:23gdepoire: can anyone help me?
12:27kherbst: uhh nice, reclocking doesn't work on that 660 as well... what a card
12:29kherbst: gdepoire: I think this might be due to some multithreading issues
12:29kherbst: fixing that is hard
12:29kherbst: might be something else though
12:29kherbst: gdepoire: is this kind of deterministic or does it happen randomly?
12:29kherbst: with randomly I mean the time after starting
12:32gdepoire: kherbst: it doesn't always freeze the system but when it does, I think it's always a certain point when the game is loading
12:33kherbst: allthough I don't think plain minecraft does multithreaded GL
12:33kherbst: ohh wait, it was added in 1.8 or something
12:35kherbst: gdepoire: is there an easy way for you to run minecraft older than 1.8?
12:35kherbst: just for testing?
12:36kherbst: maybe there is an option to disable it all along...
12:36kherbst: maybe hidden
12:36kherbst: I don't know
12:36pendingchaos: IIRC 1.12 or something seemed to work fine for me
12:38kherbst: gdepoire: are you using optifine or something? is this still a thing?
12:38pendingchaos: though maybe I was just lucky
12:38imirkin: ClaudiusMaximus: hm, that should be fixed in 4.16.x. don't remember the x though.
12:39kherbst: I could imagine that vanilla minecraft kind of runs fine, but ....
12:39gdepoire: im using Optifine with forge 1.8.9, I will try 1.7.10
12:39kherbst: gdepoire: try setting optifine to not use multithreading
12:39kherbst: and see if this works
12:39pendingchaos: "To fix it go to the graphics card control panel and set "Threaded Optimization" or "OpenGL Threading" to OFF"
12:41pendingchaos: looking closer, it's a sort of driver-specific threading
12:41kherbst: pendingchaos: yeah
12:41kherbst: but there should be an option for optifine as well I think...
12:42kherbst: but it is fun to see there are quite a lot of users still only playing <minecraft-1.9
12:44gdepoire: i don't see any multithreading option in optifine
12:44gdepoire: I set chunk-loading to default instead of multi-core and disable fast render but the bug still happens
12:45gdepoire: now instead of freezing my system it crashed the jvm with SIGSEGV
12:45gdepoire: also, the bug happens at "reloading - modelmanager" when starting minecraft with forge
12:45kherbst: that's easier to debug
12:46karolherbst: but mhh
12:46karolherbst: gdepoire: do you know if that happens on a plain install?
12:47karolherbst: might be worth to open a bug report with that segfault and which package to download/install
12:47gdepoire: I can't reproduce it without forge
12:47karolherbst: okay, right. But is there like a package someone can download?
12:48karolherbst: it is easier for us to fix if we know what we have to do to reproduce that
12:48gdepoire: no but I can try to make an archive with the files you need if you want
12:49karolherbst: yeah, that might help
12:50karolherbst: imirkin: did we have some mayor fix regarding multithreading inside mesa 18.0 or something?
12:51imirkin: no clue
12:51imirkin: but unlikely
12:51karolherbst: mhh, I just updated that machine from fedora 27 to 28 and now it doesn't freeze anymore...
12:53karolherbst: or maybe...
12:53karolherbst: I mean I reclocked now
12:53karolherbst: maybe the default state is unstable...
12:58pendingchaos: this looks interesting: https://github.com/MinecraftForge/MinecraftForge/commit/7da6c2d0e1b0056e520990d78f63a9be8d0db5ed
12:59karolherbst: fun how they are patching minecraft these days
13:01karolherbst: imirkin: reclocking really fixes it...
13:01karolherbst: the voltage is even the same
13:01karolherbst: okay, more or less it fixes it
13:15karolherbst: imirkin: ever saw an issue like that? https://drive.google.com/file/d/1wiYlu3XO38begDP7T_l475DXHLUnDxKG/view
13:15imirkin: not sure. could be high fps? dunno.
13:15karolherbst: both at 60
13:16imirkin: yeah, i got nothing
13:16karolherbst: maybe that can also be caused by broken context switching firmware?
13:16karolherbst: it sometimes looks like each window tries to render a frame from the other one
13:17karolherbst: but could also be the compositor messing up
13:18karolherbst: dmesg isnt helpful either
13:19karolherbst: anyway, now they just frooze and I got this: https://gist.githubusercontent.com/karolherbst/58433cb60b31572a09bd9223da2d5a16/raw/0abada837497a1a3fbb124554f5bf43fe50d0f59/gistfile1.txt
13:19karolherbst: I suspect context switching on that card, but...
13:21karolherbst: or maybe just threading issues regarding push buffers...
13:23karolherbst: imirkin: what do you think about adding a checksum to pushbuffers for debugging purposes?
13:24karolherbst: allthough that kind of still leaves us with the problem that we don't know when and where something can be messed up
13:48gdepoire: the Minecraft EULA says that I can't redistribute any game files, so how could I make a package to reproduce the bug?
13:53karolherbst: gdepoire: either send it privately or give instructions on how to recreate such a package
14:40gdepoire: also I forgot to say that when my system boots, I get this: "nouveau 0000:01:00.0: gr: intr 00000040" in dmesg
14:54gdepoire: if anyone wants an archive to reproduce the bug, send me a PM and I will give you a link to download, because I'm not allowed to redistribute Minecraft files