02:12 AndrewR: sorry, NV50_PROG_USE_NIR=1 piglit resulted in hanged GPU (nv92) :}
02:43 ccr:grumbles at NOUVEAU_ERR() macro ..
02:45 ccr: would be great if it printed __FILE__ as well, hitting static function temp() in either nv30/{nvfx_fragprog.c nvfx_vertprog.c}
02:46 ccr: guess it's fragment shader anyway
18:29 Lyude: if you guys could have a text width limit on envytools, would you, and what would it be? (wanted to update nvbios to understand all of the vbios init opcodes we know so far, but also the style is all over the place and hurts to look at so I figured I'd add a clang-format file while I'm at it
18:40 imirkin: 80 chars
18:40 Lyude: imirkin: ...smaller then the kernel?
18:41 imirkin: don't know or care what the kernel says
18:41 Lyude:was really hoping for at least 100
18:41 Lyude:really wants 100, actually
18:41 imirkin: i think 80 is a fairly optimal width for code
18:41 imirkin: but perhaps i'm biased since it works so well on my setup?
18:41 Lyude: i did until the linux kernel switched to 100 and oh boy, 20 chars makes a lot of difference
18:41 imirkin: yeah. the difference between things fitting on my screen and not fitting ;)
18:41 imirkin: [without line-wrapping]
18:42 Lyude: imirkin: do you not have a 16:9 screen?
18:42 imirkin: i have 2x 10:16 screens
18:42 imirkin: (aka rotated 16:10 screens ... 1920x1200)
18:43 imirkin: 2x 80 chars fits REALLY nicely on one screen
18:44 imirkin: that said, i'm never in favor of hard limits
18:44 imirkin: on occasion, fitting within the limit is worse than not
18:44 imirkin: this is also why i don't like automated formatting tools
18:44 imirkin: since they follow specific rules, not harder-to-measure things like "readability"
18:44 Lyude: imirkin: i mean i'm definitely not running clang-format without going over the resutls
18:44 Lyude: *results
18:44 imirkin: sure
18:46 Lyude: skeggsb, opinions?
18:48 Lyude: also karolherbst, opinions on a text width for envytools?
18:48 Lyude: i'
18:48 Lyude: oop
18:48 Lyude: *I'm not converting the whole thing but would like to convert some of the files I'm working on that are very much all over the place style wise
18:49 karolherbst: Lyude: I don't care how wide those are as long as it's not ridiculous
18:49 karolherbst: ask mwk
18:57 imirkin: Lyude: there are some nvbios files in desperate need of ... attention
18:57 imirkin: it's not the cleanest code around
18:57 Lyude: imirkin: yeah :), I've seen lol
18:57 imirkin: i believe skeggsb had some hopes of converting nvbios to use the nouveau bios parser stuff
18:57 imirkin: and/or had some variant of it already
18:57 karolherbst: which is probably a good idea regardless
18:58 imirkin: of course there are still two vbios parsers in nouveau
18:58 imirkin: so nothing is perfect ;)
18:58 karolherbst: at least nvbios handles the newer files correctly
18:58 karolherbst: uhm
18:58 karolherbst: nouveau
18:58 karolherbst: not nvbios
18:58 imirkin: yeah
18:58 RSpliet: speaking of perfect, can we now do SPIR-V->NIR->TGSI->NV50_IR? :-P
18:59 karolherbst: imirkin: I am actually wondering why we don't do packed struct/union magic :D
18:59 imirkin: RSpliet: and then back -> SPIR-V again ;)
18:59 karolherbst: but that's probably too messy
18:59 karolherbst: RSpliet: sure
18:59 karolherbst: but why? :D
19:00 karolherbst: ntt is really for drivers not wanting to support nir directly, like nv30
19:00 Lyude: karolherbst: packed can be slow sometimes but if that doesn't matter packed rules
19:00 karolherbst: or I think the end goal was even to just use it in gallium and get rid of glsl -> tgsi entirely
19:00 Lyude: if you don't need to do __attribute__((packed)) and only need bitfields though that helps
19:00 karolherbst: Lyude: vbios parsing :p
19:00 Lyude: karolherbst: ah yeah
19:01 karolherbst: but this doens't map nicely to some tables I think
19:01 karolherbst: some tables are just stupid inconsistent
19:01 karolherbst: even within the same version
19:01 karolherbst: different length and other fun
19:02 RSpliet: karolherbst: for the glory of satan of course!
19:27 AndrewR: and just in time I was about to show my latest hack karol disappeared ....
19:27 AndrewR: https://pastebin.com/PESugQkM
19:50 AndrewR: so, [45013.395809] nouveau 0000:02:00.0: fifo: channel 5 [seamonkey[7039]] unload timeout" :) (was abusing GPU with tocl benchmark + my patch )
19:50 AndrewR: but at leats main display on another GPU still work
20:21 Lyude: we never powered off the edp panel in nouveau.
20:22 Lyude: that explains a lot.
20:22 Lyude: (no, the vbios scripts (at least the ones we call from nouveau currently) apparently do not do this)
21:19 RSpliet: https://github.com/geerlingguy/raspberry-pi-pcie-devices/issues/4
21:19 RSpliet: Apparently someone is trying to plug random graphics cards into a Raspberry Pi 4
21:19 RSpliet: And had nouveau fall over
21:21 imirkin: iirc ARM devices don't end up providing enough PCI window
21:21 imirkin: so the BARs never get allocated
21:22 imirkin: (at least not all of them)
21:23 ericonr: they might have issues with floating point stuff
21:23 ericonr: at least on the AMD side
21:24 ericonr: 5700XT support for aarch64 required a bit of kernel hacking to fix floating point exceptions
21:24 imirkin: well, if you look at the issue, it's definitely talking about BAR space.
21:25 ericonr: oh yeah, I just think they might have issues after that's sorted out
21:25 ericonr: all the power, tho
21:37 HdkR: Float exceptions? In the kernel?
21:38 HdkR: Sounds like a pretty bad bug if Radeon+ARM is causing float problems
21:42 ericonr: it's ok on x86 specifically
21:42 ericonr: from what I understand
21:42 ericonr: ppc64 shows the issues more clearly
21:43 karolherbst: huh, but that's little endien arm, no?
21:43 karolherbst: *endian
21:43 HdkR: Nobody should ever run big endian ARM
21:44 karolherbst: HdkR: you misspelled "Nobody should ever run big endian"
21:44 ericonr: karolherbst: sorry, ppc64le
21:44 HdkR: That too
21:44 ericonr: it's more about the guard code around fp operations than endian issues
21:44 karolherbst:cries in s390x
21:44 karolherbst: ericonr: probably
21:44 karolherbst: all the fp stuff is just terrible
21:44 ericonr: :)
21:44 HdkR: Stop doing FP in the kernel? :P
21:45 ericonr: sounds reasonable to me
21:45 karolherbst: stop messing with global fp state
21:45 karolherbst: ericonr: do you have code flipping rounding mode?
21:45 karolherbst: like compiled with Ofast?
21:45 Lyude: note there's only one user of fp in the kernel
21:45 karolherbst: ahh, this is a kernel problem?
21:45 karolherbst:doens't know the context
21:46 ericonr: karolherbst: I don't. And I don't have ppc64le hardware either, I just know this from second hand
21:46 ericonr: and indeed, it's a kernel issue in amd drivers
21:46 karolherbst: I know that things break if you compile stuff with Ofast
21:46 ericonr: is it even noticeably faster?
21:46 karolherbst: benchmarks say so
21:46 ericonr: I only know it's dangerous
21:47 karolherbst: you know, Ofast exists so that CPU vendors can show of with huge numbers (and while also disabling mitigations)
21:47 karolherbst: some still use Ofast "because"
21:47 ericonr: avx512 is more showoff-y, I think
21:47 ericonr: but it's at least "correct", usually
21:48 karolherbst: avx512 is just terrible
21:48 karolherbst: avx512 only exists for intel management so they can boast about how their CPUs have more threads than GPUs
21:49 HdkR: AVX512 only redeeming quality is that it allowed Intel to optimize `rep stos` and `rep movsb`, We can now throw away avx512 since we gained that :P
21:49 karolherbst: :p
21:49 karolherbst: it's probably still slower
21:49 karolherbst: also, what you do with your 200 loc assembler memcpys?
21:49 karolherbst: all for nothing now?
21:50 HdkR: Pretty sure it's the first check in glibc now?
21:50 karolherbst: so if you don't have it, it's now even slower?
21:50 ericonr: not for nothing, they help slow down whole cpu clock :)
21:50 karolherbst: ericonr: nope, they actually make memcpy faster
21:51 ericonr: karolherbst: I meant that other cores not doing memcpy still suffer
21:51 karolherbst: but this is all just super terrible anyway
21:51 HdkR: nah, glibc uses a dynamic dispatch
21:51 karolherbst: HdkR: at least something
21:51 ericonr: but eh, what do I know, I daily drive musl anyway
21:51 karolherbst: but as long as intel still thinkgs that SIMD is a good idea we will have to deal with that crap
21:51 HdkR: yea :|
21:52 karolherbst: does musl have a fast or trivial memcpy implementation? :D
21:52 karolherbst:thinks if trivial and fast implementations are not the same the technical base is just horribly broken
21:53 ericonr: karolherbst: it has specialized asm for some stuff, including memcpy iitc
21:53 ericonr: iirc
21:53 HdkR: It's pretty basic compared to glibc's version though
21:53 ericonr: https://git.musl-libc.org/cgit/musl/tree/src/string/x86_64/memcpy.s
21:53 ericonr: probably is
21:53 karolherbst: well, you can also write it in C and cry every time auto vectoriazation fails
21:54 karolherbst: ahh yeah
21:54 karolherbst: ericonr: that is slow memcpy :p
21:54 ericonr: :)
21:54 karolherbst: fast memcpy looks more like 5 loops and shit
21:54 ericonr: I don't really understand x86_64 asm
21:54 HdkR: and a dispatch table and cpuid detection
21:55 ericonr: I think felker cares a lot more for simplicity than squeezing cycles out
21:55 karolherbst: ericonr: https://twitter.com/jfbastien/status/1288232681432440834 :p
21:55 HdkR: and then the ideal is `rep movsb; ret` now ;)
21:55 ericonr: karolherbst: re. fast and trivial should be the same, I agree
21:55 ericonr: karolherbst: my eyes!
21:56 karolherbst: :p
21:56 karolherbst: but it's fast
21:56 karolherbst: and in C
21:57 HdkR: x86 performance characteristics is silly
21:57 karolherbst: I think that's true for most CPU archs
21:58 karolherbst: I mean, I kind of understand
21:58 karolherbst: they still have to deal with shitty code because people think writing "parallel" code means inserting locks weverwhere
21:58 karolherbst: *everwehere
21:58 karolherbst: ...
22:00 HdkR: ARM is still pretty sane. Interleave your loadstores and unroll the loop to roughly the number of pipelines
22:00 karolherbst: that sounds terrible
22:00 HdkR: Sadly we don't have a rep movsb equivalent there yet
22:01 HdkR: ARM did gain a 64byte cacheline copy for PCIe bursts though
22:01 karolherbst: "uff"
22:02 karolherbst: I think the fate of all CPU archs is, that they suffer from legacy stuff they can't break
22:05 HdkR: Which is semi-reasonable
22:05 HdkR: Implement it right the first time, otherwise pain for all
22:05 karolherbst: I don't even think x86 did anything "wrong" at the time, they just can't fix it
22:06 karolherbst: if you'd write your x86 programs in the native CPUs ISA it would probably look beautiful
22:06 karolherbst:has seen some native ISA stuff once and it just looked like GPU code
22:07 HdkR: Sadly if you wrote your code in native CPU ISA it would also break in a single generation
22:08 karolherbst: sure
22:08 karolherbst: but there was this idea of just compiling everything to llvm ir and do the final compilations on target machines, but I guess that was also painful
22:08 karolherbst: :D
22:09 HdkR: oops, now your struct alignments are mangled
22:09 ericonr: karolherbst: didn't apple do this/
22:09 ericonr: ?
22:09 ericonr: I think I read something about them distributing bitcode for some stuff
22:10 karolherbst: nope
22:10 karolherbst: they played around with it
22:10 karolherbst: but was never used
22:10 HdkR: They required IR submission for Watch apps submitted to the store, but as far as I know they only ended up using it to ensure people weren't doing evil things
22:11 HdkR: LLVM IR isn't good enough for cross-arch compiling it turns out :P
22:11 karolherbst: who knew
22:11 karolherbst: :D
22:12 karolherbst: I think a lot of companies ran into this mistake
22:12 karolherbst: unstable IR? sounds good :p
22:12 HdkR: perfect, ship dxil
22:12 karolherbst: imagine khronos wouldn't have dropped SPIR
22:13 HdkR: Oops, SPIR, push that under a rug
22:14 karolherbst: llvm ir was a mistake :p
22:16 HdkR: Using it outside of LLVM is a mistake. It should be an internal IR only
22:16 karolherbst: yep
22:17 karolherbst: maybe somebody should just submit an MR to remove the API :D
22:17 imirkin: tell that to llvmpipe
22:18 karolherbst: mhh, isn't that different?
22:18 HdkR: LLVM should have had a stable ingest IR first :P
22:18 imirkin: it's using llvm ir outside of llvm
22:18 karolherbst: HdkR: "ouch"
22:18 karolherbst: you mean, spirv? :D
22:19 HdkR: haha
22:20 karolherbst: imirkin: but I think there was a difference between the constructing the stuff while you go and reusing those binary files
22:20 karolherbst: but yeah.. maybe it's all the same
22:20 imirkin:is just trolling
22:20 karolherbst: yeah.. I think what we do is just doing this "string" based stuff where you just use strings for the opcode names :p
22:46 astlydichrar: hi there! I'm looking for some guidance on the "Blank monitor, flicker, snow, or other random live image corruption" section of the troubleshooting page
22:47 astlydichrar: basically, I have an Intel + Nvidia 1050 setup on a laptop and this is happening with my external screen: https://www.youtube.com/watch?v=W6GFjHwbcv0
22:48 Lyude: oh wow
22:48 Lyude: that's a bizarre one
22:48 astlydichrar: yep! nobody on /r/debian even commented on a post of mine about that
22:49 astlydichrar: the card is supposed to be supported by nouveau though, it's gp107
22:49 Lyude: it eerily reminds me of underflow reporting
22:50 Lyude: skeggsb: if you have any time, mind taking a look at that video? ^ would be appreciated if you could look at the issue as well, but if you don't have the time too just let me know. I'm mostly curious if you've seen anything like that before, and if maybe my guess about underflow reporting sounds right
22:51 Lyude: astlydichrar: are you on X by chance and if so, what xf86-video driver are you using (modesetting or nouveau?)
22:52 astlydichrar: this is on wayland
22:53 Lyude: sweet, I hate looking at X :)
22:53 astlydichrar: how would I figure out which xf86-video driver am I using?
22:54 Lyude: karolherbst: btw, are we using the gitlab for tracking nouveau issues yet
22:54 Lyude: astlydichrar: you don't-you're using wayland
22:54 karolherbst: Lyude: yeah
22:54 Lyude: oh cool
22:54 Lyude: i always lose track of the kernel bz so that helps
22:54 karolherbst: https://gitlab.freedesktop.org/drm/nouveau/-/issues
22:54 karolherbst: it slowly fills
22:54 karolherbst: you should have full access
22:55 Lyude: astlydichrar: I don't have the time to look today and I'm not sure what skeggsb is up to, but mind filing a bug there so I don't lose track of this?
22:55 astlydichrar: sure, I will :)
22:55 Lyude: cool, link to it afterwards and I'll watch it on gitlab
23:19 astlydichrar: Lyude: should I include a VBIOS dump?
23:20 Lyude: astlydichrar: might not be a bad idea tbh, also you can ignore the instructions on the wiki and just grab /sys/kernel/debug/dri/1/vbios.rom and /sys/kernel/debug/dri/1/strap_peek and upload those
23:34 astlydichrar: Lyude: could you copy-paste the instructions again? had to reboot my computer and can't see your previous message, sorry
23:38 ericonr: astlydichrar: grab /sys/kernel/debug/dri/1/vbios.rom and /sys/kernel/debug/dri/1/strap_peek
23:45 astlydichrar: thanks! issue posted here: https://gitlab.freedesktop.org/drm/nouveau/-/issues/17