12:25karolherbst: imirkin: crash on a NV17 and the user bisected that twice to the drm merge commit :'( https://gitlab.freedesktop.org/drm/nouveau/-/issues/92
14:01pmoreau: imirkin: I’ll see if I can check those tests locally.
14:10HannaM: maybe a stupid question.. but, if I wanted to tinker with the nouveau et al. software, related to my installed graphics hardware .. is there a reasonable amount of risk involved, that I might destroy the hardware?
14:12ajax: not really? depends what you're tinkering with and there's lots that's quite safe
14:13ajax: you might need to reboot a lot, but unless you're like messing with clock speeds and voltages you're unlikely to physically damage anything
14:13HannaM: well, I know many hardware today has protections of all kind and in doubt the system may just shutdown - and I mean not so much stuff like overheating, but rather like "sending comands or writing to registers which damage stuff"
14:14HannaM: i'm not interested in over-clocking or alike, only in maximum 2d/3d acceleration as possible, as it would be under windows
14:14HannaM: well, that's good to hear
14:15HannaM: according to https://nouveau.freedesktop.org/VideoAcceleration.html my old cards might be almost fully supported anyway .. but I will see for myself, when I have time to inspect the related code in mesa, nouveau etc. =D
14:46imirkin: pmoreau: i think i have it worked out...
14:54pmoreau: Cool! Do you still need me to test something?
14:56imirkin: later, probably
14:56imirkin: i haven't uploaded the change yet
14:57imirkin: it's super-dodgy, but wtvr
14:57imirkin: at least i did it without adding a ton of serialize's
15:00pmoreau: Okay, and no hurries as I have plenty on my plate at the moment.
16:40imirkin: pmoreau: fyi - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10867
16:41imirkin: i don't _love_ it, but it seems plausible
16:41imirkin: mwk: btw -- this is the result of our conversation yesterday --^
16:41imirkin: (in case you should want to have a look)
16:41imirkin: (not at all required though)
16:50mwk: imirkin: technically you're using the "no release" mode (low 2 bits == 2) for the "sync" query, which is in theory unordered with the previous write, and it should be 0 to be a semaphore release
16:50mwk: and have proper sync semantics
16:51mwk: you may be avoiding the race because everything on this path is in-order, but I wouldn't rely on that
16:51mwk: 0x5010 instead of 0x5002 sounds like it'd have the proper release behavior, I think
16:54imirkin: mwk: yea, i know, i did that on purpose
16:54imirkin: mwk: the theory being that the same unit produces things sequentially
16:55mwk: perhaps, but that doesn't guarantee that the memory subsystem doesn't reorder actual writes
16:55imirkin: that'd be some pretty intense reordering
16:55mwk: true, but can you guarantee it doesn't happen?
16:55imirkin: i can barely guarantee that i exist
16:56imirkin: anyways, since you tend to be right about such things, i can flip it to 0x10 instead of 0x02
16:56imirkin: and make it more fence-y
16:57imirkin: mwk: btw, experimentally, using unit = crop (aka "all") also worked
16:57imirkin: but i decided to stick to unit = streamout
16:57mwk: wait, weren't you already using a crop fence before?
16:58imirkin: mwk: yes
16:58imirkin: mwk: i.e. this upsets the timing enough to make it all work out :)
16:58imirkin: mwk: i bet i can insert one of those TestForQuadro methods in there too ;)
16:59mwk: yes, and have a code that *only* fails on a Quadro :p
17:04imirkin: mwk: so somehow i had justified it to myself why the unit = 0xf thing worked last night. but i can no longer come up with a plausible explanation