00:06Lyude: OH, now that is seriously interesting
00:06Lyude: blacklisting nouveau and rebooting enough times eventually gets me a spurious interrupt before nouveau's loaded
00:06Lyude: and it seems to fail disp if I try loading nouveau after that
00:07Lyude: there's definitely something evil here
00:07Lyude: the owls are not what they seem
00:09karolherbst: Lyude: mhhhh, maybe we get an interrupt which triggers something odd?
00:09Lyude: karolherbst: well, an unclaimed interrupt is almost always a sign something very bad is going on to begin with
00:10Lyude: most likely to do with the fw, I guess then the question is what
00:10karolherbst: Lyude: ohhhhhhhhhhhh
00:10karolherbst: it is so obvious now
00:10karolherbst: we get an interrupt and we _think_ it was the evo failing executing the method
00:10karolherbst: it wasn't the evo
00:11Lyude: there's a catch
00:11karolherbst: it is just that crappy GPU state hammering interrupts like crazy
00:11karolherbst: or well, more or less
00:11Lyude: the thing is when I loaded nouveau after I saw the spurious interrupt, display still failed in response to an interrupt
00:12karolherbst: it makes sense
00:12Lyude: unless the interrupt would remain unclaimed until we loaded nouveau, but it said it was disabling the interrupt entirely
00:12karolherbst: let me read some code
00:12karolherbst: Lyude: no, I think it is something like that: we enable the display engine, so we also start handling those interrupts
00:12karolherbst: the engine is in a weirdo state hammering interrupts until we finish init
00:13karolherbst: Lyude: mind hacking something up to ignore interrupts until we are done calling core507d_init?
00:14karolherbst: until we call evo_wait the first time actually
00:15Lyude: karolherbst: maybe (btw, I am very surprised we aren't already disabling interrupts before doing anything else since I think AMD does that...), I thought I tried that already but I might not have put the write to 0x6100b0 early enough
00:15nyef: Can you "just" mask the interrupts from PDISPLAY at the PBUS level until things are set up?
00:16karolherbst: yeah, it is a guess from my side, but it _might_ be the cause
00:16Lyude: is there anything earlier then disp->init?
00:17karolherbst: Lyude: nouveau_display_create
00:17karolherbst: but... I hope nouveau_display_create isn't doing anything stupid
00:17karolherbst: but you never know
00:17Lyude: it might not need to, the bios could have done something stupid well before it gave us a chance to
00:26karolherbst: Lyude: mhh, do you think something _could_ happen here? "drm_kms_helper_poll_init(dev); drm_kms_helper_poll_disable(dev);" ?
00:26Lyude: but let me take a closer look
00:26karolherbst: I mean, that looks liker super suspicious
00:28karolherbst: Lyude: I guess we might want to move the init up to where we first call _enable?
00:28Lyude: karolherbst: tbh, that is really supposed to only do something if we had polled connectors (and we don't on nouveau) so I'm not terribly suspecious of that
00:28Lyude: but i'm verifying that right now
00:28Lyude: also: interrupt trick didn't work
00:32karolherbst: Lyude: see that "ret = nouveau_bo_new(&drm->client, 4096, " inside nv50_display_create?
00:32Lyude: karolherbst: yeah; that's definitely not doing anything (the polling I mean)
00:32Lyude: karolherbst: yep
00:32karolherbst: that should be the memory we use for the evo stuff
00:35karolherbst: and then we call into nv50_core_new
00:36Lyude: karolherbst: btw, I can still give you access to this machine if you want to take a closer look
00:37karolherbst: yeah, but not today, you can pm me the stuff and then I could check tomorrow morning
00:37Lyude: i want to go home anyway :)
00:38Lyude: heading off now, have a good night!
00:40HdkR: Does Nouveau support Turing yet?
00:40karolherbst: the heck
00:41karolherbst: HdkR: maybe :p
00:42karolherbst: what kind of question is that anyway :D
00:42HdkR: It was just announced, so obviously I had to do the sarcastic question immediately
00:42karolherbst: I mean, either there are patches somewhere, something is merged or people working on it wouldn't be allowed to tell you anyway :p
00:43karolherbst: skeggsb: ^^
00:43HdkR: Siggraph stream just happened
00:47karolherbst: yeah... dunno
00:48karolherbst: I hope Turing doens't have a new ISA...
00:48karolherbst: or other things
00:48HdkR: It's all about the gigglerays
00:50karolherbst: yeah well...
00:50karolherbst: apperantly they pumped up int16 and int8 perf
00:50karolherbst: which _might_ be interesting for dolphin
00:50HdkR: Dolphin needs int24 mostly
00:51karolherbst: soooo int16 + int8 + carry :p
00:51HdkR: or int32 + clamp or mask
00:51karolherbst: that is slower ;)
00:52karolherbst: if int16 is 2x int32 in terms of speed
00:52karolherbst: and int8 4x int32
00:52karolherbst: that might introduce some weirdly optimized shaders
00:52karolherbst: alone because glsl doesn't know about int16 nor int8
00:52karolherbst: a compiler could be outsmarted
00:53karolherbst: int temp = input & 0xffff;
00:53karolherbst: which could be optimized to a single b16 load
00:54karolherbst: maybe clamping would give you the same thing
00:54karolherbst: I don't look forward in writing those passes :D
00:55karolherbst: but uhm....
00:55karolherbst: the ISA has to change for that
00:55karolherbst: another ISA
00:55HdkR:stacks ISAs higher
00:56karolherbst: I mean, with the Volta one they have enough space for all that stuff...
00:56karolherbst: maybe they just add a variant
00:56karolherbst: or something
00:56karolherbst: dunno how much space there actually is
17:16Lyude: karolherbst: poke, I've got the machine here whenever you want to try taking a look at it today
20:48Lyude: karolherbst: I just noticed this: https://paste.fedoraproject.org/paste/UtZP52I0pRyfjWz9DYpgKQ
20:49Lyude: before we create the core channel, the registers the interrupt is complaining about actually contain the core507d_init method
20:49Lyude: then we try kicking it after the disp error happens
20:49Lyude: i'm going to see if I can figure out if anything in nouveau happens to be the one writing those registers before evo gets setup
20:49karolherbst: yeah, makes sense
20:50Lyude: at the very least, someone messing with our push buffer seems slightly less likely
22:09Lyude: karolherbst: you had mentioned that you were worried this weird disp bug might be the cause of some sort of caching issues, correct?
22:10karolherbst: why? :D
22:10Lyude: i just got a lead!
22:11Lyude: happens between lines 2225 and 2235 in drivers/gpu/drm/nouveau/dispnv50/disp.c
22:12Lyude: oh, and a second time between 2235-2241
22:12Lyude: (those line numbers are probably a little off for you, as that's after adding a lot of various printks
22:58Lyude: well, still not much more informed of what's going on here then before, the line numbers don't match any place we're writing, although it sems that the bug might be able to happen anywhere after we call nv50_core_new(), which isn't terribly useful...
22:58Lyude: karolherbst: do you have any idea how we might be able to tell if this is some sort of caching issue or not?
22:59karolherbst: no idea
23:01JayFoxRox: are the NV20 / NV2A fogtables dumped anywhere?
23:52Lyude: skeggsb: what is the bios setup on your p50 like, do you have uefi enabled/disabled? or anything else changed from the defaults?