01:04LetterRip: imirkin, ok finally got it all upgraded to current 4.20
01:05imirkin: you missed pci=nocrs
01:05imirkin: that's a problem unrelated to nouveau
01:05imirkin: i'd recommend reporting a bug to the pci folk
01:08LetterRip: it gets to the same point as it did when i was using the pci=nocrs but will try it again
01:17LetterRip: imirkin, yeo the nocrs does eliminate the kernel panics, but the ultimate result appears the same - here is the dmesg
01:17LetterRip: will report it
01:19imirkin: the only other thing i can suggest is to try an ancient kernel of sorts, and see if things are better there
01:20imirkin: if they are, try to find where things went wrong
01:20imirkin: older hardware can bitrot a bit
01:20LetterRip: imirkin, ok
01:20imirkin: yet-another thing to try would be to check if it works ok with xf86-video-nv instead of nouveau
01:20imirkin: (which is a userspace driver for nvidia gpu's, Xorg-only)
01:20LetterRip: imirkin, yep, i've tried 4 year old kernels, with similar result
01:20LetterRip: will try nv
01:20imirkin: well - remember the pci=nocrs thing - that's important
01:20LetterRip: imirkin yeppers
01:21LetterRip: being able to ssh in helps a lot
01:21imirkin: yet-another bit might be to see if it works if you plug a secondary screen
01:21LetterRip: yeah will try that
01:21imirkin: since the panel handling is a bit different
01:21LetterRip: thanks for your assistance
01:21LetterRip: and time
01:22imirkin: fwiw i've personally used a NV42 on fairly recent kernels, and it was totally fine
01:22imirkin: (Quadro FX 3450)
01:22imirkin: so it's not like the whole generation is dead
01:22imirkin: but this was a regular desktop board, screen plugged in over dvi
04:00LetterRip: 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:10LetterRip: I'm also passing "video=LVDS-1:1440x900-32@60" to get the missing video mode
04:15imirkin: can you figure out which kernel broke it?
04:15imirkin: 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:15LetterRip: i don't think the kernel broke it, i just hadn't tried unity with this version
04:16LetterRip: it appears that nouveau and MATE (and just tested Cinnamon also) result in a freee
04:16LetterRip: but xfce and unity work
04:17imirkin: oh ok
04:17imirkin: this is with whatever kernel you were using before?
04:18imirkin: in that case, i might recommend updating mesa
04:18LetterRip: (the unity is with 16.04 Ubuntu kernel; xfce is with currentkernel)
04:18imirkin: i fixed a bunch of issues that got introduced recently, you want 19.0
04:18imirkin: or like ... 13.0
04:18LetterRip: i'm using stretch backports
04:18imirkin: but nothing in between ;)
04:18LetterRip: will check which mesa it is
04:20imirkin: also .. pastebin xorg log?
04:27LetterRip: imirkin - works with LXDE also
04:28imirkin: could be that unity & co just don't work with GL 2.1
04:28LetterRip: 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:28imirkin: iirc they require GL rendering to do anything
04:28imirkin: doesn't matter - the xorg log would look the same
04:29imirkin: a bit surprised about MATE - i figured that would work. they only drank the GL kool-aid with gnome3...
04:30HdkR: Got to take advantage of that GPU that everyone has ;)
04:31imirkin: seems like it goes faster if you just do it on the CPU...
04:31imirkin: and certainly a lot less heart-ache
04:31LetterRip: imirkin, here you go - https://pastebin.ubuntu.com/p/DyPWz6rd9g/
04:31imirkin: LetterRip: ok, that's all as expected. good.
04:31LetterRip: hmm i could run blender and see if it freezes up
04:32imirkin: or start with glxgears ;)
04:34LetterRip: blender froze it
04:34LetterRip: will try glxgears
04:43LetterRip: imirkin, pointer to where i can can mesa 19.0 from for debian?
04:44LetterRip: experimental perhaps?
04:46LetterRip: or do i need to build from source
04:47LetterRip: i think i found the guide i needed, nevermind
06:01Hijiri: 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:02imirkin: it does. but it's all manual.
06:03imirkin: i.e. you have to initiate a clock change
06:05Hijiri: I know about setting the clock speed, just wasn't sure if memory was being reclocked too
06:05Hijiri: 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:06imirkin: whatever's on the last line is what's actually set
06:08Hijiri: I guess it's just a really slow operation, or maybe it's CPU-bound
07:02LetterRip: imirkin, upgraded to mesa 19.0rc5 and still the same issues (mouse pointer dirty redraw rectangle is garbage, and crashing in MATE desktop)
07:22pmoreau: 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:23pmoreau: 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:18kale: join #lineage
17:48pmoreau: 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:49karolherbst: pmoreau: revert it and run piglit ;)
17:49karolherbst: some of the double/int64 tests should fail with that
17:50pmoreau: Need to do that on something else than my Tesla laptop then.
17:50pmoreau: I don’t think we expose int64/double on Tesla.
17:50karolherbst: not even int64?
17:51pmoreau: Not that I remember
17:52karolherbst: pmoreau: something in llvm changed :/
17:52karolherbst: getting "void SPIRV::OCL20ToSPIRV::transWorkItemBuiltinsToVariables(): Assertion `CI && "invalid instruction"' failed."
17:52pmoreau: I was thinking it might be my patch, but it doesn’t look like it. \o/
17:53karolherbst: I propably need ee5cc7bdefa0f96ee4d9a6d65f6c989f7b7fa980
17:53pmoreau: But kinda annoying still :-/
17:53karolherbst: uff, that only changes a test
17:54karolherbst: maybe rebuilding helped
17:54karolherbst: pmoreau: well, I will run piglit then, should be faster anyway
17:57pmoreau: 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:58karolherbst: the 191 one?
18:00karolherbst: "Series looks good, feel free to merge!" always a good sign
18:01karolherbst: pmoreau: can you push your branch with the added acks and r-bys?
18:02pmoreau: 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:02karolherbst: can't we just disable those warnings?
18:03pmoreau: 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:04karolherbst: we can't use 1.1
18:04karolherbst: anyway, that's a stupid thing to set for drivers anyway
18:05karolherbst: what should the compiler warn about?
18:05karolherbst: that we implement/use some 1.0 function?
18:05karolherbst: or that we don't use newer functions?
18:05pmoreau: Gotta deprecate stuff you know, planned obsolescence! :-D
18:06karolherbst: I mean for an application it makes sense
18:06karolherbst: but not for a driver
18:06karolherbst: let me see
18:08karolherbst: pmoreau: I think there was something nice we can do.. let me see
18:08pmoreau: Fall back to an earlier version of the header files? O;-)
18:09karolherbst: mhh, specify 220 and define all CL_USE_DEPRECATED_OPENCL_1_0_APIS... thingies?
18:13pmoreau: We already define the CL_USE_DEPRECATED_* for 1.0 through 2.0 (I should probably define for 2.1 as well).
18:14karolherbst: in the end we want to implement 2.2 ;)
18:14pmoreau: I’ll add that and the definition of the TARGET thing to 220, add all the tags and push that to the MR.
18:14pmoreau: Let’s go straight to Next! :-D
18:29karolherbst: pmoreau: allthough we could probably merge the nir stuff without that RA fix, but stuff may just randomly fail
18:37pmoreau: 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:58karolherbst: pmoreau: mhh, just noticed that there are some new piglit regressions ...
19:14karolherbst: mhh, texlod stuff
19:24karolherbst: mhh, I don't add that 0 source
19:34karolherbst: 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:36karolherbst: ohh wait, no, we have that levelzero flag
19:36karolherbst: so scalar tex stuff is fine
19:36karolherbst: just wondering when we start requiring having a 0 source there
19:39karolherbst: setting levelZero fixes it :)