00:56 dakr: airlied, remeber the fix from yesterday to check chan->killed in nouveau_ioctl_exec() to avoid subsequent jobs to hang waiting for the fence to signal??
00:57 dakr: there could also be already queued up exec jobs..
00:59 dakr: e.g. job C depends on B depends on A, when A fails and the channel is killed job B will hang waiting for the fence..
01:00 airlied: dakr: yeah I think we have to work out a plan for those as well
01:00 airlied:is in training today so no planning :-P
01:00 dakr: in userspace the corresponding syncobj will time out and the client will destroy the channel sooner or later, which will also kill the fence context, which will signal the fence and job C will run and cause a fault on the deleted fence context
01:02 airlied: dEQP-VK.memory.*
01:02 airlied: Passed: 2535/3205 (79.1%)
01:02 airlied: Failed: 20/3205 (0.6%)
01:02 airlied: not too bad
01:02 dakr: yeah..
01:02 dakr: I'd have two ideas how to fix this issue:
01:03 dakr: first, we could tear down the sched_entity in nouveau_channel_killed() right before nouveau_fence_context_kill() which will signal all pending fences.
01:04 dakr: second, reject emitting a new fence in nouveau_fence_emit() when the fence context is killed.
01:04 dakr: second would still let the jobs run even though they can't succeed, but they wouldn't block anymore.
01:05 airlied: I'd try the first and see how it goes
01:07 dakr: yeah, I agree, and now we're getting there..
01:07 dakr: we already did, remember this one? https://paste.centos.org/view/raw/df0fe16b
01:08 dakr: for me the backtrace of nouveau_channel_killed() looks different and isn't in atomic context
01:08 airlied: dakr: oh I merged some of Ben's code into my tere
01:09 airlied: so I could get the stability fixes
01:11 dakr: if run nouveau_channel_killed() with preemption disabled we can only tear down the sched_entity by scheduling a work item, which makes it racy and hence we'd need to take the second approch.
01:12 dakr: airlied, I wonder what's the reason for the change, can you point me to the commits?
01:15 airlied: dakr: https://gitlab.freedesktop.org/skeggsb/nouveau/-/tree/00.06-gr-ampere is the tree
01:15 airlied: it's got a lot of stuff in it
01:30 dakr: airlied, with those changes nouveau_channel_killed() is called with two spinlocks acquired..
01:34 dakr: so, probably need to refuse emitting a fence when the fence context / channel is killed and tear down the sched entity based on that
01:39 dakr: skeggsb_, you have another idea to deal with that given your recent changes?
03:09 fdobridge: <j​ekstrand> airlied: At some point, I should probably take your branches and make them do the interesting things and see how badly things fall over. IDK that you're ready for that yet, though. 😅
03:09 fdobridge: <j​ekstrand> I'm also in no rush.
03:10 fdobridge: <j​ekstrand> Rest of this week will be code review and little stuff. Starting in on NAK on Monday. That's the plan anyway.
03:12 airlied: jekstrand: not ready yet, though I'm trying the first full cts parallel run now and it hasn't fallen over yet
03:13 airlied: jekstrand: have to think about alignment a bit more as well
03:14 airlied: having to align images to what the hw requires esp when compression kinds are used
03:14 airlied: might need some nil enhancements
05:00 airlied: Pass: 197325, Fail: 12522, Crash: 1704, Warn: 4, Skip: 1395119, Timeout: 5, Missing: 5749, Flake: 24828, Duration: 3:25:02, Remaining: 0 from a run on uapi
06:32 airlied: dakr: timeline semaphores seems to function too!
06:34 airlied: dakr: oh the nouveau exec ioctl needs a u32 padding between the u32 and u64
06:35 airlied: as does the bind one
06:39 airlied: okay timeline semaphores kinda work, one test hung wierd
07:31 airlied: jekstrand, dakr : I've stuck the new uapi changes for nvk into an MR
07:31 airlied: jekstrand: I'd appreciate any pre-review of any of it you have time for
07:31 airlied: there's quite a few changes outside the obvious syncobj/mem allocs
13:08 vliaskov: hi skeggsb_ karolherbst is there a bleeding edge branch that I can try ampere tests on instead of mainline? E.g. https://gitlab.freedesktop.org/skeggsb/nouveau/-/commits/00.06-gr-ampere and https://gitlab.freedesktop.org/skeggsb/nouveau/-/commits/01.01-gsp-rm have a new interrupt tree for TU/GA and reworked mc ampere component (among many other unrelated changes). I am not yet interested in hwaccel / gr, just stable
13:08 vliaskov: display and runpm. Still trying to debug "mc: intr 00000040" message and stacktraces seen on https://pastebin.com/8PHpuBus
13:09 vliaskov: I also wonder what nouveau branch this tweet refers to: https://twitter.com/jekstrand_/status/1560648097197608961 perhaps that wouldn't be ampere related though
15:43 jekstrand: vliaskov: No, not ampere-related.
15:44 jekstrand: airlied: Yeah, I'll try to take a look this afternoon. Need to use my good brain time for SPIR-V CFG review
15:58 dakr: airlied, sounds good!
15:59 dakr: airlied, regarding the hung test, is it one that makes the channel fail?
16:00 dakr: I fixed the fault we've got in such a case, but syncobj might still be blocked by the fence never getting signaled.
16:02 dakr: Another option to fix that would be to use the scheduler timeout handler to unblock such a job, but I still think we probably shouldn't insert a new fence on a killed channel / fence context.
16:10 dakr: This would also give us the option to set the dma fence' status to -ENODEV, indicating userspace that the channel is dead.
17:51 TimurTabi: @jekstrand: aren't you talking about the 01.01-gsp-rm branch?
17:52 airlied: probably the ampere one
17:52 airlied: its the one with all the stability work, the gsprm vranch is based on it
17:58 fdobridge: <g​ouz> hello all,
17:58 fdobridge: <g​ouz> i am trying to debug a GL app with valgrind-mmt (followed https://nouveau.freedesktop.org/Valgrind-mmt.html)
17:58 fdobridge: <g​ouz> but i am getting errors such as:
17:58 fdobridge: <g​ouz> ERROR: nvrm_ioctl_host_map56: cannot find object 0xc1d0004e 0xbeefc360
17:58 fdobridge: <g​ouz> ERROR: nvrm_mmap: couldn't find object/space offset: 0x0000000000000000
17:58 fdobridge: <g​ouz> ERROR: Can't detect chipset, you need to use -m option or regenerate trace with newer mmt (> Sep 7 2014)
17:58 fdobridge: <g​ouz> i am running on the proprietary nvidia driver on an rtx 2070
17:59 fdobridge: <k​arolherbst🐧🦀> yeah.. that stuff doesn't work anymore with newest drivers
17:59 fdobridge: <g​ouz> 😩
17:59 fdobridge: <k​arolherbst🐧🦀> I have some WIP aptches to wire up UVM, but that's very painful
17:59 fdobridge: <g​ouz> ahh ok thanks!
18:00 fdobridge: <k​arolherbst🐧🦀> https://github.com/karolherbst/valgrind/commits/uvm
18:00 fdobridge: <k​arolherbst🐧🦀> and https://github.com/karolherbst/envytools/commits/UVM
18:01 fdobridge: <g​ouz> i am going to try it!
18:01 fdobridge: <k​arolherbst🐧🦀> not really sure it's worth it though as now we have the open source driver and could just dump stuff there
18:01 fdobridge: <k​arolherbst🐧🦀> also probably needs to rebased and adjusted to the newer driver versions
18:01 fdobridge: <g​ouz> i probably should explain what lead me to this
18:02 fdobridge: <g​ouz> i was experimenting with instanced drawing in nvk, some tests do not pass because there is no support for gl_BaseInstance in the shaders
18:02 fdobridge: <g​ouz> for gallium nouveau these values are passed with a ubo i think
18:03 fdobridge: <k​arolherbst🐧🦀> yeah.. but if you have questions about what the ISA supports I can also answer those
18:03 fdobridge: <g​ouz> oh nice!
18:03 fdobridge: <g​ouz> do you think there exists such a value as a system value?
18:04 fdobridge: <k​arolherbst🐧🦀> let me check
18:07 fdobridge: <k​arolherbst🐧🦀> nope, doesn't seem to exist
18:07 fdobridge: <k​arolherbst🐧🦀> guess you'll have to copy what we do in gallium
18:08 fdobridge: <k​arolherbst🐧🦀> but jekstrand has some cheating ways of dumping command buffers
18:09 fdobridge: <g​ouz> for testing, i managed to pass it through the nvk_root_descriptor_table and it works, but this is not the correct solution i think
18:10 fdobridge: <g​ouz> good for experimenting though 🙂
18:11 fdobridge: <j​ekstrand> Eh, it's as good as anything
18:11 fdobridge: <g​ouz> but that way i cannot support gl_DrawID (i.e. on multidraw)
18:11 fdobridge: <j​ekstrand> Right
18:14 fdobridge: <j​ekstrand> For gl_DrawID, I think we want to have a spot reserved in the root descriptor but then emit a `LOAD_CONSTANT_BUFFER` from the MME to set the value.
18:18 fdobridge: <g​ouz> I think I understand
18:19 fdobridge: <g​ouz> Should I try implementing the gl_BaseInstance case as said above?
18:22 fdobridge: <j​ekstrand> Sure but if you get into nouveau/codegen, walk away. I'm going to start typing us a new compiler on Monday so I don't want to add more weird interdependencies between NVK and codegen.
18:22 fdobridge: <j​ekstrand> In particular, if it has to be plumbed through some hard-coded constant buffer or similar.
18:24 fdobridge: <g​ouz> Ok nice! I will try something out and add a merge request for review
18:25 fdobridge: <j​ekstrand> cool
22:15 airlied: jekstrand: always syncing is actually a bit painful, since I have to make a syncobj :-P
22:15 jekstrand: airlied: Yeah, well...
22:16 jekstrand: airlied: There's something to be said for having a syncobj per queue which we always signal so that we have a way to do waitIdle().
22:17 jekstrand: Not actual vkQueueWaitIdle(). That's already handled in common code.
22:17 jekstrand: But for things like "OMG we need to swap out the texture pool"
22:17 jekstrand: Which, incidentally, you need to do. IDK if you have code for that yet.
22:19 airlied:has no idea what "swapping out the texture pool" entails thankfully
22:48 jekstrand: airlied: If anything ever changes in nvk_queue_state_update(), we need to idle the queue
22:48 jekstrand: airlied: It should only happen a single digit number of times per app launch so idling is fine and saves us from having to reference count.