18:02ppw: is there any performance to be gained at all by compiling the module into the kernel?
18:06karolherbst: ppw: huh? what do you mean?
18:06karolherbst: you mean y vs m inside the kernel config?
18:07karolherbst: might matter a bit for CPU perf as you need less relocations and call overhead, but I don't think it actually matters all that much
18:07ppw: yeah that's what I meant
18:08karolherbst: I doubt for GPU it matters as most perf is related to running shaders anyway
18:10RSpliet: In the grand scheme of "nouveau doesn't change GPU/DRAM clocks", "nouveau doesn't use Z-culling properly", "nouveau's shader compiler isn't hyperoptimised" and "nouveau's memory allocation/placement algorithms are fairly basic", the performance cost of a loadable module is negligible
18:11RSpliet: But sure, technically it may be a tad faster
18:11karolherbst: well.. there is merit in reducing CPU overhead, but...
18:11karolherbst: what people often forget is idle performance as well...
18:11RSpliet: Oh, let's not forget multithreading :-P
18:12ppw: RSpliet: OK, then what about this SVM option I discovered in the kernel? should I enable it?
18:12karolherbst: it matters, but not enough that people actually care
18:12karolherbst: ppw: you won't need it
18:12karolherbst: but it doesn't come with any runtime overhead really
18:12RSpliet: ppw: the performance problems with nouveau are all only solvable with large development effort
18:13RSpliet: So as far as these tweaks go, I'd say cluck around and find out ;-)
18:13ppw: ... well, yeah. that's kind of a fact. I'm just curious.
18:13RSpliet: And I don't want to kill curiousity! But nobody's done these experiments because the expectation is that it's negligible
18:14karolherbst: I suspect killing busy waiting in userspace is the biggest low hanging fruit we have atm to significantly lower CPU overhead
18:14karolherbst: we are using anholts suggestion for vulkan and it works out great
18:23ajax: i expect that working on nouveau performance is a target-rich environment
19:42johns: karolherbst: I'm back in front of the machine again, will be extracting info shortly. I'll check my backscroll here, but let me know if there's more to add / more that would be helpful
19:44karolherbst: johns: uhm... let me remember.. ahh yeah
19:47karolherbst: setpci -s 01:00.0 0x30.B=1
19:47karolherbst: setpci -s 01:00.0 0x50.L=0
19:47karolherbst: nvapeek 0x300000
19:47karolherbst: wondering if that returns the proper value
19:55johns: karolherbst: that returns "..." which I'm guessing is not the proper value
19:55karolherbst: that's 0
19:56karolherbst: johns: do you still have the dd command?
19:58johns: karolherbst: maybe.. I have dd if=/dev/mem of=cseg.rom bs=64k count=2 skip=12 and dd if=/dev/mem bs=4096 skip=192 count=32 | hexdump
19:59karolherbst: yeah, sounds right
20:00karolherbst: let me see what 0x30 and 0x50 were doing...
20:00karolherbst: I suspect with the proper combination of values we could make that work...
20:01johns: karolherbst: also you asked for a dump of /config, that's at https://paste.debian.net/1248444/
20:01karolherbst: "0000030 0000 0000 0050 0000" that is _oddO
20:02karolherbst: johns: is that from the correct device?
20:02johns: karolherbst: heh I was just catching that, sorry, no
20:02johns: trying again
20:03johns: karolherbst: https://paste.debian.net/1248445/ should be right
20:03karolherbst: ahh yeah, that looks better
20:06karolherbst: ahh no
20:06karolherbst: hexdump is just printing different than I though D
20:07karolherbst: johns: dd if=/dev/mem of=/dev/stdout bs=1 count=512 skip=$((0xe1000000)) | hexdump
20:07karolherbst: ehh wait
20:07karolherbst: that's wrong
20:07karolherbst: johns: dd if=/dev/mem of=/dev/stdout bs=1 count=512 skip=$((0x0x60e1000000)) | hexdump
20:08karolherbst: I am still wondering about that address
20:08karolherbst: but it's probably fine
20:09karolherbst: johns: dd if=/dev/mem of=/dev/stdout bs=1 count=512 skip=$((0x60e1000000)) | hexdump
20:09karolherbst: wondering if the last one actually gives us the vbios
20:13johns: karolherbst: that says bad address
20:13karolherbst: the last one?
20:13karolherbst: try dd if=/dev/mem of=/dev/stdout bs=1 count=512 skip=$((0xe1000000)) | hexdump then
20:14karolherbst: I am actually wondering about this 0060 in the config hexdump..
20:15johns: karolherbst: https://paste.debian.net/1248447/ is what I get from that
20:16karolherbst: do setpci -s 01:00.0 0x30.B=0 and try again
20:16karolherbst: though I would assume it becomes all ffff after that
20:18johns: karolherbst: you are correct https://paste.debian.net/1248448/
20:18karolherbst: setpci -s 01:00.0 0x30.B=1
20:18karolherbst: setpci -s 01:00.0 0x50.L=1
20:18karolherbst: and try again
20:18karolherbst: though I suspect it's all 0 as well
20:18karolherbst: I'd also need lspci -v to double check something
20:19johns: karolherbst: machine rebooted itself after those last two setpci and dd
20:19karolherbst: .... :(
20:20karolherbst: so the value in 0x30 is bonkers
20:20johns: I'll try it again just to see
20:22johns: yeah.. it does not like that
20:24johns: karolherbst: https://paste.debian.net/1248450/ is lspci -v
20:25karolherbst: johns: mind doing the dd without messing with setpci?
20:26karolherbst: but that's _very_ odd
20:26johns: hmmm https://paste.debian.net/1248451/
20:26karolherbst: yeah.. okay.. tough
20:27karolherbst: that's the shadow stuff
20:27karolherbst: uhm.. disable/enable one I mean
20:27karolherbst: let's.... do something stupid...
20:28karolherbst: setpci -s 01:00.0 0x30.L=$((0xe1000001))
20:28karolherbst: then lspci -v again
20:29johns: setpci: Invalid value "3774873601".
20:30karolherbst: maybe like this then? setpci -s 01:00.0 0x30.L=0xe1000001
20:30karolherbst: ohh wait...
20:30karolherbst: that's out of range.. duh
20:31karolherbst: setpci -s 01:00.0 0x30.b=0x1
20:31karolherbst: setpci -s 01:00.0 0x34.L=0
20:31karolherbst: then lspci -v
20:32johns: I see it no longer says disabled next to expansion rom
20:33karolherbst: yeah.. that's the write to 0x30
20:33karolherbst: huh.. 34 is something else... I always forget that it's all 32 bit based anyway
20:33karolherbst: no idea
20:33karolherbst: like something is wrong, but I have no clue what
20:33karolherbst: with all my GPUs I was able to retrieve the vbios with the location encoded inside 0x30
20:34karolherbst: either the GPU is weird... or it doesn't have a vbios (which would be weird)
20:34karolherbst: the only thing I think might be worth trying out is to put that GPU into a mainboard with stock firmware
20:34karolherbst: and see what happens there
20:37johns: that is a sensible step, I have one machine with stock firmware where it might fit but I'm not optimistic.. will take a look
20:37karolherbst: yeah.... anyway, if that doesn't work I suspect it's something with the GPU, but...
20:38johns: there's also the kernel unpatch that hell__ suggested
20:38karolherbst: I doubt it would work though
20:38karolherbst: as we checked the location it would use
20:38karolherbst: and it's all garbage
20:38karolherbst: well.. you could still give it a try but my hopes are low
20:38johns: I see
20:42karolherbst: my hopes were that if it's a libreboot/coreboot but, then maybe we could workaround that with the address in 0x30, but... :(
20:57johns: I'll try to get it into another machine in the next few days.. my next stop after that may be ordering a different card :) my needs are pretty simple
22:12RSpliet: ajax: like nuking fish in a barrel