01:04 LetterRip: imirkin, ok finally got it all upgraded to current 4.20
01:04 LetterRip: https://pastebin.ubuntu.com/p/msQRdQZ4rF/
01:05 imirkin: you missed pci=nocrs
01:05 imirkin: that's a problem unrelated to nouveau
01:05 imirkin: i'd recommend reporting a bug to the pci folk
01:07 LetterRip: oops
01:08 LetterRip: it gets to the same point as it did when i was using the pci=nocrs but will try it again
01:17 LetterRip: imirkin, yeo the nocrs does eliminate the kernel panics, but the ultimate result appears the same - here is the dmesg
01:17 LetterRip: https://pastebin.ubuntu.com/p/xYdxdhCBzP/
01:17 LetterRip: yep
01:17 LetterRip: will report it
01:19 imirkin: the only other thing i can suggest is to try an ancient kernel of sorts, and see if things are better there
01:20 imirkin: if they are, try to find where things went wrong
01:20 imirkin: older hardware can bitrot a bit
01:20 LetterRip: imirkin, ok
01:20 imirkin: yet-another thing to try would be to check if it works ok with xf86-video-nv instead of nouveau
01:20 imirkin: (which is a userspace driver for nvidia gpu's, Xorg-only)
01:20 LetterRip: imirkin, yep, i've tried 4 year old kernels, with similar result
01:20 LetterRip: will try nv
01:20 imirkin: well - remember the pci=nocrs thing - that's important
01:20 LetterRip: imirkin yeppers
01:21 LetterRip: being able to ssh in helps a lot
01:21 imirkin: yet-another bit might be to see if it works if you plug a secondary screen
01:21 LetterRip: yeah will try that
01:21 imirkin: since the panel handling is a bit different
01:21 LetterRip: thanks for your assistance
01:21 LetterRip: and time
01:22 imirkin: fwiw i've personally used a NV42 on fairly recent kernels, and it was totally fine
01:22 imirkin: (Quadro FX 3450)
01:22 LetterRip: ok
01:22 imirkin: so it's not like the whole generation is dead
01:22 imirkin: but this was a regular desktop board, screen plugged in over dvi
01:22 LetterRip: ok
04:00 LetterRip: imirkin, i tried 16.04 linux and it worked with unity; switching to xfce in 19.1 and it works (though the mouse pointer is glitched) - so it appears to be a bug related to nouvea interaction with one of the widgets of mate desktop
04:10 LetterRip: I'm also passing "video=LVDS-1:1440x900-32@60" to get the missing video mode
04:15 imirkin: cool
04:15 imirkin: can you figure out which kernel broke it?
04:15 imirkin: i'm surprised you need the video= bit -- we pull the mode from the VBIOS, and it should be working fine according to the prints
04:15 LetterRip: i don't think the kernel broke it, i just hadn't tried unity with this version
04:16 LetterRip: it appears that nouveau and MATE (and just tested Cinnamon also) result in a freee
04:16 LetterRip: freeze
04:16 LetterRip: but xfce and unity work
04:17 imirkin: oh ok
04:17 imirkin: this is with whatever kernel you were using before?
04:17 LetterRip: yep
04:18 imirkin: in that case, i might recommend updating mesa
04:18 LetterRip: (the unity is with 16.04 Ubuntu kernel; xfce is with currentkernel)
04:18 LetterRip: ok
04:18 imirkin: i fixed a bunch of issues that got introduced recently, you want 19.0
04:18 imirkin: or like ... 13.0
04:18 LetterRip: i'm using stretch backports
04:18 imirkin: but nothing in between ;)
04:18 LetterRip: ok
04:18 LetterRip: will check which mesa it is
04:20 imirkin: also .. pastebin xorg log?
04:21 LetterRip: sure
04:27 LetterRip: imirkin - works with LXDE also
04:28 imirkin: could be that unity & co just don't work with GL 2.1
04:28 LetterRip: imirkin, do you want xorg log for a session with LXDE, xfce, or mate? (ie a working session and a broken one or just the one that freezes)
04:28 imirkin: iirc they require GL rendering to do anything
04:28 imirkin: doesn't matter - the xorg log would look the same
04:28 LetterRip: ok
04:29 imirkin: a bit surprised about MATE - i figured that would work. they only drank the GL kool-aid with gnome3...
04:30 HdkR: Got to take advantage of that GPU that everyone has ;)
04:31 imirkin: seems like it goes faster if you just do it on the CPU...
04:31 imirkin: and certainly a lot less heart-ache
04:31 LetterRip: imirkin, here you go - https://pastebin.ubuntu.com/p/DyPWz6rd9g/
04:31 imirkin: LetterRip: ok, that's all as expected. good.
04:31 LetterRip: hmm i could run blender and see if it freezes up
04:32 imirkin: or start with glxgears ;)
04:34 LetterRip: blender froze it
04:34 LetterRip: will try glxgears
04:43 LetterRip: imirkin, pointer to where i can can mesa 19.0 from for debian?
04:44 LetterRip: experimental perhaps?
04:46 LetterRip: or do i need to build from source
04:47 LetterRip: i think i found the guide i needed, nevermind
06:01 Hijiri: I forget, does current reclocking support include memory reclocking? Asking since I get lag in Minecraft when I do things that I think is causing the game to update meshes
06:02 imirkin: it does. but it's all manual.
06:03 imirkin: i.e. you have to initiate a clock change
06:05 Hijiri: thanks
06:05 Hijiri: I know about setting the clock speed, just wasn't sure if memory was being reclocked too
06:05 Hijiri: when I read the clock state it shows memory as having a faster clock speed than normal, but I just wanted to be sure
06:06 imirkin: whatever's on the last line is what's actually set
06:08 Hijiri: I guess it's just a really slow operation, or maybe it's CPU-bound
07:02 LetterRip: imirkin, upgraded to mesa 19.0rc5 and still the same issues (mouse pointer dirty redraw rectangle is garbage, and crashing in MATE desktop)
07:22 pmoreau: imirkin: Thanks for the headsup (re: disabling compute support on Tesla). I had started looking into images support around FOSDEM last year, but didn’t made much progress IIRC.
07:23 pmoreau: I plan on looking back into it once the different clover series are merged and once I have time to look into it, so not before April most likely.
17:18 kale: join #lineage
17:48 pmoreau: karolherbst: Do you have some code that easily triggers the compound bug, that is fixed by “nv50/ir/ra: Fix copying compound for moves”? I have been trying different things, via GLSL->TGSI/GLSL->NIR/OpenCL C->NIR, but I have been able to get a test case reproducing it. :-/
17:49 karolherbst: pmoreau: revert it and run piglit ;)
17:49 karolherbst: some of the double/int64 tests should fail with that
17:50 pmoreau: Need to do that on something else than my Tesla laptop then.
17:50 karolherbst: why?
17:50 pmoreau: I don’t think we expose int64/double on Tesla.
17:50 karolherbst: not even int64?
17:51 pmoreau: Not that I remember
17:52 karolherbst: ufff
17:52 karolherbst: pmoreau: something in llvm changed :/
17:52 karolherbst: getting "void SPIRV::OCL20ToSPIRV::transWorkItemBuiltinsToVariables(): Assertion `CI && "invalid instruction"' failed."
17:52 pmoreau: I was thinking it might be my patch, but it doesn’t look like it. \o/
17:53 karolherbst: I propably need ee5cc7bdefa0f96ee4d9a6d65f6c989f7b7fa980
17:53 pmoreau: But kinda annoying still :-/
17:53 karolherbst: uff, that only changes a test
17:54 karolherbst: mhh
17:54 karolherbst: maybe rebuilding helped
17:54 karolherbst: pmoreau: well, I will run piglit then, should be faster anyway
17:55 pmoreau: Thanks
17:57 pmoreau: karolherbst: Ready to merge the first clover series, except I didn’t get an answer regarding the warning. :-D Hopefully curro will answer quickly on that one.
17:58 karolherbst: the 191 one?
18:00 karolherbst: "Series looks good, feel free to merge!" always a good sign
18:01 karolherbst: pmoreau: can you push your branch with the added acks and r-bys?
18:02 pmoreau: Yep; I will add the tags to the commits, but I would like to have an answer regarding the warning, before pushing something that is going to generate additional warnings when building clover.
18:02 karolherbst: can't we just disable those warnings?
18:03 pmoreau: We can, by setting the define to some value. The question is which one: we could go for 1.1 as this is the version supported, or the max like we do for ICD and headers (though 1.1 is maybe a better idea).
18:04 karolherbst: we can't use 1.1
18:04 karolherbst: anyway, that's a stupid thing to set for drivers anyway
18:05 karolherbst: what should the compiler warn about?
18:05 karolherbst: that we implement/use some 1.0 function?
18:05 karolherbst: or that we don't use newer functions?
18:05 pmoreau: Gotta deprecate stuff you know, planned obsolescence! :-D
18:06 karolherbst: I mean for an application it makes sense
18:06 karolherbst: but not for a driver
18:06 karolherbst: let me see
18:08 karolherbst: pmoreau: I think there was something nice we can do.. let me see
18:08 pmoreau: Fall back to an earlier version of the header files? O;-)
18:09 karolherbst: mhh, specify 220 and define all CL_USE_DEPRECATED_OPENCL_1_0_APIS... thingies?
18:13 pmoreau: We already define the CL_USE_DEPRECATED_* for 1.0 through 2.0 (I should probably define for 2.1 as well).
18:13 karolherbst: yeah
18:14 karolherbst: in the end we want to implement 2.2 ;)
18:14 pmoreau: I’ll add that and the definition of the TARGET thing to 220, add all the tags and push that to the MR.
18:14 pmoreau: Let’s go straight to Next! :-D
18:29 karolherbst: pmoreau: allthough we could probably merge the nir stuff without that RA fix, but stuff may just randomly fail
18:37 pmoreau: karolherbst: It could be merged but not enabled, though that is not going to be helping that much. Except regarding the number of patches to rebase and such.
18:58 karolherbst: pmoreau: mhh, just noticed that there are some new piglit regressions ...
19:14 karolherbst: mhh, texlod stuff
19:24 karolherbst: mhh, I don't add that 0 source
19:34 karolherbst: imirkin: when does a TXF end up with a lod source? also I think we mess that up with the scalar tex instructions as well
19:36 karolherbst: ohh wait, no, we have that levelzero flag
19:36 karolherbst: so scalar tex stuff is fine
19:36 karolherbst: just wondering when we start requiring having a 0 source there
19:39 karolherbst: setting levelZero fixes it :)