00:36 Manizuca: seems to be a bigger problem than what I thought
00:36 Manizuca: i saw that someone was experimenting with replacing the tegra driver with kmsro
00:36 Manizuca: i wonder if that would be a better idea
00:41 gruetzkopf: xrandr output looks normal
00:41 gruetzkopf: i'll post a photo
00:41 gruetzkopf: https://photos.app.goo.gl/9oy7fQ69z8gPbZCx9
00:42 gruetzkopf: apologies for the potato quality, but i think you can see what i mean
00:46 gruetzkopf: https://paste.ccc.ac/?62683181e19e4962#IrYd2v6GNIP7JI/mtCylw35n6eXRTW+5oz4Aqf34BVc= xrandr in the broken (top) and working case - looks identical to me
02:35 imirkin: gruetzkopf: wow, neat effect. i like it :)
08:53 karolherbst: imirkin: do you think you have a trace with the crysis issue somewhere?
10:29 karolherbst: imirkin: I am wondering if we want to have a debug option where we upload a nop shader in case compilation fails and make every pixel be purple or so
12:58 imirkin: karolherbst: the ASTC decode error color? :)
13:41 karolherbst: anything :D
13:42 karolherbst: the biggest issue I have with crysis right now is, that even though shaders fail to compile, everything looks fine
13:43 karolherbst: the biggest issue I see just is, what if the vertex shader compiles, but the fp not, or vice versa
13:50 imirkin: or what if the fp shader output is integer
13:59 karolherbst: well.. those are things which can be easily checked
13:59 karolherbst: but all the shader linking stuff is more annoying to deal with
13:59 karolherbst: maybe we simply write random data into each output...
14:03 imirkin: gtg
20:17 Lyude: hm, skeggsb - is GF110_DISP_CORE_CHANNEL_DMA mislabeled? It's set to 0x907d, but the 907d version of the core channel was only ever used starting with the GF119
20:21 karolherbst: Lyude: mhh, 0x90 is GF110 though
20:21 karolherbst: Lyude: check drm/nouveau/include/nvif/class.h
20:21 Lyude: huh
20:21 Lyude: strange :s, was hoping to use that to figure out if we're running on GF119+ since we don't want to expose CRC controls for earlier gens
20:23 Lyude: ah well, there's probably another way to do it
20:24 imirkin_: Lyude: yes, the name is weird.
20:24 imirkin_: but this is what nvidia calls it.
20:24 imirkin_: and ben tends to go with the nvidia names
20:26 imirkin_: so all the GF110 stuff is actually GF119
20:26 imirkin_: and the real GF110 has none of it :)
20:26 Lyude: ah, strange
20:26 imirkin_: (and GF117 doesn't have a display unit at all)
20:26 imirkin_: well
20:26 imirkin_: GF100 = nvc0
20:27 imirkin_: GF110 = nvd0
20:27 imirkin_: chip GF110 = nvc8
20:27 imirkin_: ;)
20:27 imirkin_: (GF119 = nvd9)
20:27 imirkin_: all the other ones are nvcx (well, GF117 = nvd7)
20:28 imirkin_: there's madness to the logic
20:28 Lyude: btw, I'm going to add a header into nouveau with the various pretend handles we've come up with for objects that need them (e.g. main vram handle, core ntfy sync handle, wndw dmactx handles, and now CRC handles
20:28 imirkin_: we have that, no?
20:28 imirkin_: maybe not.
20:28 imirkin_: in some nvif or usif header
20:29 Lyude: imirkin_: for that I couldn't find anything (we use plain constants for the handles in disp.c), probably since there's only a few things that need them
20:29 imirkin_: maybe
21:01 imirkin_: karolherbst: this feels slightly sleazy, but feel like running cts-runner yourself with recent mesa and see if you can get it to complete? maybe on kepler vs pascal or soemthing?
21:02 karolherbst: imirkin_: yeah, sure, can do that
21:02 imirkin_: i _really_ can't tell what's wrong on my machine
21:02 pedahzur: Lyude: Need anything from me? Any new code to try?
21:02 imirkin_: either it's some core ctxsw function that's broken
21:02 imirkin_: (but then why same place every time)
21:03 imirkin_: or there's something about the GPU that we don't understand
21:03 imirkin_: coz the error comes like 100 years after the actual address gets used on the GPU
21:04 imirkin_: anyways, i'll do a bit more debugging on my side too
21:04 Lyude: pedahzur: not yet, sorry :(, I've been busy with other rhel stuff but I know that skeggsb and karolherbst are still looking at your issues, they've got some stuff on their plate as well atm
21:04 imirkin_: but it's not the more straightforward logical bugs that i normally tend to solve
21:04 imirkin_: (i.e. code reliably fails, fix it... this is an unreliable failure.)
21:05 imirkin_: (if only failures were more reliable... :) )
21:50 skeggsb: Lyude: yeah, as imirkin said, that's an strange naming oddity... you can see evidence of it in the class headers nv released too
21:50 skeggsb: cl907a.h:} GF110DispCursorControlPio;
21:50 skeggsb: *shrugs*
21:53 imirkin_: skeggsb: did GF119 come out before GF110? no way, i'd imagine...
21:53 imirkin_: i.e. could it be that they named it the GF110 display class before the "other" GF110 chip came out?
21:53 skeggsb: i suspect something like that probably happened, yeah
21:53 imirkin_: first crop was obviously GF100, GF104, GF106, GF108
21:54 imirkin_: or maybe they were going to use it in GF110, but then something happened
21:54 imirkin_: but struct names can't ever be updated, so here we are