00:05tobijk: imirkin: according to the gm107 backend your patches for signed modulo are not legal: nouveau_compiler: codegen/nv50_ir_emit_gm107.cpp:227: void nv50_ir::CodeEmitterGM107::emitField(uint32_t*, int, int, uint32_t): Assertion `(v & ~m) == ~m' failed.
00:12tobijk: imirkin: yet when ignoring the assert and commenting it to see where it goes, we are actually able to compile that special shader (its way bigger in comparison to shader i get with a hack patch to make it compile)
00:39imirkin: tobijk: sounds like an emission bug. can you show me the TGSI that causes that so i can reproduce locally with nouveau_compiler?
00:39imirkin: at least i'm pretty sure that i didn't do anything illegal
00:45tobijk: imirkin: plase note, that is the buggy shader with the false 0x0s instead of the right hex values we had a talk about yesterday: https://hastebin.com/roxaguliyo.md
00:47imirkin: as long as nouveau_compiler crashes, i'm happy :)
00:47imirkin: [sort of]
00:48imirkin: it crashes for nvf0 too
00:49tobijk: same assert i hope?
00:49imirkin: i must be messing up the flags -> predicate thing
00:49imirkin: diff crash for maxwell, but i suspect same idea
00:50imirkin: i'll investigate. thanks.
00:50tobijk: oh right, other backend
00:57Fervi: I probably find some kind of bug (or not - maybe feature).
00:57Fervi: I need to chmod 660 for /dev/tty* for sway (probably on X it also works)
00:57Fervi: All works perfectly, sway running
00:57Fervi: But if I pressed CTRL + ALT + F1 - Linux go to console and screen freezing
01:22imirkin: tobijk: it's odd i didn't see this assert when i was testing though
01:22imirkin: i wonder if this is a nouveau_compiler issue
01:27imirkin: er no. i'm just an idiot.
01:27imirkin: i must have "fixed" it for nv50, and then forgotten to retest on nvc0
01:28tobijk: so you just removed the assert? *kidding*
01:28tobijk: so the nv50 backend has a fix for allowing that kind of behavior?
01:29imirkin: tobijk: https://hastebin.com/yodejikeqi.hs
01:29imirkin: but i'm hitting another assert now
01:30imirkin: in SHLADD
01:30imirkin: 372: shladd ftz f32 $r2 $r14 1.000000 neg $r15 (8)
01:31tobijk: shradd then ;-)
02:07imirkin: no - it's float
02:07imirkin: something merged something it shouldn't have
02:10imirkin: oh lol
02:11imirkin: it's my isPow2() change
02:11imirkin: i guess i have to audiot all the isPow2 usage
02:12tobijk: imirkin: oh which assert did you hit in shladd? we should add it to the gm107 backend as well
02:12tobijk: i can compile the thingy just fine and there is: 374: shladd ftz f32 $r2 $r10 1.000000 neg $r11 (8)
02:12imirkin: nouveau_compiler: codegen/nv50_ir_emit_gk110.cpp:802: void nv50_ir::CodeEmitterGK110::emitSHLADD(const nv50_ir::Instruction*): Assertion `!(imm->reg.data.u32 & 0xffffffe0)' failed.
02:12imirkin: this is my current fixup: https://hastebin.com/pufaqowede.php
02:13imirkin: yeah, builds fine now
02:17tobijk: iscadd vs shladd on maxwell vs kepler, not sure if the assert would be appropriate
02:24tobijk: imirkin: the patch looks better now, but instead of fixing that shladd line, maybe go back to just allowing special cases for isPow2
02:24tobijk: int/uint to be precise
02:25tobijk: as it was done before your patch
02:28tobijk: going to bed now, feel free to send a v2 if you want me to test it further...
02:42imirkin: ISCADD == SHLADD
02:43imirkin: the type on the immediate is fairly meaningless unfortunately
02:43imirkin: i don't have time or desire to fix it up globally
02:43imirkin: but basically it's just a n-bit value and that's that
02:43imirkin: the consuming instruction defines the type
14:14tarragon: ppsspp 1.4.2 didn't hard lock nouveau with a game. But still crashes with darn same game! How can I explore this further?
14:16orbea: tarragon: gdb
14:17tarragon: orbea: do you know how to use perf+nouveau+Xorg??
14:17orbea: as a user, more or les....
14:18orbea: but if you want to debug a crash, you should use gdb...
14:18orbea: it may not be a nouveau issue, gdb will help determine that
14:18orbea: last time I saw ppsspp crash was because of an incompatible ffmpeg version
14:22tarragon: orbea: I am using in built, is the same game same stage accross multilpe kernel/mesa upgrades
14:22tarragon: my patience running out
14:23orbea: idk what to say, without a backtrace we aren't getting anywhere :)
14:29tarragon: backtrace ? I don't understand
14:31tarragon: oh yeah, sorry I a getting chats mixed up.
19:56rgentz: hi; i got a problem with my debian system, in particular the video card.
19:56rgentz: nouveau 0000:02:00.0: DRM: evicting buffers...
19:56rgentz: Nov 12 11:49:38 RainerDebian kernel: [ 1226.985955] nouveau 0000:02:00.0: DRM: waiting for kernel channels to go idle...
19:56rgentz: Nov 12 11:49:38 RainerDebian kernel: [ 1226.985995] nouveau 0000:02:00.0: DRM: suspending client object trees...
19:56rgentz: Nov 12 11:49:38 RainerDebian kernel: [ 1226.990069] nouveau 0000:02:00.0: DRM: suspending kernel object tree...
19:56rgentz: Nov 12 11:49:40 RainerDebian kernel: [ 1228.539933] thinkpad_acpi: EC reports that Thermal Table has changed
19:58pmoreau: Did he try to paste a good chunk of dmesg in chat?
19:58tobijk: an oops or something like that :)
20:00pmoreau: I was looking at what he posted, and thought: “what’s the issue there?”. Wanted to ask him, then saw he got kicked for spam. :s
20:00tobijk: same thing here...maybe he is coming back
20:01pmoreau: Maybe. I’m intrigued as to what the issue was. :-D
20:01tobijk: pmoreau: there were some problems suspending with 4.10 and below and as he is using debian, thats likely it
20:01tobijk: and fixed with newer kernel
20:02pmoreau: Ah, OK. :-)
21:21tobijk: pmoreau: what di you do to the poor nv-report.py in shader-db? :D
21:21pmoreau: Hum, added support for shared to it, plus fix one or two bugs. Why?
21:22tobijk: broken for me now
21:22pmoreau: What’s wrong with it? “broken” isn’t too descriptive :-p
21:23tobijk: pmoreau: https://hastebin.com/xugodedixa.sql
21:23tobijk: that is python 3 urgh
21:24tobijk: python2: https://hastebin.com/yidorikose.sql
21:24tobijk: broken as well :/
21:25pmoreau: Could you link to the before and after please?
21:26tobijk: oh wait, i believe i know the problem, let me check
21:26pmoreau: I guess the before doesn’t have shared, but the after has, so the keys defer?
21:27tobijk: pmoreau: no, both have shared ones, i created them a few minutes ago
21:28pmoreau: Hum :-/
21:28tobijk: before/after coming up
21:28tobijk: "Document exceeds maximum lenght" ~_~
21:30tobijk: https://homepages.thm.de/~tjkl80/nouveau1.txt https://homepages.thm.de/~tjkl80/nouveau2.txt
21:30tobijk: pmoreau: -^
21:32pmoreau: tobijk: FWIW, it also crashes without my patches ;-)
21:36tobijk: pmoreau: well, i forgot to pull before and hacked up my own "shared" patch, that one works: https://hastebin.com/ewesasogav.py
21:36tobijk: but does not include your goodies ofc
21:36pmoreau: tobijk: “nvidia_shaderdb/Civilization VI/1501528914/90.shader_test - type: 0, local: 336, shared: 0, gpr: 29, inst: 389, bytes: 4152” does not have an equivalent; the before has 31,466 entries, the after has 31,467 entries
21:36tobijk: pmoreau: yeah there is one newly compilable shader
21:37tobijk: thats the thing i checked before
21:37tobijk: but it wwas not the problem
21:38tobijk: or did i remove the wrong entry? mhm
21:39imirkin: i have local fixes for that
21:39imirkin: (the list being different between two runs)
21:39imirkin: i never pushed them =/
21:39pmoreau: Well, that is what is causing the assert to fail, cause the two sets have different size
21:39pmoreau: Ah :-/
21:40tobijk: pmoreau: yep its the new entry
21:41pmoreau: So, if I had add an empty entry in before to match the new one in after, then it works, even after my patches :-)
21:41tobijk: yep :)
21:42pmoreau: Not my fault then O:-)
21:42imirkin: let me see if i can clean up my local patches
21:42imirkin: hold on
21:45pmoreau: Oh, I was seeing blue, I thought it was still tobijk looking for his patch :-D
21:45pmoreau: You both have the same colour in my IRC client
21:46tobijk: yeah that is always confusing
21:46imirkin: i guess it varies by client, but everyone who's not me is blue in my client
21:46tobijk: luckily most guys active here have different colors for me
21:46imirkin: double-check that my update fixes the thing for you
21:47imirkin: but it should. i ran into it last time i fixed compilation for something
21:47tobijk: imirkin: yep
21:47tobijk: it does fix it
21:47pmoreau: Yep, it fixes it
21:47imirkin: and you should get a note about the fact that one side is missing that shader
21:48tobijk: oh, now put a blank line in there and i'm happy :)
21:48imirkin: i have this additional patch locally: https://hastebin.com/rofaxopoxa.pl
21:48imirkin: which prints which shaders were helped/hurt and how much
21:49imirkin: [as well as showing bytes changed for when i was doing nv50-focused things where these things matter]
21:49tobijk: imirkin: that'd be useful, i always look at the files
21:49imirkin: [since it's not 1:1 with instructions]
21:50imirkin: tobijk: btw, is that run with my 2/2 patch as well?
21:51tobijk: imirkin: oh actually with your latest, you broke the script for python3 :D
21:51tobijk: imirkin: yep with both patches applied
21:51imirkin: it never worked with python3
21:51imirkin: i don't recognize python3 as a thing, so it's ok
21:51tobijk: i thought so
21:51imirkin: it says "python", which means python 2
21:52imirkin: it'd be like running gcc and getting a c++ compiler.
21:53imirkin: [and it already doesn't work with python3 - i use print as a keyword, not as a function]
21:53tobijk: imirkin: i'm with you, the // for integer divisions you had a talk about a few days ago was enough for me to evade python3 as long as i can
21:54imirkin: it's funny coz i'd be a lot less hostile towards it if people weren't trying to replace "python" with py3.
21:54imirkin: o well.
21:55tobijk: create jobs he said, create python3...
21:55tobijk: ok now i'm tripping people on their toes
22:03imirkin: tobijk: btw, do you actually have civ6, or were you just using shader-db?
22:17tobijk: imirkin: i actually have it, so yeah i ran it with your patch
22:18imirkin: and presumably it works :)
22:18imirkin: or was that other shader never hit?
22:18tobijk: imirkin: it is hit pretty early on (i think the main menu)
22:19tobijk: imirkin: but we have flickering everywhere, but that is not your patch, its another problem
22:20tobijk: likely the maxwell backend
22:20imirkin: oh yeah, that happens
22:20imirkin: valley has weird geometry
22:20imirkin: i never tracked it down. does MESA_DEBUG=flush "fix" it for you?
22:21tobijk: imirkin: it did for valley, havent checked with civ6
22:21tobijk: but let me check...
22:21imirkin: yeah, i know it does for valley
22:21imirkin: which just means we're not flushign something hard enough
22:22tobijk: actually i traced it to one specific GL cal ltype, but i forgot about it
22:22imirkin: glDrawArrays() ? :)
22:23tobijk: RangedArrays imho
22:23tobijk: nevermind that was only the func
22:24imirkin: either way
22:24imirkin: that's just like one of a few ways to invoke a draw function
22:24imirkin: everything else just alters state
22:24imirkin: the draw is what "executes"
22:24imirkin: it's not going to be specific to the draw variant, in all likelihood
22:24imirkin: but rather an interaction with previous state
22:25tobijk: sadly i could never find a small app triggering that
22:38tobijk: imirkin: no civ6 does not render right even with MESA_DEBUG=flush
22:39tobijk: could be the hex values lost in the glsl -> tgsi
22:40tobijk: can't check with my old kepler system anymore, its gone for a while
22:41imirkin: they're not lost
22:41imirkin: they're only lost when *printing* the tgsi
22:42tobijk: imirkin: ah ok, so i got you wrong then
22:42tobijk: yet fixing that is still worth it
22:42imirkin: because the thing formats the floats in a way that you lose that info
22:42tobijk: imirkin: would you take such kind: https://hastebin.com/jevimolufe.cpp
22:42imirkin: there's an env var you can set to have it print floats or something
22:42tobijk: i found it pretty handsome for diffs
22:44imirkin: sure, sounds reasonable. as long as you default it to true.
22:44imirkin: also i'd get rid of the default values for args
22:44imirkin: i don't think you ever use their default-ness, and it just causes confusion otherwise
22:46tobijk_: random system hang, always nice :/
22:47tobijk_: imirkin: ok defaults are going away as well :)
22:48imirkin: and make sure it gets set to true in the "main" flow
22:48imirkin: in some init function or ... whereever
22:48tobijk_: if prog->print() is empty it is initialzed to true, so print
22:49imirkin: yeah, but every part calls it with info.do_the_thing
22:49tobijk_: yeah ok, i will double check
22:53imirkin: and nothing ever sets that to true