00:31imirkin: mwk: https://github.com/envytools/envytools/pull/164
00:31imirkin: i haven't looked at it yet
00:47imirkin: this weekend's task - get connector hotplug to work in xf86-video-nouveau
00:54RSpliet: Lyude: the ones someone replied with in your second backlight patch
00:57imirkin: he's the guy who created a lot of the current kernel printk-wrapping macros
00:58imirkin: so he generally knows what he's doing with those
01:15airlied: imirkin: got an mst hub?
01:18imirkin: airlied: picked up a couple of monitors
01:18imirkin: U2415's, they do DP1.2 + chaining
01:19airlied: ah yeah good enough to get to mst firmware bugs :-p
01:19imirkin: and woe be unto he who plugs them in a loop
01:19imirkin: i generally set them up so that only 1 of them speaks DP 1.2
01:20imirkin: the other stays in DP 1.1 mode
01:20imirkin: that generally keeps them out of too much trouble
01:20imirkin: although i get the occasional "blink" (screens go black for about 3s) on a SKL
01:20imirkin: in the past i used to get watermark errors, but no more
01:23imirkin: windows blinks every so often too, so ... just reaffirms my hatred of hardware.
11:43tron42: Hi! I am a developer
11:44tron42: I own a NVidia card and I use nouveau, I'd like to contribute to the project
11:49milesrout: ^ what he said
11:49milesrout: me too
11:56pabs3:not a nouveau dev, but saw https://nouveau.freedesktop.org/wiki/IntroductoryCourse/
11:57pabs3: also https://nouveau.freedesktop.org/wiki/FAQ/#index5h3
11:58pabs3: and https://nouveau.freedesktop.org/wiki/Development/
13:28RSpliet: tron42, milesrout, pabs3: https://trello.com/b/ZudRDiTL/nouveau
13:29RSpliet: In case you're looking for inspiration for something to hack on... although you're best off scratching your own itches
13:32RSpliet: imirkin: thanks for confirming the source of the printk patches. They seemed of good quality, I just wondered whether these patches were a definite win, or rather simply hitting a different point on the mem vs. CPU-cycles trade-off curve
14:30imirkin: RSpliet: yeah, i have no idea. just mentioning who the dude is.
14:51imirkin: skeggsb: so apparently it's possible to get 4k@60 on kepler/maxwell1 over hdmi by somehow forcing the output into YUV420 encoding mode. i don't see any references to this anywhere at all - i wonder if it's a pll hack of some sort.
15:24karolherbst: imirkin: mhh, I mean, this is 1.4b compliant though
15:24karolherbst: imirkin: wikipedia has a note on that: "Possible by using Y′CBCR with 4:2:2 or 4:2:0 subsampling (as noted)"
15:24karolherbst: imirkin: @75 might be also possible, but I think not for nv if we cap at 297MHz?
15:26karolherbst: imirkin: here is the table by the way: https://en.wikipedia.org/wiki/HDMI#Refresh_frequency_limits_for_standard_video
15:26karolherbst: 5k@30 with 4:2:2 might also work
15:29karolherbst: imirkin: by the way, do you know how that vblancing stuff works? Especially how we listen on the events in userspace?
16:07RSpliet: karolherbst: Presumably a userspace thread can call a "wait for vblank" ioctl (or DRM generic ioctl with that effect) will be taken off the scheduler's ready queue and marked blocked on IO or sth. When the VBLANK interrupt hits nouveau, it will ask DRM to put the task back on the ready queue and return w/e it needs (a timestamp? a status code? sth like that...)
16:08karolherbst: RSpliet: yeah, I am more interested on how we do all that syscalls stuff as the GPU reset notifications should be delivered in the same way
16:08karolherbst: I am not quite sure how all that works in the end
16:09RSpliet: I'm not sure if it should be...
16:09karolherbst: I mean, not the same calls
16:09karolherbst: but the same mechanism
16:10karolherbst: I am not 100% if it even works or if I am simply doing something wrong
16:10karolherbst: at least the sys calls returned 0 to create and enable those notifications
16:10karolherbst: there is no ioctl to wait on it
16:10RSpliet: No that's not what I mean. I think for vblank you generally want the userspace application to request to be woken up on a vblank and block until it hits
16:11karolherbst: okay sure, for notifications you want some fd and do something on it like read or select or maybe even epoll
16:11karolherbst: though epoll should be too much for that
16:11RSpliet: a GPU reset is an exceptional situation that I suspect you want to use a different mechanism. More specifically, sending a "signal" (like SIGKILL but rather a... "SIGMYGPUHASBEENRESETGOANDDOSPECIALSTUFF") to the userspace application that registers for this signal
16:12karolherbst: using signals for that is always causing for troubles
16:12karolherbst: we have plenty of fds
16:12karolherbst: and normally if you think about web servers, they also kind of simply wait until _something_ happens
16:12karolherbst: and if you are good, you use epoll for that
16:13RSpliet: Why? I think that's the most reliable mechanism for non-blocking IO initiated by the kernel...
16:13karolherbst: because you have no control over who gets the signal
16:13RSpliet: I don't think it's right to poll for an exceptional situation
16:13karolherbst: RSpliet: epoll_wait ;)
16:14karolherbst: epoll is just the name of the entire framework
16:18karolherbst: anyway, I got told that we already have a mechanism for stuff like that
16:18karolherbst: I was mainly interested in how all that stuff works in the end
16:18karolherbst: I am simply calling the NTFY stuff on the channel we've got in mesa
16:18karolherbst: and it seems like it is successful, I just don't know how to get such an event
16:19RSpliet: Yeah we better have a mechanism for that :-P Channels die all the time, better notify just the one process whose channel got killed rather than every consumer of nouveau :-D
16:19imirkin: karolherbst: no clue. but it's part of drm, so listening to vblank events should be easy. rtfm :)
16:20karolherbst: yeah, point is, I don't want to listen to vblank events
16:20imirkin: i thought you said you did
16:20imirkin: what do you want?
16:21RSpliet: imirkin: understand the userspace<->kernel interaction on a GPU or channel reset
16:21karolherbst: I want to install one of those NVIF_NTFY thingies from userspace and wait on something happening
16:21imirkin: karolherbst: and re yuv420... the question is *how* it gets used.
16:21imirkin: i.e. how do i tell the gpu to output yuv420
16:21imirkin: i only see settings for 422
16:22karolherbst: imirkin: do you have access to a 1440p@120 display?
16:22karolherbst: I doubt you have acces to a 5k@30 one, or maybe
16:22imirkin: 1920x1080 120.00
16:22imirkin: 3840x2160 60.00
16:22imirkin: that's the best i can do.
16:23karolherbst: for 1440p@120 and 5k@30 you can use 4:2:2 subsampling with HDMI 1.4
16:23karolherbst: I think I understood you correct in that you are not able to get those 4:2:0 modes to work, right?
16:23imirkin: the question isn't whether it's possible in theory
16:23imirkin: the question is how to configure the gpu to actually do that
16:24karolherbst: sure, and if nvidia is able to do 4:2:2 but not 4:2:0 it would be easier to check what to do ;) but yeah
16:24imirkin: i'm looking at the display docs that nvidia published
16:24imirkin: and i'm not seeing it.
16:24karolherbst: but there are 4:2:2 references?
16:24imirkin: grep for "422"
16:24karolherbst: I think I saw something... let me check
16:25imirkin: although curious...
16:25imirkin: but there's no 36_422 or 420
16:25imirkin: but there is a
16:26imirkin: and naturally there's a
16:26karolherbst: or NV907D_HEAD_SET_CONTROL_OUTPUT_RESOURCE_PIXEL_DEPTH_BPP_32_422
16:26imirkin: my point is - it's unclear from the docs
16:26karolherbst: yeah, seems so
16:26imirkin: but it does seem like something the hw definitely supports
16:27karolherbst: but in the end you have to limit the bandwith, right? And the GPU can't magically push more through the cable than specified
16:27karolherbst: so I would assume the display has to be able to understand whatever gets pushed there
16:28imirkin: the GPU has to be told what to push on the cable...
16:28imirkin: you give the GPU an image to scan out
16:28imirkin: and tell it "convert it into bits please"
16:28imirkin: it needs to know what the format of those bits is
16:28imirkin: otherwise fail
16:28karolherbst: isn't it that output_resource_pixel stuff?
16:28imirkin: uh huh
16:29imirkin: but 420 and 422 are diff formats
16:29imirkin: so ... how do i make it do 420
16:29karolherbst: doesn't seem there is a 420
16:29imirkin: but i know that the hw is able to do it somehow
16:29imirkin: there are all kinds of references to it
16:29imirkin: in online docs about driver support etc
16:29karolherbst: do you know if nvidia does it on your setup?
16:29imirkin: i haven't dug into it yet.
16:30imirkin: but if your suggestion is "just look at a mmiotrace", then i could have thought of that myself :p
16:30karolherbst: volta seems to have some 420 stuff
16:30karolherbst: but that isn't really helpful to you either
16:30imirkin: kepler+ is supported according to online references
16:30imirkin: oh, btw - unrelated - i've borrowed a GM206 (for the DP-MST testing) -- anything you want from me in its regard?
16:31imirkin: i'll grab a vbios for posterity, but i won't have access to the board for that long - i don't want to keep it on loan longer than necessary
16:31karolherbst: not really, I have a GM204 myself :p and usually if it comes to display things, Lyude is looking into it
16:32karolherbst: reminds me, I need to cleanup my no interlaced modes on DP patches
16:33karolherbst: imirkin: and to stay sane, maybe you want this: https://github.com/karolherbst/nouveau/commit/1e59d8489151fef845f1e111d5d9a55669dc0b04
16:33karolherbst: no idea if current code can trigger really faulty behaviour
16:33karolherbst: it might
16:33imirkin: i like sanity...
16:34imirkin: seems like a pretty huge error ... skeggsb --^
16:34karolherbst: yeah.. it is part of my interlaced fixes
16:34karolherbst: I thought I would clean it up sooner
16:34imirkin: karolherbst: oh wait - in current code shouldn't matter
16:34imirkin: coz there's nothing else in that union
16:35imirkin: but if you add anything else, then fail
16:35karolherbst: but before you end up adding something and run into the same error
16:35imirkin: it's still clearly the right thing to do, but not fatal currently
16:35karolherbst: I am actually wondering why we want to call that mstm thing on all connectors, but maybe we have dunno
16:35karolherbst: I don't know enough
16:35karolherbst: uhm, encoders
16:35imirkin: yeah that's not something i have any clue about
16:36imirkin: seems like we'd only want to do it for DP/eDP encoders? but what do i know. perhaps that's not a thing that an encoder can be.
16:52imirkin: pendingchaos: can you send a patch to add sched info to xf86-video-nouveau? it's likely i'll be doing a release this weekend.
16:52pendingchaos: imirkin: adding .beginsched/.endsched? or using the output of envysched?
16:53pendingchaos: in other words: should it require envysched to compile the shaders
16:54pendingchaos: or should I copy over the output into the *nv110.fp and nv110.vp files
16:55karolherbst: mhh, at least I got the kernel to try to send three notifications instead of 2...
16:55karolherbst: one is the "gr: TRAP ch 2 [00ffbac000 fault]" message, the other the "fifo: channel 2: killed" stuff
16:55karolherbst: and the third is mine... okay
16:56karolherbst: so how to get it
16:57karolherbst: mhh, we should fix that CI stuff
16:57karolherbst: ohh wait
16:57karolherbst: pendingchaos: you should fix that CI error :p
16:57imirkin: pendingchaos: it would ideally not require envysched
16:58pendingchaos: karolherbst: I don't think it was envysched causing it
16:58pendingchaos:nods at imirkin
16:58karolherbst: yeah... mhh weird
16:58karolherbst: but the envytools builds were all passing
16:59karolherbst: and yours is a few hours after the last passing one
17:02karolherbst: pendingchaos: I get the same fail locally
17:03karolherbst: and the commit before it compiles :)
17:06karolherbst: pendingchaos: ohhhhhhh
17:06karolherbst: pendingchaos: name conflict
17:06karolherbst: pendingchaos: "#include <sched.h>"
17:07karolherbst: inside nva/nvaspyi2c.c
17:07karolherbst: so it includes your file instead of whatever it included before
17:08pendingchaos: sorry, I have to go
17:08pendingchaos: I should be back in a few hours
17:14karolherbst: imirkin: do you think we should just "abort" in case we detect a gpu reset inside mesa for applications not requesting the robustness bit on context creation? Alternative is that processes just hang and freeze the system. I think this would also make debugging a bit easier because the application just kills itself. Worst case it is X, but everything is lost in that case anyway. And users have to wait less before being able to
17:14karolherbst: use the machine again. Normally they would just force shutdown
17:14karolherbst: I guess
17:15imirkin: karolherbst: i'd prefer to do the gpu reset and limp along
17:15karolherbst: well, we do the GPU reset
17:15karolherbst: but you have to delete the screen
17:15imirkin: i.e. ensure all the same allocations are there
17:15imirkin: all textures are lost/etc. but keep going.
17:15karolherbst: if an application is requesting a robustness context, that's okay
17:15imirkin: first off, they'll get reuploaded 99% of the time
17:15karolherbst: because applications ar esupposed to delete the context and create a new one
17:15imirkin: through the normal course of running the application
17:15karolherbst: for certain drivers
17:16karolherbst: but we have to delete the entire screen...
17:16karolherbst: this is really really painful
17:16imirkin: so you'll get a few shit frames
17:16imirkin: but then it'll be fine again
17:16imirkin: and if not, the user can exit
17:16karolherbst: screen creation is at dlopen time though. No idea what to do about that yet
17:16karolherbst: I was thinking about just replacing all the fds and move on
17:17imirkin: why would the fd's need replacing?
17:17karolherbst: for robustness that is fine as we can switch to the GL_ERROR_GPU_RESET or whatever that is table
17:17karolherbst: imirkin: because all the objects are dead basically
17:17karolherbst: we need to allocate new channels
17:17imirkin: ehhh ... ok
17:17karolherbst: basically redo everything we do on screen creation
17:18imirkin: having the explicit userspace VA management would really help here.
17:18imirkin: i'd say get that in first
17:18imirkin: and then move on from there.
17:18karolherbst: mhhh, yeah, but I don't really want to rely on any ETA here. Anyway, we have to get that notification about the GPU reset anyhow
17:19karolherbst: I am just wondering if I should spend a minute and just quit the application
17:19karolherbst: or only throw an error?
17:19karolherbst: for robustness that is well defined
17:19imirkin: worry about that later?
17:19karolherbst: yeah, maybe
17:19karolherbst: anyway, I need to implement something for robustness and we can be spec complient here
17:20imirkin: what about the current impl isn't compliant?
17:20karolherbst: well, you can't create such a context with nouveau anyhow
17:20imirkin: pretty sure we're allowed to weasel out of it.
17:20karolherbst: yeah, by not allowing to create such a context ;)
17:21karolherbst: I would expect that at least compositors or window managers or important stuff like that make use of it...
17:21karolherbst: and recreate contexts
17:21karolherbst: would make the life for users less painful
17:21imirkin: i'm not saying it's bad to implement...
17:22imirkin: but having userspace VA management would make it all a lot more tractable to just auto-recover
17:22karolherbst: well, I am not there yet anyway. Still having to get the notifications about GPU reset into mesa :)
17:22imirkin: and it's also needed for vulkan
17:22imirkin: so ... why not do that
17:22karolherbst: yeah, in the end we want to get there anyway
17:22imirkin: instead of reimplementing the same thing 20x
17:22karolherbst: but this reset thing might be just a hour of time to implement
17:22imirkin: then stop talking about it and implement it
17:23karolherbst: as we really don't have to do anything really
17:23imirkin: coz you've been talking about it for >30 mins :p
17:23karolherbst: I know
17:23karolherbst: just wondering what we do for non robustness applications for now
17:23imirkin: but it's more fun to complain...
17:23imirkin: we hang indefinitely
17:23imirkin: stuck while trying to reset the channel
17:23karolherbst: but if we now the channel is dead, we could just abort immediatly
17:24imirkin: i believe that's what we do.
17:24karolherbst: or do something else
17:24imirkin: and fail at it.
17:24karolherbst: well, mesa won't ever know the channel is dead
17:24imirkin: some locking thing iirc?
17:24imirkin: i mean in the kernel
17:24karolherbst: sure, we know that in the kernel
17:25karolherbst: mhh, let me check where my applicaiton actually gets stuck
17:26karolherbst: okay mhh, waiting on a fence of course
17:26karolherbst: uhm, well the kernel isn't stuck actually
17:27karolherbst: it just killed the channel and reset the engines
17:27karolherbst: the situation where we get stuck is for shaders being stuck in a loop
17:27karolherbst: and then we wait inside the kernel
17:27karolherbst: but for those I just want to trap the shaders
17:28imirkin: in my experience, the kernel usually gets stuck trying to kill the channel
17:28karolherbst: mhh, doesn't happen for me
17:28imirkin: unless i go in and kill the offending process myself
17:28karolherbst: instead of those inf loop ones
17:28karolherbst: the process is stuck
17:28karolherbst: waits inside nouveau_fence_wait for me
17:28imirkin: and takes X with it
17:29imirkin: i mean - X is stuck
17:29imirkin: but killing the process fixes X
17:29karolherbst: and for those cases I want those applications to abort or do whatever whenever we know the channel is dead
17:29karolherbst: instead of having to wait or to kill the application
17:31imirkin: but the application is stuck inside nouveau iirc
17:31imirkin: nouveau tries to kill the app
17:31imirkin: and fails.
17:31imirkin: or something.
17:31karolherbst: the thing I currently work with is some CL applications and this is the bt: https://gist.githubusercontent.com/karolherbst/2a3f427c77201c3b4114f8ea66040640/raw/4db4f64f0d6e6b99c254e0616b55590023dce498/gistfile1.txt
17:31imirkin: that's just stuck in userspace
17:32imirkin: i'm talking about X being stuck (a diff process)
17:32karolherbst: wondering about what happens in your case so that nouveau gets stuck
17:32karolherbst: well, is nouveau stuck or X just waiting on the stuck process?
17:32imirkin: btw, we really should update the comm or pid or whatever when an fd gets passed to another process
17:32imirkin: i dunno.
17:33karolherbst: anyway, I want to take care of the simple cases first, which I am able to trigger easily and then try to get those X being stuck things under control as well
17:33karolherbst: from my experience this also happens on prime setups
17:33karolherbst: or on my laptopt
17:33karolherbst: where X is stuck, because it just waits on stupid clients
17:33karolherbst: and other weird effects
17:34imirkin: skeggsb: would you take a patch which updates the cli->name on every ioctl() [if the pid has changed]
17:38karolherbst: imirkin: in which scenarios is that relevant though? compositors/sessions after login getting a fd from logind?
17:38karolherbst: or is it also happening for random X clients?
17:38imirkin: karolherbst: it's relevant in my scenario... fd is allocated by X, passed to client.
17:38karolherbst: right, but when does it happen?
17:38imirkin: all errors/etc show up as coming from X
17:39imirkin: (except for DRI_PRIME, of course, which doesn't go through X)
17:39karolherbst: that explains
17:39karolherbst: yeah, after I am done with it on my prime system here, I go to my gm204 and check if that helps there
17:39karolherbst: I have a plasma installation there, soo probably no problem in triggered some nice errors
17:39karolherbst: *with triggering
17:40karolherbst: anyhow, that ntfy+ioctl code is really really painful to follow :/
17:46imirkin: crap... there are like 20 copies of the client name. inconvenient.
17:48imirkin: cli->name and then there's the nvkm-side cli name...
17:49karolherbst: maybe we shouldn't save it at all and just look it up in case it becomes relevant?
17:49karolherbst: we have the pid
17:49imirkin: yeah, checking how all that works
17:50imirkin: pretty sure there's a %pSomething to print the current task name
17:50imirkin: ... except the "DRM" client is special
17:51karolherbst: mhh, printk %p only exists for functions afaik
17:51karolherbst: ohh wait, maybe there is even more
17:51karolherbst: huh, no processes
17:56imirkin: so nvkm-side, looks like it's only used in nvif_printk and derivatives
17:57imirkin: which among other things happens in nvif_ioctl (trace-level)
17:57imirkin: which in turn means it happens a lot
17:58imirkin: ok. so fine. i'll fix it.
18:22karolherbst: RSpliet: okay, found the code
18:22karolherbst: apperantly we do a "wake_up_interruptible(&filp->event_wait);"
18:22karolherbst: and filep is a drm_file
18:24karolherbst: okay, and it writes into the object I supplied
18:49karolherbst: ahh okay, so that 's just the normal drm event stuff. I guess there are APIs for that
18:52karolherbst: pendingchaos: which application was it that was hanging your GPU? hitman? or the new Tomb Raider?
19:24pendingchaos: karolherbst: Hitman is fine. F1 2015 (IIRC) and Tomb Raider with TressFX cause a hang (though I don't think I have mentioned F1 2015)
19:24pendingchaos: I will probably rename sched.h to codesched.h or something
19:25pmoreau: IIRC, hakzsam was investigating some F1 2015 hang a long time ago, some kind of infinite loop going on in one of the compute? shaders.
19:25karolherbst: pmoreau: ahh, but those are the simpliest ones to debug
19:26pendingchaos: maybe NV<something>WATCHDOG would "fix" that
19:26karolherbst: pmoreau: we just need the framework around it, but we know everything to figure that out
19:26pmoreau: Ah, nice :-)
19:26karolherbst: pmoreau: yeah, I was able to trap a kernel from kernel space to abort stuck shaders
19:26karolherbst: we just need to dump the state and so on
19:27karolherbst: and have a buffer for the state
19:28karolherbst: pmoreau: there is a compute method to set a trap handler on the channel, but it seems to only work for compute shaders
19:28karolherbst: and is more or less new
19:28karolherbst: maxwell+ or something
19:28karolherbst: before that we have a channel bound mmio register
19:29karolherbst: anyway, need to look into it after I am done with the reset stuff
19:37pmoreau: Can’t wait to be able to do some actual debugging with Nouveau :-)
19:38karolherbst: yeah.. that would be nice
19:39karolherbst: I was totally surprised how well that cuda-gdb stuff works
19:44pmoreau: I have been using it extensively when programming in CUDA: being able to set breakpoints, step-through at warp, block, or grid level, reading the registers/memory content, getting the PC of the instruction triggering a mem fault
19:46pendingchaos: imirkin: where should I post the patch? firstname.lastname@example.org?
19:46pendingchaos: should I include a subject prefix other than "[PATCH]"?
19:47imirkin: nouveau@ is fine
19:47imirkin: cc me
19:47imirkin: no special prefix necessary
19:47imirkin: it's not SUCH a high-volume list
19:48imirkin: F1 2015 definitely hangs when you try to start a race
19:48imirkin: hakzsam tracked it down to some value not being initialized/set properly
19:48imirkin: which causes an infinite loop in the shader
19:49imirkin: however it's some value in some ssbo
19:49imirkin: so unclear why it's wrong to begin with
19:50karolherbst: I se
19:52karolherbst: okay, let's see if reading on the fd is actually giving me the event now :)
19:59karolherbst: it works
20:01imirkin: pendingchaos: what's with the "wt 0x3f" stuff at the beginning?
20:01imirkin: does nvidia do that?
20:01pendingchaos: no, envysched does though
20:01pendingchaos: in case the code is used as a function
20:01pendingchaos: it probably could be removed
20:02pendingchaos: (I assume the "wt 0x3f" stuff is needed in the functions in gm107.asm)
20:03karolherbst: yeah, it makes sense
20:03karolherbst: wt 0x3f is implicit if you do "(st 0x0)"
20:04karolherbst: "(st 0x0)" basically means "(st 0x1f wt 0x3f)" I think
20:04pendingchaos: isn't a delay of zero used to signify dual-issue? I assumed "(st 0x0) (st 0x0) (st 0x0)" was some sort of special sequence the hardware checked for
20:06karolherbst: st 0x0 is translated to 0x7e0
20:06karolherbst: and for dual issueing you actually have to use "(st 0x0 yl)"
20:06karolherbst: otherwise it doesn't dual issue
20:07karolherbst: it is still some magic value
20:07karolherbst: pendingchaos: https://github.com/karolherbst/mesa/commit/b700edc474dc4856058541bba2158fd9597967d4
20:09karolherbst: mhh actuall a lone wt 0x0 should translate into all write barriers set and max stall
20:09karolherbst: I am not 100% sure though
20:10karolherbst: that yield flag is also suppose to increase performance, that's why I am not exactly sure, and nvidia sets it pretty much everywhere except on a few things
20:10karolherbst: anyhow, if we set it everywhere, perf is getting much worse
20:14Lyude: RSpliet: there hasn't, but the patches also haven't been merged yet either. I wouldn't think the control flow would be that big of a deal since most of the codepaths that's used in are either not hot paths, or are debugging code. it also really doesn't add that much to begin with
20:15Lyude: i didn't see anything wrong with it when I looked at it
20:21rhyskidd: karolherbst: ^
20:22karolherbst: yeah... I will work more on that if I get to the trap handling stuff
20:33pendingchaos: karolherbst: the CI error is fixed
20:33pendingchaos: just renamed sched.h to codesched.h
20:49karolherbst: sadly that even doesn't exactly contains a lot of data...
20:51karolherbst: which is fine as long as it is the only event type we are subscribing to...
20:52karolherbst: well, we have that token field at least
20:52karolherbst: so we can pass in some func pointers through that, or some struct with data
20:53karolherbst: soo, of course it needs kernel patches + libdrm
20:55karolherbst: skeggsb: https://github.com/karolherbst/nouveau/commit/def9a55e56ae90fc79d99062e11c6991a73f5d25
20:55karolherbst: I guess we also should increase the minor version
20:56karolherbst: or we don't and just check against EACCESS
21:16rhyskidd: pendingchaos: other than perhaps adding some documentation for envysched, it looks good to me
21:17pendingchaos: ah yeah, the .rst stuff
21:17pendingchaos: I should probably add stuff for that
21:48rhyskidd: pendingchaos: good work getting envysched together
21:48rhyskidd: well done
22:06pendingchaos: pushed some commits to add stuff to docs/envydis/index.rst and add a -p option to print "sched (st 0x0) (st 0x0) (st 0x0)"
22:52karolherbst: imirkin: chromium checks for LOSE_CONTEXT_ON_RESET_ARB, nice
22:53karolherbst: aware of any issues with chromium and nouveau?
23:13karolherbst: we kind of need an event loop thingy with that...
23:14karolherbst: or uhm, well, we could probably use dup?
23:21karolherbst: mhh, no, dup doesn't help here
23:51karolherbst: soo, noce
23:51karolherbst: libdrm: https://github.com/karolherbst/drm/commit/cf79f43688d8e1ecc6833df0c38632db96e1327a
23:51karolherbst: mesa: https://github.com/karolherbst/mesa/commit/67f5a991ba39a5ca844eace09b72e08b0972196d
23:52karolherbst: imirkin: ^^ this is what we can currently do with the kernel interfaces
23:53karolherbst: pmoreau: you might be interested as well