01:11orbisvicis: imirkin: any way I can get drm-next as a patch against rc8 ?
01:13imirkin: just grab the git tree
01:13imirkin: and then run "git diff v4.9-rc8..drm-next"
01:13orbisvicis: heh that works
01:13orbisvicis: well now I know what to do... just have to do it :)
06:20gnurou: skeggsb: send the falcon library series - hopefully I understood what you wanted
06:21skeggsb: gnurou: i've had a quick look already, i want to play with it a little before commenting too much :P
06:22gnurou: skeggsb: sure. keep in mind that this is only the first step, I think I know how we can convert everything (including the current pmu/ and NVIDIA's own message queue) using this as a basis
06:23gnurou: skeggsb: I just want to get this in ASAP so I can rebase my secboot series (looking forward to doing it... not) and move forward with this as well
06:32gnurou: skeggsb: ah, I also wanted to ask you about if you had any suggestion for how we could port devinit to this lib without allocating temporary buffers...
06:33skeggsb: i'll take a crack at it, and the other engines, to get a feel for the code
06:33skeggsb: consider it my way of reviewing :P
06:33gnurou: I like that. sorry for giving you extra work though
06:34skeggsb: nah, it's fine, need something to break up the horror of multithreading
16:14mlankhorst: whats wrong with multithreading? O:)
16:14imirkin_: it killed me, and it's about to consume ben too
16:17karolsummer: skeggsb: got any time to looker over my G92 pci patches?
16:17karolherbst: … silly irc client
16:19mlankhorst: what's wrong with just writing all relevant state in each command submission, in which case the races become unimportant?
16:19karolherbst: mlankhorst: multiple applications?
16:20imirkin_: mlankhorst: there are deeper problems than that atm
16:20imirkin_: and we really don't want to tank perf
16:21karolherbst: but maybe it isn't that bad actually. first make sure that the kernel module has no race conditions, then fix up the X thing. allthough that might take a while
16:21orbisvicis: imirkin_: sorry to be such a pain, but v4.9-rc8 doesn't exist, unless I should diff between drm-next branch and another repository ?
16:22mlankhorst: orbisvicis: do you have linus' repo as a remote?
16:22karolherbst: but I am quite sure there aren't any easy triggerable race conditions on the kernel side
16:22karolherbst: imirkin: are you aware of any issues within the kernel regarding this?
16:22mlankhorst: yeah I personally like the eviction stress test bringing down the sste :)
16:23karolherbst: mlankhorst: you know what may be fun?
16:23karolherbst: mlankhorst: application against libdrm locking up nouveau
16:23mlankhorst: not that hard
16:23karolherbst: and then fix libdrm + nouveau until there is no issue anymore (tm)
16:24imirkin_: karolherbst: parallel piglit has always done the trick for me
16:24karolherbst: not for me
16:24imirkin_: although ben has a fix in the latest kernel that i'm hopeful will "fix" it
16:24imirkin_: yeah, it never broke for ben either
16:24karolherbst: I didn't found any way to trigger those issues
16:25karolherbst: I even ran my entire plasma desktop on the GPU through prime
16:25karolherbst: no crash
16:25karolherbst: not even in those webengine applications
16:25imirkin_: i think it's because i use shit gpu's
16:25imirkin_: which hit different race conditions
16:25imirkin_: well aren't you special :p
16:25karolherbst: I think the DDX is actually an important factor here
16:25imirkin_: yeah, it's a second client
16:25mlankhorst: run max-texture-size in parallel till it crashes
16:25mlankhorst: 3 or 4 is enough
16:25karolherbst: will try to do the same with outputsinkoffloading
16:25imirkin_: you have fewer context switches
16:25karolherbst: imirkin: I had like 50 references on the module
16:25imirkin_: mlankhorst: ah, that's an oldie but a goodie ;)
16:26mlankhorst: never fails!
16:26karolherbst: your systems are just weak
16:26mlankhorst: I gave up and ran the blob again
16:26karolherbst: mlankhorst: well writing simple tests would be helpful
16:26karolherbst: the simplier the better
16:27karolherbst: and if X isn't involved, it is even easy to track down
16:27mlankhorst: karolherbst: I had a patch that inserted guard pages in each kernel allocation
16:27mlankhorst: still hard to trigger
16:27karolherbst: that's not the issue though
16:28karolherbst: the issue is, that the nouveau interface is bombed with a lot of stuff
16:28karolherbst: and sometimes a race condition is triggered
16:28imirkin_: karolherbst: i suspect mlankhorst has a better grasp of the max-texture-size issue :)
16:28imirkin_: he spent like ... a year on it
16:28karolherbst: I thought he was talking about nouveau multithreading
16:29imirkin_: nouveau multithreading is not a kernel issue, it's a purely userspace mesa issue
16:29imirkin_: nouveau also has separate issues due to multiple clients, but that's unrelated
16:29karolherbst: I see
16:32mlankhorst: gave up in the end, happens on fermi and earlier too
20:30mupuf: skeggsb: hey. I completely forgot about this issue with the LED class when it is compiled as a module
20:30mupuf: what should I do to say to look for an external symbol?
20:46karolherbst: mupuf: nouveau builtin + LED_SUBDEV as module?
20:46mupuf: oh, good question
20:47karolherbst: or what issue were you talking about?
20:47mupuf: nouveau=y, leds_class=m
20:48mupuf: it is pretty stupid, but hey, maybe we can force leds_class as a dependency
20:48karolherbst: mhh mhh
20:48karolherbst: I don't like implicit dependencies anyway
20:48karolherbst: I think best would be, if nouveau is builtin, only led_subdev builtin is allowed
20:48karolherbst: or n
20:48mupuf: basically, we would need =y/m depending on nouveau's way of being compiled
20:48karolherbst: no idea how to declare that though
20:49mupuf: me neither
21:18karolherbst: \o/, got my smart dyn reclocking working again
21:20karolherbst: look for "reclock request from PMU", "sending ACK" and "dyn reclocking to "
21:20karolherbst: and "staying at"