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