06:40 fling: Ok guys it does not crash anymore, not a single crash for many days already after I switched from xv to x11 in mpv.
06:40 fling: No hangs, no issues at all.
06:42 fling: Does this mean the bug is in nva3 code?
06:43 fling: Would not xv cause issues with ddr3 version of this gt 240 ?
06:55 gnarface: couldn't it be a bug in the xv code too though?
06:55 gnarface: i'm not sure there's only one suspect
06:55 gnarface: sometimes there's more than one at the same time even
08:21 RSpliet: fling: the vast majority of all nva3/5/8 are DDR3. There's no reason to assume yours is special in any way. Probably an xv or "core nouveau" bug
08:32 fling: RSpliet: what is core nouveau?
08:33 RSpliet: not a thing
08:33 RSpliet: but a word that I just made up that I hoped would describe the memory management/command buffer management/... shared code
08:34 fling: It is running on 5.4
08:34 fling: Should I use 5.8 ?
08:37 RSpliet: It's defo worth a try. Somehow I'm sceptical that if this is a kernel issue, it's now fixed though
09:04 fling: RSpliet: or I can just keep using x11 right?
09:04 fling: I'm just thinking what if this bug or whatever could cause an unexpected crash in something else
09:05 fling: What apps to try if I want to debug this?
09:26 gnarface: fling: you can just keep using x11
09:27 gnarface: fling: the only thing you could really lose is performance, but probably not enough to matter on modern hardware unless you're trying to get 4k video working or something
09:28 gnarface: fling: though, if it has a "sdl" option like mplayer, you should benchmark that too as a comparison
09:28 gnarface: (sometimes sdl is like magic)
09:42 fling: gnarface: ok, I will check sdl with 5.4, then both sdl and xv with 5.8
09:42 fling: gnarface: what I'm talking about I don't want nouveau to crash when I'm not expecting me, I don't want a surprise ;P
09:42 fling: So I thought maybe I could use other apps for checking if they are causing crashes or not
18:35 Lyude: karolherbst: btw, you were right - we do actually use the CE in mesa sometimes, but we still call it m2mf
18:36 imirkin: on kepler+ though? i think...
18:36 Lyude: imirkin: yeah
18:36 imirkin: so there it's the "standard" interface iirc
18:36 imirkin: the firmware is only for fermi iirc
18:37 Lyude: mhm, now I need to just figure out what I'm doing wrong in igt that is making it so that I can only seem to get the CE to copy a single line even when blitting from one linear bo to another
18:37 imirkin: uhm
18:37 imirkin: yeah, you screwed something up
18:37 Lyude: imirkin: yeah obv :P
18:37 imirkin: CE should totally work
18:37 imirkin: can i see your code?
18:38 Lyude: imirkin: yeah sure thing, gimme one second
18:38 imirkin: (if you're interested in some assistance)
18:38 imirkin: can just be a snippet
18:38 Lyude: of course, I have a feeling it's something very silly. I also noticed that the way mesa uses the CE is different from xf86-video-nouveau, which makes me suspect things might work if I follow mesa more closely instead since they seem to omit some methods when doing linear bits
18:38 imirkin: since you've done something obvious wrong. like left out a stride.
18:39 Lyude: imirkin: nah i can just post the github repo :P, I'm not shy
18:39 Lyude: always easier to fix obvious problems with another pair of eyes anyway
18:39 imirkin: and yeah. there was a time when i think skeggsb updated the mesa logic to work more properly based on some RE
18:39 imirkin: and chances are the ddx was never updated
18:42 imirkin: Lyude: also note that the ddx tends to deal with somewhat different constraints -- the types of buffers it sees are generally untiled, etc
18:43 imirkin: Lyude: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_transfer.c#n109
18:43 imirkin: that's the logic to copy from :)
18:43 Lyude: imirkin: yeah that's what I started looking at last night
18:43 Lyude: https://gitlab.freedesktop.org/lyudess/igt-gpu-tools/-/tree/wip/nouveau-evo-plane-v1
18:44 imirkin: where's the file i'm looking for?
18:45 imirkin: oh i see
18:45 Lyude: a bunch of the stride calculation for tiled buffers is probably wrong (still feel free to point out obvious mistakes with it) but luckily none of that should matter for just a basic linear to linear blit (and once i've got that going I can start figuring out tiling)
18:45 Lyude: imirkin: lib/nouveau/* and lib/igt_nouveau.h
18:45 imirkin: yeah
18:45 imirkin: that won't work
18:45 imirkin: you're missing the else's on the if (memtype)
18:46 imirkin: oh i see, you do it unconditionally later
18:47 imirkin: Lyude: int src_pitch = src_fb->strides[plane]; -- what is this?
18:47 imirkin: pixels or bytes?
18:47 imirkin: it needs to be bytes.
18:47 karolherbst: Lyude: yep :p
18:47 Lyude: imirkin: it should be bytes iirc
18:47 karolherbst: right now I hit this with CL images :D
18:48 Lyude: well, PITCH_IN/PITCH_OUT probably aren't if that's what you meant
18:49 imirkin: Lyude: could you hvea a height > 2048?
18:49 Lyude: imirkin: my biggest suspicion is either that, or that we might want to omit PITCH_IN, PITCH_OUT, and LINE_COUNT
18:50 Lyude: imirkin: not yet - I did notice that bit though
18:50 imirkin: you want all 3 of those.
18:50 Lyude: this is just with 1080p
18:50 imirkin: with linear
18:50 imirkin: with memtype you actually don't want pitch in/out, always want line count
18:50 Lyude: imirkin: they don't seem to be set in nve4_m2mf_copy_linear() though?
18:50 imirkin: } else {
18:50 imirkin: src_ofst += src->y * src->pitch + src->x * cpp;
18:50 imirkin: BEGIN_NVC0(push, NVC0_M2MF(PITCH_IN), 1);
18:50 imirkin: PUSH_DATA (push, src->width * cpp);
18:50 imirkin: oh
18:50 imirkin: copy_linear
18:50 imirkin: you don't want that.
18:51 imirkin: that's 1d copy
18:51 Lyude: ...that explains some things :)
18:51 imirkin: nve4_m2mf_transfer_rect
18:51 imirkin: wait
18:51 imirkin: f me
18:51 imirkin: i was looking at the nvc0 variant
18:51 Lyude: hehe, yeah I kept making that mistake too
18:51 imirkin: you still want the in/out pitch
18:51 imirkin: they're just set at the bottom
18:52 imirkin: unconditionally
18:52 imirkin: so you're good.
18:52 Lyude: also btw - there's a small test called nouveau_copy.c there that tries exercising blitting and shows you the cvisual output
18:52 imirkin: either way, you want nve4_m2mf_transfer_rect - that should work.
18:53 karolherbst: ehhh
18:53 karolherbst: "nouveau 0000:01:00.0: ce0: LAUNCHERR 00000003 [MEM2MEM_RECT_OUT_OF_BOUNDS]"
18:53 karolherbst: :/
18:53 Lyude: imirkin: so to be clear, we do still want LINE_COUNT?
18:53 Lyude: karolherbst: is that with my test?
18:53 Lyude: I stopped getting that error a little while ago
18:53 imirkin: Lyude: nblocksy
18:53 karolherbst: no, that's CL 1D_ARRAY copyimage
18:54 Lyude: ahh
18:54 karolherbst: I now even only copy index 0 and ignore the others...
18:54 karolherbst: something is sifhy
18:54 karolherbst: *fishy
18:56 karolherbst: imirkin: does anything look strange here? https://gist.github.com/karolherbst/a029b8c9fde751a31bac7942328e1388
18:56 imirkin: what am i looking for?
18:56 karolherbst: something that would explain the MEM2MEM_RECT_OUT_OF_BOUNDS
18:56 imirkin: heh
18:56 karolherbst: ohh
18:56 karolherbst: "0x00000030 [4] GP104_COPY.Y_COUNT = 0x30" mhh
18:57 karolherbst: that's probably wrong
18:57 imirkin: yeah, esp when DST_SIZE_Y is 0x1
18:57 karolherbst: yeah
18:57 karolherbst: okay, cool
18:57 imirkin: one might go so far as to say that that's OUT OF BOUNDS!
18:57 karolherbst: another thing to follow up on then :)
18:57 karolherbst: :D
18:57 Lyude: imirkin: and nblocksy should just be the height of the image (for linear) in this case, right?
18:57 karolherbst: hopefully nouveau doesn't mess up again
18:57 imirkin: Lyude: yes. the blocks stuff is for compressed formats
18:58 imirkin: e.g. you might have 4x4 blocks which are represented as a single "pixel"
18:58 imirkin: but have a logical 4x4 height
18:58 imirkin: so there's a terminology about "blocks" which is the "physical" height/width
18:58 imirkin: while the actual width/height values are the logical ones used for texturing/etc
18:59 imirkin: but for non-compressed formats, blocks == pixels
18:59 Lyude: imirkin: alright, yeah I knew a good bit of the tiling stuff already (I read through the tegra X1 docs on it and the XDC presentation, although I'm still unsure if I fully understood how to calculate stuff like pitch/stride for tiled formats
19:00 imirkin: blocks have nothing to do with tiling
19:00 imirkin: at least not the "nblocks" stuff
19:00 Lyude: oh, huh
19:00 imirkin: it has to do with compressed formats, like s3tc/etc
19:02 imirkin: unrelatedly, tiling happens in blocks
19:02 imirkin: which have a configurable width
19:02 imirkin: (well, they're square)
19:03 imirkin: but that's not what this nblocks stuff is about
19:03 Lyude: that's helpful to know
19:03 imirkin: other than the initial texture parameter setup
19:03 imirkin: you don't have to give a shit about these parameters. they're computed once, and they are correct, and you just stick them in when asked.
19:04 imirkin: you never* have to do "math" on the tiles
19:04 imirkin: * sometimes you do
19:04 imirkin: ;)
19:05 Lyude: imirkin: btw, most of the tiling calculation stuff I've added is in igt_fb.c, which would show you the bits i'm pretty unsure on
19:06 Lyude: particularly calc_plane_stride() and calc_plane_size()
19:06 imirkin: where is igt_fb?
19:07 imirkin: did you mean igt_nouveau?
19:07 Lyude: imirkin: no, lib/igt_fb.c and lib/igt_fb.h
19:08 Lyude: imirkin: also wasn't too clear on this before, you said you were looking at the wrong code earlier - does that means nve4_m2mf_copy_linear is still primarily just intended for 1d images?
19:08 imirkin: copy_linear is still not what you want
19:08 imirkin: you want the rect one
19:08 imirkin: if you want to copy rects
19:08 Lyude: gotcha
19:08 imirkin: make sure you look at the nve4 variant of it
19:08 imirkin: not the nvc0 variant
19:09 Lyude: yep :)
19:09 imirkin: the ABI's are slightly different due to an unforced error
19:09 Lyude: yeah, i remember ben mentioning that (if I get really bored someday I might try to fix the firmware so we follow nvidia's dma-copy interface. but i'll have to be really bored)
19:10 karolherbst: using multiple CE engines would be a fun project...
19:10 imirkin: the "other" ones are used for async movement of buffers by ttm
19:13 karolherbst: really?
19:13 karolherbst: I mean, having two CEs is quite new
19:13 karolherbst: or well.. 8
19:13 imirkin: since fermi, i think
19:13 imirkin: yeah, recently they've added a ton
19:13 imirkin: used to be 2 or 3
19:13 karolherbst: indeed GF100 has two
19:14 karolherbst: and GF104
19:14 karolherbst: but there are fermis with just 1
19:14 karolherbst: but yeah..
19:14 karolherbst: It would be fun if we could make more use of them I guess?
19:14 karolherbst: or maybe you can't do anything with them from userspace?
19:14 imirkin: the ones that waste the second engine on the compression thing?
19:15 karolherbst: no clue
19:15 karolherbst: my thinking is like this: I see many, I think: we can do something with those
19:15 karolherbst: :p
19:16 imirkin: yeah
19:16 imirkin: esp with the new boards with tons of them
19:16 Lyude: ok, so (assuming w is pixels) PITCH_IN/PITCH_OUT should be ((src|dst)->w * (src|dst)->cpp), OFFSET_OUT_LOW/HIGH should be fine, LINE_LENGTH_IN should be (src->w * src->cpp) again, LINE_COUNT should be (line_count) where line_count is the remaining height limited to 2047 lines per CE invocation
19:16 Lyude: if i understand all of this code right
19:16 Lyude: (not paying attention to x/y offsets here yet)
19:17 imirkin: Lyude: yeah
19:18 imirkin: where is the push buffer set up?
19:18 imirkin: Lyude: btw, you're not enabling some args
19:18 imirkin: exec = NVE4_COPY_EXEC_SWIZZLE_ENABLE | NVE4_COPY_EXEC_2D_ENABLE | NVE4_COPY_EXEC_FLUSH | NVE4_COPY_EXEC_COPY_MODE_NON_PIPELINED;
19:18 imirkin: i'm guessing that 2D_ENABLE is somewhat important
19:18 imirkin: and could be relevant to you only seeing 1 line copied
19:18 Lyude: imirkin: lib/igt_nouveau.c, init_ce()
19:19 imirkin: Lyude: also, the swizzle thing could matter.
19:19 Lyude: imirkin: yeah I thought that might be related as well. also, wait
19:19 Lyude: 2D_ENABLE
19:20 Lyude:face palm
19:20 Lyude: cannot believe it didn't occur to me until just now what that might refer to
19:20 imirkin: hehehe
19:20 imirkin: could really refer to anything
19:20 imirkin: so many options
19:20 Lyude: I thijnk it might be called something different in nvidia's headers
19:20 imirkin: probably
19:20 imirkin: GIVE_A_SHIT_ABOUT_LINE_COUNT
19:21 Lyude: wait, I've got 2D_ENABLE already (2D_ENABLE == NVA0B5_LAUNCH_DMA_MULTI_LINE_ENABLE
19:22 Lyude: so yes that's also a very accurate descriptor lol
19:22 imirkin: where do you have it?
19:22 Lyude: ...oh, I deleted it by accident??
19:22 Lyude: i had it at one point I remember
19:23 Lyude:adds it back
19:23 Lyude: should have been on the top uint32_t dma_args assignment
19:23 imirkin: should.
19:23 imirkin: dunno how generic this needs to be
19:23 imirkin: but you might also need to end up swizzling stuff
19:23 imirkin: if you want e.g. BGRA <-> RGBA to work
19:23 Lyude: imirkin: that-also explains some other things
19:24 imirkin: also, for memtype you need push_space += 7
19:25 imirkin: (1 for the header)
19:32 joey: cls
19:36 Lyude: imirkin: also, for a compressed format I'm assuming that nblocksx would be ((w / 4) * cpp)?
19:37 imirkin: well, not necessarily / 4, but yes.
19:37 imirkin: er
19:37 imirkin: not *cpp
19:37 imirkin: just w / blockwidthx
19:37 imirkin: (not all compressed formats are 4x4)
19:37 Lyude: gotcha, so I'll have to teach igt how to get the block width from the modifier
19:37 imirkin: e.g. FXT1 is 8x4. and ASTC has tons of options.
19:37 imirkin: but note that compressed formats are never displayable directly
19:38 imirkin: at least i'm not aware of any hw which would allow this
19:38 Lyude: ahh, so I don't even really need to care about the block size then for this?
19:38 imirkin: no
19:39 imirkin: i was just explaining what this stuff meant in the mesa code
19:39 Lyude: ahhh, gotcha
19:39 imirkin: which does have to worry about these things
19:45 joey: btw imirkin, karol, got it working. had to enable a sh*tload of framebuffers liek simplefb, efi fb, vesafb, in hte end, got my console on nouveau lol.. next up, is compiling x and nouveau from source or wayland and nouveau...
19:46 imirkin: joey: if it's a semi-modern system, just needed efifb
19:46 joey: nah, i dual boot like 4 OS and grub gets in the way
19:46 imirkin: quad-boot then?
19:46 joey: yus :D
19:47 joey: lol
19:47 joey: arch, ubuntu, lfs and win10
19:48 joey: want to run insder build on win10 so i can mount zfs and ext4..
19:48 joey: but linux keeps me busy engough...
19:48 Lyude: a-ha!
19:49 Lyude: now that's what I called a successful blit volume 22
19:49 Lyude: *call
19:49 imirkin: success?
19:50 Lyude: imirkin: with linear yeah, so tiled shouldn't be too hard to make working (can't spent much more time on this today unfortunately, so it'll have to wait for another day)
19:50 imirkin: Lyude: yay!
19:50 joey: only use win10 for audio software (ableton), for the rest got X running with my linux tools in wsl lol
19:50 imirkin: Lyude: iirc display capabilities of tiled surfaces are fairly limited
19:50 Lyude: imirkin: sweet, means less code for me to write :)
19:51 imirkin: (like, not sure you can display tiled surfaces at all... that's pretty limited.)
19:51 imirkin: been a while since i've looked at it
19:51 Lyude: imirkin: I'd think you can? iirc I remember james jones added some code to kms cube for this, so I'd be surprised if you couldn't
19:51 imirkin: ok
19:51 imirkin: i thought it was around buffer import/etc
19:52 Lyude: imirkin: yeah, there -are- definitely some variants of nv's tiling format that don't work on bos
19:52 Lyude: but I think that starts when you have stuff like a depth > 1?
19:52 imirkin: oh, with z-tiling?
19:52 Lyude: sorry, *fbs, not bos
19:52 Lyude: imirkin: yeah
19:52 imirkin: so yeah, that definitely won't work :)
20:17 Agent-Theta: hello again, im still having problems with a "regular" linux kernal/os (KDE Neon), i'm not having the problem with microcode, but i think i don't have the latest versions
20:18 Agent-Theta: i have a 2070 (non-super) and the xorg logs are saying Unknow chipset: NV166 (at least it identified it correctly)
20:18 imirkin: nouveau's currently doing nothing for you
20:18 imirkin: any issues you're having aren't related to nouveau
20:19 imirkin: since it's effectively not being loaded
20:19 Agent-Theta: huh
20:19 imirkin: (it's being loaded, and doesn't support your chipset, and bails)
20:19 karolherbst: well.. we have acceleration, but that requires a newer mesa and maybe even patched nouveau ddx
20:19 imirkin: and a newer kernel apparently
20:19 karolherbst: imirkin: but that's X?
20:19 imirkin: if it's saying unknown chipset :)
20:20 imirkin: oh
20:20 imirkin: i thought that was kernel. my bad.
20:20 imirkin: Agent-Theta: pastebin xorg log
20:20 karolherbst: yeah.. not sure if the nouveau ddx is wired up yet, but probably not
20:20 imirkin: for volta+? definitely not.
20:20 karolherbst: using modesetting should help with a new enough mesa
20:20 Agent-Theta: let me pastebin it
20:20 imirkin: i don't have such a gpu, and i'm the only one who cares about people having a stable Xorg experience apparently
20:20 karolherbst: but I am pestering skeggsb about the common issue everybody is seeing and apparently it will take a while to fix it :/
20:21 karolherbst: imirkin: well, I do as well, but fixing the most common issue is quite hard
20:21 Agent-Theta: https://pastebin.com/QNABaTpq
20:22 karolherbst: heh
20:22 karolherbst: looks fine
20:22 karolherbst: even glamor loads
20:22 karolherbst: that's a good sign
20:22 imirkin: Agent-Theta: don't worry about the Unknown chipset lines in there
20:22 karolherbst: ehh wait
20:22 karolherbst: no
20:22 karolherbst: it detects llvmpipe
20:23 karolherbst: Agent-Theta: what version of mesa are you using?
20:23 Agent-Theta: how do i find that? pacakge manager?
20:23 karolherbst: uhh I guess?
20:24 karolherbst: yeah.. I think you need mesa 20.2
20:24 karolherbst: Agent-Theta: glxinfo might be quicker
20:25 Agent-Theta: 20.0.8, that would be an issue
20:25 karolherbst: yep
20:25 karolherbst: need a newer one
20:26 karolherbst: we should add a chipset, mesa version matrix to our wiki...
20:27 Agent-Theta: the reson i could not tell for sure it was versions, is even though it says there are versions on the front page, there is not, and the git links arn't that helpful for that, just FYI
20:28 karolherbst: yeah..
20:28 karolherbst: the wiki needs work :/
20:28 karolherbst: at least, everybody can contribute now
21:25 Lyude: jfyi - confirmation on nvidia you can't scan out from compressed pages. -but-
21:26 Lyude: there is a method on one of the engines that you can use to tell the hardware to flush out a compressed surface to ram for display
21:26 HdkR: Woo copy engines that can saturate vram :)
21:27 imirkin: Lyude: that's in reference to msaa-type compression, i think
21:27 imirkin: not like compressed texture formats
21:28 Lyude: imirkin: i don't think so, james jones seemed to imply it could be used in like our eglSwapBuffers() equivalent for compositors
21:28 Lyude: (so it probably wouldn't be on IGT's level anyway)
21:29 Lyude: also apparently they did try to support this around the ~nv50 hardware in disp but it was broken and they didn't bother ever fixing it
21:32 HdkR: ooo
21:32 HdkR: Maybe one day it'll be supported
21:32 HdkR: Give it another decade :)
21:32 imirkin: Lyude: yes
21:33 Lyude: HdkR: nah, sooner then that. iirc james jones has patches pending for it
21:33 HdkR: Oh cool
21:33 imirkin: Lyude: my point is that it has nothing to do with e.g. s3tc compressed texture formats
21:33 Lyude: on mesa
21:33 Lyude: imirkin: ahhh
21:33 Lyude: gotcha
21:33 imirkin: it's a different "type" of compression
21:36 HdkR: The FB compression is significantly different since it's only for bandwidth savings, not memory savings :)
22:05 karolherbst: ahhh
22:05 karolherbst: imirkin: pipe_transfer is busted as well :)
22:05 imirkin: huh?
22:05 karolherbst: sets nblocksy for arrays
22:06 imirkin: oh, in clover?
22:06 karolherbst: yeah
22:06 imirkin: yeah, that's a common issue with 1d array support
22:11 karolherbst: nice, the crash is gone :)
22:11 karolherbst: now I just get test fails
22:12 imirkin: almost done
22:12 karolherbst: maybe 2darrays are easier to fix...
22:12 imirkin: should be straightforward
22:12 karolherbst: yeah.. I hope
22:12 karolherbst: just.. "Failed at column: 0 *0xc0 vs. 0x7e"
22:12 karolherbst: :/
22:13 imirkin: could be some clamping thing
22:13 karolherbst: 1D, 2D, 3D tests are passing though
22:18 karolherbst: heh
22:18 karolherbst: clFill tests are throwing "gr: GPC0/PROP trap: 00000020 [RT_HEIGHT_OVERRUN] x = 8, y = 4, format = 3a, storage type = 0"
22:19 karolherbst: ohh.. same problem :/
22:25 imirkin: still sending some parameters wrong
22:25 karolherbst: other API functions
22:25 imirkin: yeah
22:26 imirkin: this is the RT-based stuff.
22:26 imirkin: i.e. actual rendering
22:26 imirkin: sounds like the fb's values are wrong
22:26 imirkin: iirc there are values in the pipe_framebuffer which are new
22:26 imirkin: we don't just go on what's in the surface
22:26 imirkin: (this is to support no-framebuffer rendering)
22:29 karolherbst: okay.. now the errors are gone, but still wrong results :)
22:29 imirkin: multiple bugs in a single piece of code?
22:29 imirkin: inconceivable!
22:33 unlord: hi
22:33 unlord: I'm running the proprietary nvidia drivers (sorry) and my computer won't boot now
22:33 unlord: http://dgql.org/~unlord/dmesg.txt
22:34 imirkin: thank you for choosing nvidia
22:34 imirkin: we appreciate you have a choice in gpu vendors, and you apparently have made the wrong one :)
22:34 karolherbst: lol...
22:34 karolherbst: unlord: well, we don't give support for the nvidia driver here
22:35 karolherbst: have to bother nvidia with that
22:35 karolherbst: also, we wouldn't be able to help anyway
22:35 imirkin: unlord: it apparently hates your acpi too
22:35 unlord: imirkin: this machine was working fine for 80 some days, and then the power went out
22:36 karolherbst: maybe corruption on the disc?
22:36 karolherbst: maybe reinstalling nvidia would help.. ehh.. recompiling
22:36 unlord: karolherbst: no, I have confirmed there is no disk corruption
22:36 imirkin: unlord: yeah, i mean, i get that it should keep working. had an issue with a box at the office... power went out, the thing doesn't even POST anymore.
22:36 karolherbst: unlord: "how" did you confirm it?
22:36 karolherbst: bit by bit check against a backup?
22:37 karolherbst: or are you using an fs which checksums each block?
22:37 imirkin: unlord: that said, there's really nothing we can say about the blob driver here. if you want to try nouveau, we can see why it might not be working.
22:37 unlord: karolherbst: I ran fsck, I looked at recently accessed files
22:37 karolherbst: unlord: what fs?
22:38 unlord: ext4
22:38 karolherbst: sorry to tell you, but you did _not_ check for data corruption
22:38 karolherbst: ext4 can't do it
22:39 unlord: karolherbst: doesn't gentoo md5sum files as they are installed?
22:39 unlord: I can probably go figure this out
22:39 karolherbst: maybe
22:39 karolherbst: ohh, right
22:39 Lyude: it's going to be easier to just not assume disk corruption didn't happen and just reinstall the driver in plaintext mode
22:39 karolherbst: gentoo should, yeah
22:39 karolherbst: portage checksums installed files afaik
22:40 karolherbst: and there are tools to verify integrity
22:40 HdkR: Sounds a bit more involved than just a fsck :)
22:40 unlord: HdkR: sure, but so far I don't have any evidence to suggest this is the problem
22:40 karolherbst: yeah.. but with hard crashes you never know
22:41 Lyude: unlord: you can boot up with rd.driver.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm modprobe.blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm and thzat'll stop the nvidia driver from loading and let you get to a text console. that's as much help I can give
22:41 Lyude: also, probably best to boot up in plaintext mode (also pass 3 to the kernel commandline to do that)
22:41 karolherbst: HdkR: we have a fun saying here though: "no backup, no pity" :p
22:42 Lyude: also - fun fact, data corruption can also happen independently of the OS if for instance, you're using an SSD and the power gets cut and the SSD firmware doesn't have protection against that
22:42 Lyude: i've had two SSDs die that way
22:42 karolherbst: ext4 is quite good at verifying metadata is alright
22:42 karolherbst: and the overall fs tree is valid
22:42 karolherbst: but it does not guarentee data is not corrupted
22:43 karolherbst: especially as it does not do COW
22:43 karolherbst: at least afaik
22:43 unlord: Lyude: I took this power outage opportunity to add 20TB of storage to this box for backups
22:43 Lyude: good :)
22:43 karolherbst: unlord: that's not a backup though ;)
22:43 unlord: but until it boots, I won't be backing anything up
22:43 unlord: karolherbst: it's not to back up this computer
22:43 karolherbst: ahh
22:43 karolherbst: then it's fine
22:44 unlord: this computer is barely 3 months old, it doesn'thave anything valuable on it yet :)
22:44 Lyude: i feel like nvidia should pay us to give people support for their driver
22:44 karolherbst:still has to finally fix the entire way of doing backupts
22:44 karolherbst: Lyude: lol...
22:44 imirkin: Lyude: i try to counter that by recommending people to get not-nvidia instead
22:44 Lyude: imirkin: as do I :P
22:44 unlord: Lyude: where do I put this rd.driver line?
22:45 Lyude: unlord: kernel commandline
22:45 karolherbst: Lyude: if we are not getting paid by nvidia, then I wonder what we are doing anyway :p
22:45 Lyude: karolherbst: hehe
22:46 unlord: Lyude: I guess I can edit the grub line
22:46 Lyude: unlord: yep
22:50 unlord: well, it boots now
22:52 unlord: okay smart people, explain me how to use nouveau and I'll switch to it
22:52 unlord: also, can I game with it?/
22:52 Lyude: 1 - uninstall the nvidia driver
22:53 Lyude: 2 - depends on how old the card is, and the performance won't be anywhere near the nvidia blob
22:53 Lyude: newer cards (maxwell 2 and up) don't support any kind of reclocking yet
22:53 unlord: 1080GTX
22:53 unlord: so 4 years
22:53 Lyude: yeah, that won't support reclocking
22:53 unlord: I guess that is "new"
22:53 Lyude: that's pascal btw
22:53 HdkR: 3 - Yeet the Nvidia card - replace with AMD
22:54 HdkR: Per the "recommending peopel to get not-nvidia" comment
22:54 unlord: I guess I fatfingered it wrong
22:54 unlord: nvidia_modeset 1138688 0
22:54 unlord: nvidia 19263488 1 nvidia_modeset
22:55 HdkR: While the AMD Windows stack is hot garbage, the Linux side is very much the opposite :P
22:55 Lyude: if your machine boots that's fine, I probably missed a module in the blacklist thing
22:55 Lyude: it should be enough to let you uninstall it
22:55 Lyude: HdkR: the amd windows stack gives them such a bad name
22:55 Lyude: and, it's definitely a shame parts of it are shared with linux
22:55 unlord: Lyude: I would like to know why it stopped working though
22:55 unlord: this ran fine for months
22:56 unlord: I wonder if it is a firmware package or something
22:56 Lyude: unlord: unfortunately I have no idea and wouldn't be able to help you figure it out much, the kernel module probably just stopped loading for some reason
22:56 unlord: Lyude: that's weird right?
22:56 unlord: nothing else changed, computers are deterministic and all
22:56 HdkR: Not too uncommon for the Nvidia blob, especially if you got an update
22:57 unlord: I don't update things once they work
22:57 Lyude: unlord: i mean, my personal bar for expectations of nvidia on linux is near the floor. but yeah it's a little surprising, but not that surprising
22:57 Lyude: that's, probably not good, you should update things
22:57 HdkR: I understand the hesitation that once you've got the Nvidia blob working in Linux, you really don't want to touch anything out of fear of it exploding :P
22:57 Lyude: yeah, that makes sense at least :P
22:58 HdkR: Always a day long task of hanging the driver back up again...
22:58 Lyude: i feel like I should start keeping count of how many people come in here asking for help with the nvidia blob so the next time nvidia folks tell me the experience on their driver is great I can go "OH IS IT NOW?"
22:58 HdkR: hah
22:58 unlord: Lyude: none of this is new right? I've been having linux problems for like 20 years
22:59 Lyude: unlord: for the nvidia driver yeah. I mean, in the last 20 years gpu support on Linux has gotten _WAY_ farther then it used to be
23:00 Lyude: intel, amd run better then windows out of the box by default on linux. The arm gpu driver ecosystem is making a ton of headway (adreno's well supported, vivante, panfrost is getting there, vc4/vc5 are nearly perfect)
23:00 Lyude: but nvidia's still more or less as bad as it was 20 years ago in terms of user experience. maybe a few less bugs
23:01 Lyude: mostly because they just don't want to go open source, so they make things exponentially more painful for themselves and their users in the process
23:02 unlord: I guess I could upgrade the nvidia-drivers :)
23:04 RSpliet: Well, "want" implies an understanding of their motivations and (internal) discussions. I don't have any of those
23:04 RSpliet: That being said
23:04 RSpliet: Their history speaks for itself. Regardless of the motivation, open source has up until this day not been a goal
23:04 RSpliet: And it hurts out-of-the-box usability of their hardware
23:05 Lyude: RSpliet: i mean, if I had those things, I'd probably have to pretend like I'm not aware of them
23:05 RSpliet: ;-) ;-) ;-)
23:06 RSpliet: I was actually surprised to hear that ARM provides some support to Collabora for the panfrost/bifrost driver
23:07 Lyude: yeah that's pretty recent :), I'm really proud we managed to get that
23:07 Lyude: it's a shame I never got to do much work on it though
23:08 Lyude: oh well, maybe I can help out with the vulkan drivers for nouveau to get my 3D fill
23:08 karolherbst: Lyude: convince skeggsb :p
23:08 RSpliet: that would be an amazing step tbh
23:08 RSpliet: Would that not require proper threading support though?
23:08 karolherbst: no?
23:09 karolherbst: the bug is entirely inside mesa :p
23:09 imirkin: RSpliet: mostly it would require a different VM api
23:09 Lyude: RSpliet: I mean, assuming the things we need arrive at some point in time
23:09 karolherbst: yeah...
23:09 karolherbst: the uapi is the issue
23:17 unlord: Maybe I should buy one of these: https://www.tomshardware.com/news/amd-rx-6000-series-gpus-to-support-the-av1-codec
23:21 HdkR: Wait until reviews. It will also require a kernel that was released...yesterday?
23:22 unlord: I was about ot update my krenl
23:22 unlord: kernel
23:22 imirkin: HdkR: better than one released tomorrow
23:22 Lyude: yeah but there's usually a decent bit of time between kernel release and kernel inclusion in new releases... although iirc you were using gentoo
23:22 Lyude: so maybe that doesn't matter as much for you
23:23 HdkR: imirkin: It's fine when that GPU is going to be announced in two weeks :P
23:23 Lyude: good for amd getting support in mainline on time
23:23 Lyude:wipes single tear from cheek
23:23 Lyude: they've grown up so fast
23:24 HdkR: Now if they can fix the six months of stability problem
23:24 Lyude: HdkR: reallllllllllllllllly hope at some point they finally understand they wouldn't have all of these issues if they actually had a well organized codebase
23:25 Lyude: i've definitely been tempted to go through and clean up huge parts of their driver too many times
23:25 unlord: oh yah, I remember you guys from a year ago when I joined here asking how to create a DOS TSR that loads the nvidia register file so I can support low resolution true color modes with VBE2 int 0x10 API
23:25 Lyude: the day DAL/DC dies is the day it'll benefit everyone
23:26 unlord: my recollection was it was totally possible but I'd need to spend some work pulling out card detection code
23:29 HdkR: Lyude: If only we would be so lucky
23:32 unlord: nice, just reinstalling the same nvidia-drivers gentoo package fixed it
23:33 HdkR: Smells like something inside the nvidia drivers corrupted