12:36 karolherbst: imirkin: now that we can know from the kernel when the channel is dead, any idea what we should do in case an application hits a dead channel? just crashing so that X/whatever doesn't freeze forever?
12:36 karolherbst: kind of next on my todo list after getting the MT stuff figured out
12:56 imirkin: karolherbst: well, there's a way to indicate to the application that the context is lost
12:57 karolherbst: ohh sure
12:57 imirkin: karolherbst: an application should indicate whether it supports this event or not
12:57 karolherbst: but not if they don't create a robustness context
12:57 karolherbst: and I am talking aboue the case where applications don't
12:57 imirkin: if it doesn't, then the kernel should just kill it
12:57 imirkin: but you have to be careful to kill the right application
12:57 karolherbst: well, the kernel doesn't know if the application requested a robustness context ;)
12:58 karolherbst: hence me thinking we should kill in mesa
12:58 karolherbst: there we know it
12:58 karolherbst: and we know when the channel is dead
12:58 karolherbst: special error value on command submission
12:58 imirkin: mesa would be an example of an application that can handle the signal
12:58 imirkin: but e.g. "old mesa"
12:58 imirkin: or other applications
12:58 imirkin: which use the nouveau api's directly
12:58 imirkin: might not
12:58 imirkin: the client should indicate that it supports this on channel creation
12:58 karolherbst: well, they have to handle error values anyway
12:59 karolherbst: can't just do ioctls and ignore errors
12:59 HdkR: Applications use nouveau directly? That's madness
12:59 karolherbst: I honestly don't think we would want to add a new communication channel between applications and the kernel just to report channel events
12:59 karolherbst: I tried that
12:59 karolherbst: it's not feasible
13:00 karolherbst: not at all
13:00 karolherbst: as you would have to rewrite all clients one way or the other
13:00 imirkin: karolherbst: ah, so you just want to return a new error from gem_pushbuf or whatever?
13:00 karolherbst: we already have that
13:00 karolherbst: I think you get ENODEV when the channel ist dead
13:01 karolherbst: not 100% on the exact error value
13:01 imirkin: ok
13:01 imirkin: yeah, that sounds familiar actually
13:01 karolherbst: wondering if we should just check for that in mesa and segfault or wahtever
13:01 karolherbst: or abort()
13:01 karolherbst: well..
13:02 karolherbst: for clients without a robustness context
13:02 karolherbst: there is the rare case of clients not doing another submit after submitting the pushbuffer breaking the context, but.. mhh
13:02 karolherbst: we could also poll randomly if we really want to
13:03 karolherbst: we do so when waiting on fences anyway
13:03 karolherbst: and I think there we also get the same error
13:03 imirkin: adding a kernel ioctl for "wait on this fence" would be super.
13:03 karolherbst: anyway... I would work out the details, just wondering if you agree with the general idea
13:03 karolherbst: mhh, yeah... right
13:03 karolherbst: currently we busy loop
13:03 imirkin: yes.
13:04 karolherbst: and I think skeggsb_ mm/cs rework will give us new options anyway
13:04 karolherbst: so I'd rather just reuse whatever we have today
13:04 imirkin: ok
14:13 karolherbst: mixing 1.2V and 1.35V DDR4 ram modules is always fun...
14:52 karolherbst: okay... 2.533 GHz seems to work alirght... I got like super random compilation issues at 2.666GHz :D
14:52 karolherbst: and somehow the firmware enabled XMP on its own
14:55 imirkin: karolherbst: btw, you didn't finish with the https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9740 review
14:56 karolherbst: ehh.. yes, forgot to respond
14:58 imirkin: thanks
16:57 imirkin: mwk: is I2F.F32.S16.BEXT nvidia's way of saying "F32.S8"? What's "BEXT"?
16:59 mwk: I'd guess so
16:59 mwk: BEXT would probably be "byte extend"
17:00 imirkin: i'm seeing a really odd issue with my rgba8_snorm conversion to/from fp32 failing ... for some values.
17:00 imirkin: like a handful of values
17:00 imirkin: still need to track down which values.
17:01 mwk: so the thing you have to know about conversions from s8/u8 is... actually there are two variants of that instruction
17:01 mwk: one which has the input in a 32-bit register, and the other that has input in a 16-bit register
17:01 imirkin: yeah, doing the 32-bit ones:
17:01 imirkin: cvt rn f32 $r3 s8 $r1l
17:01 imirkin: and then going the other way:
17:01 mwk: I suppose S16 signifies that input is a 16-bit reg, and BEXT that it's actually 8-bit
17:02 imirkin: cvt rni s16 $r2l f32 $r2
17:02 imirkin: (since f32->s8 directly doesn't exist)
17:02 imirkin: but then i just & 0xff it, and all is well
17:02 mwk: hold on a minute
17:02 mwk: i2f does have hardware bugs
17:02 mwk: which are actually simulated in hwtest
17:02 mwk: let me just verify the preconditions...
17:03 imirkin: if (!(op2 & 0x04000000)) {
17:03 imirkin: /* simulate hardware bugs. */
17:03 imirkin: if (rm == FP_RN || rm == FP_RP) {
17:03 imirkin: if ((s1 >> 5 & 0x1ffffff) == 0x1ffffff)
17:03 imirkin: s1 = 0;
17:03 mwk: yes, when converting from 16-bit register in RN or RP mode
17:04 imirkin: which i guess is what i'm doing...
17:04 mwk: mhm
17:04 imirkin: wtf does rounding even mean in that case?
17:04 imirkin: i guess 16-bit -> fp16 it matters
17:04 imirkin: but 16-bit -> fp32 shouldn't matter
17:04 mwk: oh wait, bug also happens in other rounding modes
17:04 mwk: it's just slightly different for these two modes
17:05 mwk: hmm
17:05 imirkin: if (!(op2 & 0x04000000)) {
17:05 imirkin: i don't think i satisfy that condition
17:05 mwk: why doesn't this make sense...
17:05 imirkin: 00000020: a0000409 44018780 cvt rn f32 $r2 s8 $r1l
17:05 mwk: oh I screwed up
17:06 mwk: it's conversion *to* 16-bit register, not from
17:06 mwk: ie. convesion to f16
17:06 imirkin: yea
17:06 imirkin: i only do f32 <-> f16 conversions
17:06 imirkin: never int <-> f16
17:06 mwk: good
17:07 imirkin: so i literally just round-trip it in registers (since the opt isn't smart enough to figure out what's going on)
17:07 imirkin: https://paste.debian.net/1190488/
17:07 imirkin: and somehow this produces errors ... sometimes
17:10 imirkin: (there's normally be scaling factors involved in the conversion, but the optimizer *is* smart enough to remove those)
17:11 mwk: I have no idea what could be wrong here
17:11 imirkin: ok, thanks for looking :)
17:11 imirkin: glad to know i'm not just *completely* incompetent
17:12 imirkin: i'm going to start instrumenting the test to figure out wtf it's doing
17:12 imirkin: it'll probably end up being like constbuf upload or something ridiculously unrelated like that
17:51 Lyude: danvet, karolherbst - I submitted a patch to revert the adertised cursor sizes
17:51 Lyude: i think the patch just hasn't gotten merged upstream yet
17:51 Lyude: (neither have a couple of the other patches that I've got pending in the pipeline either)
17:51 karolherbst: ohh that reminds me...
17:52 Lyude: mupuf: btw - I'm very suspicious that the regression we saw in the kms_plane tests is a bug on i915's end, there shouldn't be any issue with using a primary plane fb when we previously weren't using one
17:53 Lyude: i will try to take a look asap, if I get time <<<
17:53 danvet: Lyude, maybe just ask skeggsb_ whether putting them all into drm-misc-fixes is ok?
17:59 mupuf: Lyude: I agree, this is very suspicious, hence why I mentioned it first. However, I sent the revert because I fucked up during the review
17:59 mupuf: We can send a revert of the revert when we know better!
17:59 Lyude: yeah that's fine
18:00 Lyude: hopefully i can get to it soon if work doesn't waste too much of my time
18:03 RSpliet: Lyude: welcome back to the land of the living :-P sorry I and some others started making a lot of noise RE cursor patches. For Fedora, Hans has taken your v2 fix (expose 128x128 on Kepler) into the downstream Fedora kernel because it's broken today and that fixes stuff.
18:03 Lyude: nah it's ok
20:47 karolherbst: nice nice nice :) I think I fixed threading in a way that the android emulator runs nearly without any issues
20:48 karolherbst: ahh..
20:48 karolherbst: crashed it with opening chrome :3
21:00 karolherbst: mhhh.. more data races :/
21:00 karolherbst: this never ends
21:01 karolherbst:cries in threads https://gist.githubusercontent.com/karolherbst/c709c4c54059418b65cf699499489920/raw/926301ef35189d1136988d796f13d948f1b624eb/gistfile1.txt
21:01 karolherbst: not sure why there are even llvmpipe threads
21:04 HdkR: I noticed that when running Zink as well
21:05 karolherbst: HdkR: ehh.. that's vulkan
21:05 karolherbst: /usr/lib64/libvulkan_lvp.so
21:06 HdkR: zink != lavapipe though
21:06 HdkR: Was zink to radv
22:18 karolherbst: okay.. found the next race