03:14mooch2: wtf is gp10b
11:04karolherbst: what is the difference between FFMA.FMA and FFMA.FMA2?
11:07karolherbst: and then there is a plain FFMA as well
11:41imirkin: karolherbst: never heard of those before
11:43karolherbst: 0x3200000000000000ull is FFMA.FMA and 0x3400000000000000ull is FFMA.FMA2
11:44karolherbst: on nvc0
11:44karolherbst: according to nvdisasm at least
11:45karolherbst: 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:52mwk: karolherbst: I think they are requested execution units
11:53mwk: some other instructions have such attrs as well
11:53mwk: eg. for mov you can choose whether it executes on an ALU or on an SFU
11:54mwk: and the plain FFMA is likely "meh, choose yourself"
11:54karolherbst: I guess this is helpful for improving dual issueing
11:54karolherbst: okay, I see
11:54mwk: AFAIK noone ever verified that
11:54mwk: just my guess
11:55karolherbst: is there a way to add those FMA/FMA2 things to envydis?
11:55karolherbst: would be nice to have it there as well
11:55mwk: sure, go ahead
11:55mwk: FWIW there are a *lot* of instruction on Fermi+ that have these attributes
11:55karolherbst: I was rather asking if there is already something like that, but I guess I need to add new tags
11:55mwk: on Tesla, I think the only one is the mov with sfu
11:55karolherbst: okay. I see
11:57karolherbst: isn't there a perf counter to check how much is axecuted on the ALU/SFU?
11:57karolherbst: we could verify with that
11:59mwk: likely yes
13:06karolherbst: imirkin: any ideas? https://gist.github.com/karolherbst/77dbab53c1cbae1b5755a41398dd8713
13:06karolherbst: despite that bo being 0
13:07imirkin: karolherbst: yeah, something dumb got stuck in one of the bufctx bins?
13:07imirkin: (or got put into it)
13:08karolherbst: and I also hit an assert with my debug build
13:08karolherbst: ../../../../../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:08imirkin: that's REALLY bad
13:09imirkin: hopefully you grabbed the tgsi program?
13:09karolherbst: it's reproduciable
13:09imirkin: so then you definitely grabbed the tgsi program? :)
13:10mooch2: hey mwk
13:10imirkin: karolherbst: file a bug, i'll look at it later
13:11karolherbst: maybe I can figure it out as well
13:11karolherbst: globalCSE, fun
13:22karolherbst: okay that makes sense
13:22karolherbst: imirkin: GlobalCSE found a phi depending on another phi
13:22karolherbst: and now wants to move a phi before a join
13:22imirkin: ahhh yeah
13:23imirkin: that won't work :)
13:23karolherbst: if the source is phi it should skip, right?
13:23imirkin: maybe. would have to think about it.
13:23imirkin: (and refresh my memory of precisely what all GlobalCSE does)
13:24karolherbst: ohh wait, I think it is something else
13:25karolherbst: no, I was right actually
13:25karolherbst: join is the entry of the BB GlobalCSE wants to move that phi
13:26karolherbst: and the phi shoulve be moved after the join
13:34karolherbst: okay, I think I got a proper fix
13:34karolherbst: 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:35karolherbst: so we should just call insertHead if a phi gets moved around
13:35karolherbst: or maybe we don't want to move phis around at all (between BBs)
13:37mwk: mooch2: hi
13:42karolherbst: imirkin: this would be the fix I was thinking about: https://github.com/karolherbst/mesa/commit/604d31d799dd2fa3adb5733f4f38f60c6aa2d1cb
13:44karolherbst: mhhh, on my debug build I don't hit that segfault
13:45pmoreau: 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:47pmoreau: 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:32imirkin_: karolherbst: you can't just move phi nodes willy nilly
14:32imirkin_: they're not regular ops
14:33karolherbst: yeah I know, that's why the other way to fix it would be to not do globalCSE for phis
14:33karolherbst: but we currently do this anyway
14:34karolherbst: this patch doesn't really change the behaviour of any shader up until now
14:34imirkin_: doesn't matter. still wrong to be moving phi's around carelessly.
14:35karolherbst: also the first crash was a result of that assertion getting hit
14:35karolherbst: memory corruption I assume
14:36karolherbst: 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:37imirkin_: i would prefer to understand what's going on and make a decision based on that.
14:37imirkin_: however i don't have time this second
14:37imirkin_: so that's why i suggested you file a bug
14:40karolherbst: now I hit this "Error in Graph:createEdge: edge already exists"
14:41imirkin_: if you want to solve it yourself that's fine too, but no explanations that start with "i guess" :)
14:42imirkin_: 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:47RSpliet: 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:57RSpliet: 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:57imirkin_: RSpliet: you're jumping 20 steps ahead
14:57imirkin_: RSpliet: the first step is to have SOMETHING. then it can be improved.
14:58RSpliet: imirkin_: the *something* is the liveness analysis used by RA, no?
14:58imirkin_: RSpliet: insn scheduling? there is none right now.
14:59RSpliet: I have been aware of that, thank you
15:02RSpliet: 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:03RSpliet: the "go and implement loop unrolling" was obviously not serious, the task is big enough as-is
15:58technohacker: Hello, I wanted to know, is snd_hda_intel is in charge of HDMI audio or nouveau? (NVC0, GeForce GT 525M)
16:11RSpliet: technohacker: I think the answer you're looking for is "yes"
16:11technohacker: RSpliet: So snd_hda_intel manages HDMI audio, right?
16:15RSpliet: technohacker: it's a "HDA" device managed by that driver, but nouveau takes care of routing the audio over HDMI
16:15technohacker: RSpliet: Aah kay, thanks for the clarification.
16:16RSpliet: (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:17technohacker: RSpliet: Kay, thanks :)
21:18tobijk: imirkin: should i be worried? https://hastebin.com/ovozujayid.go
21:22imirkin_: not my area of expertise
21:22tobijk: so whos area whould it be? i dont want to list random names here :/
21:23tobijk: waking one is enough already :-)
21:33RSpliet: tobijk: don't filter logs when posting. There's useful information in every message
21:35tobijk: RSpliet: what do you mean? there is nothing expect the usual in front (normal probing of the card)
21:35tobijk: oh no i'm wrong *dang*
21:36tobijk: https://hastebin.com/osoxozehip.go more locking errors :>
21:36RSpliet: even normal probing is useful... saves people from asking trivial questions like "which card" and "did you boot with special params"
21:37RSpliet: and there is that
21:37imirkin_: oh, the thing where i915 and nouveau trip all over each other
21:37imirkin_: yes, that's a thing.
21:37imirkin_: no clue what the status of that is or who has investigated it, if anyone
21:37tobijk: 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:38tobijk: imirkin_: well it does work despite those locking errors
22:35karolherbst: tobijk: best to disable dri2 completly
22:35karolherbst: and configure the dummy X driver for the nvidia gpu
22:36karolherbst: except you are unlucky and need reverse prime
22:37tobijk: karolherbst: i'm unlucky (have to drive my external monitor)
22:38tobijk: luckyly the system does work anyway
22:38karolherbst: wait until X decides to not work anymore
22:38tobijk: 9h15min and going strong ;-()
22:39karolherbst: try to lock the screen
22:39tobijk: with those locking shit at the begining
22:39tobijk: ok (see you later i presume)
22:39tobijk: mh works fine
22:40karolherbst: mhhh, yeah, maybe there are other ways. I just know that invoking the screen locker is a candidate for messing things up
22:40karolherbst: especially when running under systemd
22:41tobijk: oh well i run systemd but not logind or how its named
22:42karolherbst: how can you not run logind?
22:42tobijk: or better it is not used
22:42tobijk: as far is i know
22:42karolherbst: no session management at all then?
22:42tobijk: does sddm count? i guess not
22:43karolherbst: uhm, yes?
22:43tobijk: ok then sddm
22:43karolherbst: "loginctl list-sessions"
22:43tobijk: mhm it actually uses logind, interesting
22:44karolherbst: yeah, because logind invokes the screen locker
22:45karolherbst: "loginctl lock-session $session_name" locks your screen
22:45tobijk: ah starting a new session did the trick
22:46tobijk: successful hang :)
22:46karolherbst: "loginctl lock-session $session_name" locks your screen
22:47karolherbst: for example
22:47karolherbst: but it can do tons of more things as well
22:47karolherbst: I think in theory it can even detach devices from sessions
22:50tobijk: 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:55karolherbst: well, deadlock