01:31karolherbst: skeggsb: you don't have some fixes for mmt/demmt lying around somewhere to properly decode the Maxwell+ compute stuff?
01:32skeggsb: no, not really. i've been manually pulling what i need out of raw "mmt_bin2dedma" dumps
01:33karolherbst: uhm... I see
01:33karolherbst: never used mmt_bin2dedma
01:33karolherbst: I guess you basically just look at the hex values yourself and make sense out of it? Or is it a bit more advanced than that
01:34skeggsb: pull the shaders out and run them through nvdisasm
01:34karolherbst: I see
01:34karolherbst: well, that won't help me if I want to figure out how to install trap handlers correctly
01:34karolherbst: or maybe it would?
01:34karolherbst: or maybe you know something?
01:35skeggsb: i don't know anything about that stuff
01:35karolherbst: well, at least the compute method for setting the trap handler address offset is documented
01:35karolherbst: but that seems to be all of it
01:35karolherbst: and the compute header doesn't seem to have a flag like "run trap handler on trap"
01:35karolherbst: or maybe I just set the wrong address or something
01:36karolherbst: skeggsb: anyway, I am already wondering how that works in regards to replayable page faults
01:36karolherbst: because the kernel kind of has to say: uhh, yeah, we can't really.. just run your trap handler, or something like that
01:43skeggsb: i don't think anything special would happen there, the trap handler probably wouldn't get called unless a fault was cancellede
01:44skeggsb: on pascal, the channel would get killed in that case too.. volta, not always, there's some mmu nack exception that can be raised there (sometimes?) instead, which presumably would trap
01:44karolherbst: okay, and if the kernel doesn't find an appropiate mapping, it cancels the fault?
01:44karolherbst: well, currently I want to get manual "bpk trap"s to work, so I am not near the memory stuff yet
01:45karolherbst: uhm "bpt trap"
02:00karolherbst: skeggsb: I am kind of worried, that turing will be a new ISA again :/
02:01mooch3: oh fuck no
02:01mooch3: please god no
02:01mooch3: wait, is turing even OUT yet?
02:02mooch3: doesn't look like it...
02:02karolherbst: no, but I am sure I could check it, but then I won't be able to tell
02:02karolherbst: I mean, regarding the ISA
02:04HdkR: mooch3: Only announced, not released
02:09karolherbst: skeggsb: interesting, Nvidia compares Turing with Pascal, _not_ Volta
02:14karolherbst: I wouldn't be surprised if Turing is based on Pascal and they changed some stuff, the same as Volta, just different and maybe are heading into a different direction overall
02:14karolherbst: I guess we will find out more later this year :)
02:21HdkR: mooch3: Just look for information based on the Quadro RTX
02:22HdkR: That's Turing
02:24mooch2: i know lol
02:26HdkR: It's all about the gigglerays :P
02:32rhyskidd: we might see Turing BIOS' once the Quadro RTX ships (at least for whatever "seq" modifications occur)
02:32rhyskidd: should know tomorrow after the nv presentation at gamescon what the timing is on shipping consumer Turing cards
02:34rhyskidd: so many gigglerays
02:34rhyskidd: we wont know what to do with 'em
02:36rhyskidd: *sigh* why can't the falcons have a _INSERT_NAMED_SPECULATIVE_FLAW_
02:36rhyskidd: Intel gets all the best stuff ...
02:39rhyskidd: at least it appears NVIDIA have avoided an engineering codename collision by calling Turing cores TU10x
02:39rhyskidd: avoiding the Radeon Southern Islands / Sea Islands issues
02:40HdkR: What were their naming issues?
02:41rhyskidd: AMDGPU Southern Islands was ("SI"), so they needed to come up with "CIK" for the later Sea Islands
02:41rhyskidd: couldn't use SI again without confusion abounding
02:42HdkR: Don't want to mix up Turing and Tesla? :P
02:44HdkR: But they are so similar </s>
02:45rhyskidd: the other roadmap question is what happened to "Ampere"?
02:45HdkR: Too many amps, burned itself out
02:45rhyskidd: cf karolherbst's speculation above about potentially going into two different paths of GPU families for differing end markets
04:58bubblethink: Hi. I'm trying to fix tearing for the external monitor in an optimus setup. I found that setting GLXVBlank to true fixes it, but with that set, my laptop's display stops working when there is no external monitor connected
05:00bubblethink: So although man pages mention GLXVBlank as true by default, it isn't in optimus setups ?
05:02bubblethink: This is on a Thinkpad W530 (ivybridge + kepler GPU and hardware mux). The OS is ubuntu 18.04
05:03bubblethink: All I want to achieve is a tear free external monitor setup. Not even a dual monitor setup. Just the external monitor when the laptop is docked
05:04bubblethink: some way to get the behaviour of GLXVBlank when the external monitor is connected, but not affect the laptop's display when there is no monitor
08:01kiljacken: I'm having problems using higher resolutions without flickering when using nouveau on my macbook pro 9,2 (GeForce 9600M GT), can anybody lend a hand?
09:31RSpliet: kiljacken: the most likely offender is the DRAM clock being too low. I don't know/think we can change that on 9600M GT (or most of the G9x cards to be honest)
09:33RSpliet: I looked into that ages ago, but really don't have time at the moment :-(
09:36kiljacken: Thanks, guess I'll have to spend some time to make the proprietary driver work then, as it doesn't out of the box any more
09:37RSpliet: Sorry. You can always try what happens when you play with /sys/kernel/debug/dri/<number>/pstate - worst case it refuses or hangs your machine (which should be solved with a simple reboot)
09:38RSpliet: I really forgot what I did and didn't implement on those generations. The whole second gen Tesla (the low-end GT2x0 and even a GT240 or GTX260) should work... fiddled around with some older cards like yours, but never had the time to polish it and test widely
09:39RSpliet: And there's definitely missing work ;-)
09:40RSpliet: (but... since yours is GDDR3 rather than DDR2, you may get lucky)
09:44kiljacken: Changing pstates helps a bit, i can get to 1280x800 with the highest pstate, but it's a far shot from 2560x1440 (which i'm not sure the link even supports)
09:45kiljacken: The old 340xx nvidia driver is broken due to changes in the kernel (i think) so might need to try an older kernel. I'm pretty sure I got it working in the past
11:40karolherbst: mslusarz: mhh, that mmiotrace doesn't seem to be very helpful regarding those syscalls: https://gist.github.com/karolherbst/367e6514871ecd295061cb5c5a113965
11:40karolherbst: or at least not directly
11:41karolherbst: I assume something is setup with the other ones and 0x21 just looks something up from somewhere
16:36Lyude: skeggsb: what does "pioc" mean in the context of evo?
17:21Lyude: skeggsb, karolherbst: the (hopefully last) important fixes for nouveau on the P50 are up, those patches should fix the random disp init errors I was seeing
17:36karolherbst: looks fine
17:36karolherbst: I mean, I am sure there might be a better or more straight forward way of doing that. Did you check nvidia mmiotraces of they do something similiar?
17:37karolherbst: or do they simply mess up in such a case?
17:37Lyude: karolherbst: yeah nvidia just completely fails to init in that case
17:38karolherbst: sooo, maybe we forget to do something on suspend
17:38Lyude: no-this only happens on the first module load after booting the machine
17:38karolherbst: ohh, okay
17:38Lyude: I checked after a couple rpm cycles and the channels seem to go back to normal afterwards
17:38karolherbst: sooo, nvidia could crash on boot as well?
17:39Lyude: karolherbst: yep
17:39Lyude: I also went through and tried to find anything else that looked like it might be able to hit that error
17:39Lyude: luckily the other channels that get left on seem to reset themselves just fine without any workarounds needed when we start setting them up
17:39Lyude: pioc does at least
17:41Lyude: it would be worth double checking if there are any other channels than core/dmac/pioc that I should verify
17:41karolherbst: mhh, maybe skeggsb knows more about it
18:41mslusarz: karolherbst: look for "ioctl pre 0x21", not those verbose VG core messages, I suspect they are not synchronized with the mmt command stream
18:42HdkR: Looking forward to Nouveau supporting the 2080 ti :)
18:48mslusarz: karolherbst: oh, and btw, once you'll confirm 0x21 is the ioctl that does the vm mapping, you could modify mmt to find ioctl size using the same logic that ioctl_create fuzzer uses
19:14Lyude: karolherbst: hm, looks like we might actually want that MST fix for nouveau with the P50 (although it's a lot less important right now then the other patches I've got atm) that you showed me a while back, e.g. the one where we ack esi interrupts even if we didn't get anything
19:15Lyude: because as it turns out, sometimes we do get something that we mistakenly ignore!
19:15Lyude: [ 2888.405802] [drm:drm_dp_dpcd_read [drm_kms_helper]] sor-0006-0f42: 0x02002 AUX -> (ret= 8) 02 20 00 00 00 00 00 00
19:15Lyude: might be an hdcp check or something like that
19:17Lyude: or hm, maybe at least when we see bits in 0x2002 getting set even if we don't handle them ourselves
19:19Lyude: not entirely sure yet though
19:21karolherbst: mslusarz: for whatever reasons, those don't show up in the trace
19:21karolherbst: maybe the buffer is still too small
19:21karolherbst: I had problems with the 64k one
20:14karolherbst: mslusarz: uhm, I don't think demmt logs those ioctl pre entryes with those mmiotrace scripts :(
20:17karolherbst: ahh, now I got them
20:17karolherbst: I guess buffer is still too small
20:21karolherbst: Lyude: uhm, so we still get that MST fail?
20:21Lyude: karolherbst: nope, not from docking/undocking, that part works 100%
20:21karolherbst: ohh okay
20:21karolherbst: but same thing basically?
20:21Lyude: karolherbst: but if we hotplug on the dock itself, that causes some issues
20:21Lyude: karolherbst: sort of, i've figured out a bit more what's happening and it's quite different
20:21karolherbst: uhm, yeah, that's what I wrote the patch for
20:21karolherbst: hotplugging the dock
20:21karolherbst: not the displays
20:22Lyude: karolherbst: sorry-I meant hotplugging displays /on the dock/, not the dock itself, should have worded that better
20:22karolherbst: ahh, okay
20:22Lyude: yeah, it's less important but I can fix it now that i've got all of the big stuff on the P50 fixed
20:24Lyude: what seems to be happening is that we make the mistake of calling drm_kms_helper_hotplug_event() from drm_dp_mst_hpd_irq() which in turn causes us to trigger fbhelper's connector probing, which in turn causes it to start trying to send messages to the MST hub from the same thread which require we wait for a response from the ESI for
20:24Lyude: of course-that doesn't work, because the ESI handler itself is now the one waiting, which causes us to start timing ourselves out and puts the dock out of sync with our state e.g. it kills the hub
20:25karolherbst: yeah, that makes sense
20:25Lyude: adding DP aux tracing was the best decision I've ever made in my life :)
22:15karolherbst: mslusarz: I am stupid... I am sure those are the nvidia-uvm ioctls
22:15karolherbst: and nvidia-uvm is basically open source
22:16karolherbst: "kernel/nvidia-uvm/uvm_ioctl.h" in the nvidia source
22:16karolherbst: 0x27: UVM_PAGEABLE_MEM_ACCESS
22:16karolherbst: 0x25: UVM_REGISTER_GPU
22:16karolherbst: 0x17: UVM_CREATE_RANGE_GROUP
22:16karolherbst: 0x19: UVM_REGISTER_GPU_VASPACE
22:17karolherbst: 0x21: UVM_MAP_EXTERNAL_ALLOCATION
22:17karolherbst: 0x1b: UVM_REGISTER_CHANNEL
22:17karolherbst: even with the structs inside that header
22:26karolherbst: mslusarz: I added a printk to nvidia-uvm: https://gist.githubusercontent.com/karolherbst/92d7520644b049caff73b8e39531dcc4/raw/63a549ebe37beb2b9b1b18e0ae8d6a300a4d794a/gistfile1.txt
22:29karolherbst: problem is, mmt_nv_ioctl_pre doesn't handle those as if ((id & 0x0000FF00) != 0x4600) return 0; is always hit with those
22:42karolherbst: HdkR: side note: Turing _will_ be tons of fun, I can guarentee it :D
22:46HdkR: At least they won't be $3000 so people can get more eyes on it :)
22:46karolherbst: watch out for the new OpenGL extensions, those will be fun
22:48mslusarz: karolherbst: great, so now you have to handle those ioctls ids if fd is from /dev/nvidia-uvm
22:48karolherbst: I am just wondering how to add those things to mmt
22:48mslusarz: don't worry about this "if"
22:48karolherbst: do you think it makes sense to split the handlers? or just put everything inside mmt_nv_ioctl_pre/post ?
22:49mslusarz: 0x46 is nvidia ioctl idntifier, which, again, they didn't use here for some reason
22:50karolherbst: I think it is a different ioctl range
22:50karolherbst: allthough I guess it should be fine
22:50karolherbst: 0x00 means it is nvidia-uvm then
22:50karolherbst: but then we have those weird ones
22:50karolherbst: 0x30000001 and 0x7ff
22:52karolherbst: anyway, first step is to read the passed in struct and dump data anyway
22:53mslusarz: well, I wouldn't look at ioctl group id
22:53mslusarz: I think it's better to filter them by fd they are called on
22:54karolherbst: so basically on which file they got called. "nvidia0" are the ones with the 0x46 identifier? or does that also include the ones called on nvidiactl?
22:55mslusarz: IIRC 0x46 are called on both
22:59karolherbst: mslusarz: any idea how I can figure the file out? Otherwise I would try to find a proper method
23:00mslusarz: what do you mean by "file" here?
23:01mslusarz: you mean fd to file mapping?
23:01karolherbst: path or name or something else how we can figure out on which driver the ioctl was called on
23:01mslusarz: one sec
23:04karolherbst: mslusarz: okay, but I was more thinking about inside mmt_pre_syscall where we only have the fd basically
23:05karolherbst: I mean, we could probably set some bit from there
23:05mslusarz: make another fd_set for nvidia-uvm fds and check it with FD_ISSET in mmt_pre_syscall
23:05karolherbst: okay, makes sense
23:29HdkR: karolherbst: Are you a Khronos member? :P
23:44airlied: HdkR: yeah he is :0)
23:47HdkR: airlied: Ah, that's why the extensions are visible then :P
23:47HdkR: Spies :P