03:14 mooch2: wtf is gp10b
03:14 mooch2: nvm
11:04 karolherbst: what is the difference between FFMA.FMA and FFMA.FMA2?
11:07 karolherbst: and then there is a plain FFMA as well
11:41 imirkin: karolherbst: never heard of those before
11:43 karolherbst: 0x3200000000000000ull is FFMA.FMA and 0x3400000000000000ull is FFMA.FMA2
11:44 karolherbst: on nvc0
11:44 karolherbst: according to nvdisasm at least
11:45 karolherbst: at least they seem to behave exactly like FFMA and didn't to anything related to that precise bug, but I didn't investigated deeper for now
11:52 mwk: karolherbst: I think they are requested execution units
11:53 mwk: some other instructions have such attrs as well
11:53 mwk: eg. for mov you can choose whether it executes on an ALU or on an SFU
11:53 karolherbst: ahhhhhh
11:54 mwk: and the plain FFMA is likely "meh, choose yourself"
11:54 karolherbst: I guess this is helpful for improving dual issueing
11:54 karolherbst: ohh
11:54 mwk: *shrug*
11:54 karolherbst: okay, I see
11:54 mwk: AFAIK noone ever verified that
11:54 mwk: just my guess
11:55 karolherbst: is there a way to add those FMA/FMA2 things to envydis?
11:55 karolherbst: would be nice to have it there as well
11:55 mwk: sure, go ahead
11:55 mwk: FWIW there are a *lot* of instruction on Fermi+ that have these attributes
11:55 karolherbst: I was rather asking if there is already something like that, but I guess I need to add new tags
11:55 mwk: on Tesla, I think the only one is the mov with sfu
11:55 karolherbst: okay. I see
11:57 karolherbst: isn't there a perf counter to check how much is axecuted on the ALU/SFU?
11:57 karolherbst: we could verify with that
11:59 mwk: likely yes
13:06 karolherbst: imirkin: any ideas? https://gist.github.com/karolherbst/77dbab53c1cbae1b5755a41398dd8713
13:06 karolherbst: despite that bo being 0
13:07 imirkin: karolherbst: yeah, something dumb got stuck in one of the bufctx bins?
13:07 imirkin: (or got put into it)
13:08 karolherbst: and I also hit an assert with my debug build
13:08 karolherbst: ../../../../../src/gallium/drivers/nouveau/codegen/nv50_ir_bb.cpp:219: void nv50_ir::BasicBlock::insertAfter(nv50_ir::Instruction*, nv50_ir::Instruction*): Assertion `q->op != OP_PHI || p->op == OP_PHI' failed.
13:08 imirkin: uhhhhhh
13:08 imirkin: that's REALLY bad
13:08 karolherbst: obviously
13:09 imirkin: hopefully you grabbed the tgsi program?
13:09 karolherbst: it's reproduciable
13:09 imirkin: so then you definitely grabbed the tgsi program? :)
13:09 karolherbst: https://gist.github.com/karolherbst/803dd273f3439033cdf70d5ab10d0a6b
13:10 mooch2: hey mwk
13:10 imirkin: karolherbst: file a bug, i'll look at it later
13:11 karolherbst: maybe I can figure it out as well
13:11 karolherbst: globalCSE, fun
13:22 karolherbst: okay that makes sense
13:22 karolherbst: imirkin: GlobalCSE found a phi depending on another phi
13:22 karolherbst: and now wants to move a phi before a join
13:22 imirkin: ahhh yeah
13:23 imirkin: that won't work :)
13:23 karolherbst: if the source is phi it should skip, right?
13:23 imirkin: maybe. would have to think about it.
13:23 imirkin: (and refresh my memory of precisely what all GlobalCSE does)
13:24 karolherbst: ohh wait, I think it is something else
13:25 karolherbst: no, I was right actually
13:25 karolherbst: join is the entry of the BB GlobalCSE wants to move that phi
13:26 karolherbst: and the phi shoulve be moved after the join
13:34 karolherbst: okay, I think I got a proper fix
13:34 karolherbst: usually insertHead is called, but because entry is join, insertAfter(join) is called instead. I think we don't want to do that for phis in any case
13:35 karolherbst: so we should just call insertHead if a phi gets moved around
13:35 karolherbst: or maybe we don't want to move phis around at all (between BBs)
13:37 mwk: mooch2: hi
13:42 karolherbst: imirkin: this would be the fix I was thinking about: https://github.com/karolherbst/mesa/commit/604d31d799dd2fa3adb5733f4f38f60c6aa2d1cb
13:44 karolherbst: mhhh, on my debug build I don't hit that segfault
13:45 pmoreau: imirkin: Hum… I can’t decide whether the translator to NVIR should be the one handling chars or halfs in 32-bit registers, or whether it should be the NVIR compiler. I’m leaning towards the former, though coalescing loads and stores of chars/halfs would be easier to do if the compiler did it, I think.
13:47 pmoreau: As for 2xhalfs, or 4xint8, within the same reg on Pascal, probably just add a new TYPE_ and update the emit code to handle them properly.
14:32 imirkin_: karolherbst: you can't just move phi nodes willy nilly
14:32 imirkin_: they're not regular ops
14:33 karolherbst: yeah I know, that's why the other way to fix it would be to not do globalCSE for phis
14:33 karolherbst: but we currently do this anyway
14:34 karolherbst: this patch doesn't really change the behaviour of any shader up until now
14:34 imirkin_: doesn't matter. still wrong to be moving phi's around carelessly.
14:35 karolherbst: also the first crash was a result of that assertion getting hit
14:35 karolherbst: memory corruption I assume
14:36 karolherbst: imirkin_: okay, so you would prefer to not move phis around or check what that pass do and think about if moving that phi is fine or not?
14:37 imirkin_: i would prefer to understand what's going on and make a decision based on that.
14:37 imirkin_: however i don't have time this second
14:37 imirkin_: so that's why i suggested you file a bug
14:38 karolherbst: k
14:40 karolherbst: now I hit this "Error in Graph:createEdge: edge already exists"
14:41 imirkin_: if you want to solve it yourself that's fine too, but no explanations that start with "i guess" :)
14:41 karolherbst: :D
14:41 karolherbst: right
14:42 imirkin_: pmoreau: you might be aware, but nvc0+ have "video" ops that allow you to do various "SIMD"-style ops as well on 32-bit registers
14:47 RSpliet: dboyan: in case you nail insn scheduling and get bored before the end of the GSoC, I created a little task on trello for loop unrolling :-
14:47 RSpliet: :-P
14:57 RSpliet: dboyan: but more seriously: I believe loop unrolling is a second example of a GPR-constraint optimisation (like insn scheduling). It'd be nice if you could have a little brainstorm about how GPR(/liveness) analysis can be efficiently generalised such that multiple optimisations can request and use this data
14:57 imirkin_: RSpliet: you're jumping 20 steps ahead
14:57 imirkin_: RSpliet: the first step is to have SOMETHING. then it can be improved.
14:58 RSpliet: imirkin_: the *something* is the liveness analysis used by RA, no?
14:58 imirkin_: RSpliet: insn scheduling? there is none right now.
14:59 RSpliet: I have been aware of that, thank you
15:02 RSpliet: LVA though, we have that. All I'm saying is that I suspect this has to be re-used for more than just insn scheduling, so if he makes adjustments to it it's good to keep the analysis' general nature in mind
15:03 RSpliet: the "go and implement loop unrolling" was obviously not serious, the task is big enough as-is
15:58 technohacker: Hello, I wanted to know, is snd_hda_intel is in charge of HDMI audio or nouveau? (NVC0, GeForce GT 525M)
16:11 RSpliet: technohacker: I think the answer you're looking for is "yes"
16:11 technohacker: RSpliet: So snd_hda_intel manages HDMI audio, right?
16:15 RSpliet: technohacker: it's a "HDA" device managed by that driver, but nouveau takes care of routing the audio over HDMI
16:15 technohacker: RSpliet: Aah kay, thanks for the clarification.
16:16 RSpliet: (or something along those lines at least. The bottom line is you need both, but it's interface is like a standard audio device like most these days :-))
16:17 technohacker: RSpliet: Kay, thanks :)
21:18 tobijk: imirkin: should i be worried? https://hastebin.com/ovozujayid.go
21:22 imirkin_: not my area of expertise
21:22 tobijk: so whos area whould it be? i dont want to list random names here :/
21:23 imirkin_: skeggsb
21:23 tobijk: waking one is enough already :-)
21:33 RSpliet: tobijk: don't filter logs when posting. There's useful information in every message
21:35 tobijk: RSpliet: what do you mean? there is nothing expect the usual in front (normal probing of the card)
21:35 tobijk: oh no i'm wrong *dang*
21:36 tobijk: https://hastebin.com/osoxozehip.go more locking errors :>
21:36 RSpliet: even normal probing is useful... saves people from asking trivial questions like "which card" and "did you boot with special params"
21:37 RSpliet: and there is that
21:37 imirkin_: oh, the thing where i915 and nouveau trip all over each other
21:37 imirkin_: yes, that's a thing.
21:37 imirkin_: no clue what the status of that is or who has investigated it, if anyone
21:37 tobijk: well you would be right, but the rest is not in dmesg buffer anymore, just in my open console (not even the probe is in the console output)
21:38 tobijk: imirkin_: well it does work despite those locking errors
22:35 karolherbst: tobijk: best to disable dri2 completly
22:35 karolherbst: and configure the dummy X driver for the nvidia gpu
22:36 karolherbst: except you are unlucky and need reverse prime
22:37 tobijk: karolherbst: i'm unlucky (have to drive my external monitor)
22:37 karolherbst: :(
22:38 tobijk: luckyly the system does work anyway
22:38 karolherbst: wait until X decides to not work anymore
22:38 tobijk: 9h15min and going strong ;-()
22:39 karolherbst: try to lock the screen
22:39 tobijk: with those locking shit at the begining
22:39 tobijk: ok (see you later i presume)
22:39 tobijk: mh works fine
22:40 karolherbst: mhhh, yeah, maybe there are other ways. I just know that invoking the screen locker is a candidate for messing things up
22:40 karolherbst: especially when running under systemd
22:41 tobijk: oh well i run systemd but not logind or how its named
22:42 karolherbst: odd
22:42 karolherbst: how can you not run logind?
22:42 tobijk: or better it is not used
22:42 tobijk: as far is i know
22:42 karolherbst: no session management at all then?
22:42 tobijk: does sddm count? i guess not
22:43 karolherbst: uhm, yes?
22:43 tobijk: ok then sddm
22:43 karolherbst: "loginctl list-sessions"
22:43 tobijk: mhm it actually uses logind, interesting
22:44 karolherbst: yeah, because logind invokes the screen locker
22:45 karolherbst: "loginctl lock-session $session_name" locks your screen
22:45 tobijk: ah starting a new session did the trick
22:46 tobijk: successful hang :)
22:46 karolherbst: :)
22:46 karolherbst: "loginctl lock-session $session_name" locks your screen
22:47 karolherbst: for example
22:47 karolherbst: but it can do tons of more things as well
22:47 karolherbst: I think in theory it can even detach devices from sessions
22:50 tobijk: mh i would have expected another kernel oops at least, but there is nothing in the logs, yet the system unmounted the and reached target shutdown
22:55 karolherbst: well, deadlock