01:23 MichaelP: 20-nouveau.conf Nvidia [GeForce GT 730 plasma 5.10.4.... screen tearing
02:33 imirkin: karolherbst: take a look when you get back: https://hastebin.com/hujujozeqa.php (your saturate patch, but generalized)
13:27 karolherbst_: imirkin: looks good to me
13:34 ccaione: imirkin_: out of curiosity (about https://bugs.freedesktop.org/show_bug.cgi?id=101782). Is the problem specific to the fact that the NVIDIA GPU is used with an Intel display controller?
13:39 rhyskidd: ccaione: There's no inherent problem with nouveau working on a muxless hybrid setup
13:39 rhyskidd: Indications are this is a problem bringing up the various Falcon engines and handling power up/down on Pascal series
13:40 ccaione: rhyskidd: I'm asking because we have seen other GP107 devices where this problem is not seen
13:40 ccaione: so I was wondering about the differences
13:42 rhyskidd: Are they hybrid (i.e. laptop) systems though? My understanding was the other GP107's that work on HDMI are in desktops
13:43 rhyskidd: Key difference being there that all the display outputs are directly connected to the nvidia card, not a mixture like on a laptop
13:44 rhyskidd: And so the issues we are having bringing up PCOPY engine properly is material, because it is getting exercised during the process of piping output around
13:44 ccaione: rhyskidd: laptopts (i.e. Asus FX502VD has a GP107 and HDMI output is fine)
13:44 ccaione: but IIRC on the Asus case all the outputs are actually on the NVIDIA card
13:45 rhyskidd: yeh ...
13:45 ccaione: only ACER connects eDP on intel and HDMI on NVIDIA
13:46 ccaione: AFAIK at least
14:30 imirkin: karolherbst_: pushed, thanks
14:31 imirkin: ccaione: the problem where the GPU doesn't come up? i have no clue what the issue is in this case. a similar issue in the past was due to the BIOS initializing the board in a state that nouveau could not bring it up from.
14:47 _0x40_: how do i compile this with debug symbols?
14:49 imirkin: 'this'?
14:49 _0x40_: nouveau
14:50 imirkin: there's no source package called 'nouveau' afaik
14:52 _0x40_: well, i need debug symbols in /usr/lib/xorg/modules/drivers/nouveau_dri.so
14:52 imirkin: so that'd be mesa
14:52 imirkin: anyways, it's simple - do what you normally do, but at the end, don't strip out the debug symbols.
14:53 _0x40_: okay, thanks!
14:53 imirkin: (this is a step that distros like to do to reduce package sizes, it's not done as part of a normal build)
14:53 imirkin: that said, if it *is* a distro-supplied package, then there should be a 'debug' package you can install
14:53 imirkin: if it's gentoo, which strips by default, you can add FEATURES=splitdebug
14:54 imirkin: which will save off the debug symbols somewhere
14:55 urmet: I recall splitdebug needing one extra package to work. so it can write the debug file locations into the binaries
14:56 imirkin: dunno. i have: FEATURES="splitdebug -xattr"
15:01 ccaione: imirkin: I was referring to the missing HDMI output on the ACER laptop with no acceleration `noaccel==1`
15:01 urmet: ah. it was installsources that needed extra debugedit package to work correctly
15:02 urmet: for extra-fancy debugging experience
15:04 karolherbst_: well, you still need to debug with -g2 or -g3 so that splitdebug does anything usefull
15:04 karolherbst_: *build
15:04 karolherbst_: best add -g3 -ggdb3
15:05 karolherbst_: no idea if the former is even needed with the latter
15:08 imirkin: ccaione: the issue is that the nouveau ddx requires acceleration in order to support offload. you can use that output just fine on its own
15:08 imirkin: ccaione: much as you can use the intel output on its own
15:08 ccaione: yeah, but not together at the same time
15:10 imirkin: well, you know ...
15:10 imirkin: you COULD try to rig it so that nouveau is primary
15:10 imirkin: oh, but no, that would suck too
15:11 imirkin: karolherbst_: pretty sure you get symbols without any of that. if you want additional dwarf info, you need more flags.
15:12 imirkin: and like i said - you can use them simultaneously as separate X screens. of course you need a WM that plays nicely with that.
15:13 ccaione: yeah
15:13 ccaione: not really what we want though :(
15:14 imirkin: sure, i get that.
15:14 imirkin: check if there's a way for you to disable the nvidia gpu entirely
15:14 urmet: hmm. gcc documentation even suggests using -Og
15:15 imirkin: for some laptops, that flips some internal mux to let the input hang off the IGP. on others, you just lose that port entirely.
15:15 karolherbst_: imirkin: okay sure, but debugging without it is usually painful,
15:21 ccaione: imirkin: that's interesting. Any hint how to check that? (you mean like a BIOS switch or something like that?)
15:22 imirkin: yeah, just go into the bios and poke around :)
15:23 ccaione: yeah, done that. But this BIOS (InsydeH20) sucks badly
15:24 ccaione: so no switch, no options for GFX in general
16:51 mwk: well, that was fucked up
16:51 mwk: so Rankine has a single pitch method for color & zeta, low 16 bits are color and high 16 are zeta
16:52 mwk: but NV40 supports pitches up to 0x1ffc0, so 16 bits are not enough, and as such Curie has separate color/zeta pitch methods
16:53 mwk: which, as expected, just &= the value with 0x1ffc0 and stuff it into the proper pitch register
16:53 mwk: but... the Rankine single pitch method works as follows
16:53 mwk: if (!pgraph error pending) surf_pitch_color = val & 0xffc0, surf_pitch_zeta = val >> 16 & 0xffc0; else surf_pitch_color = 0x1ffc0;
16:54 mwk: [on NV40 only; on NV30 it always does the first variant as expected]
17:15 MrBIOS-home_: imirkin: you around by chance?
17:15 imirkin_: .
17:22 karolherbst: imirkin_: only "KHR-GLXX.transform_feedback.api_errors_test" is missing to pass at least all 30 tests... (if I exclude the two last one which crash internally)
17:22 karolherbst: *GL30
17:23 imirkin_:fails to parse that sentence
17:23 karolherbst: I ran the gl30-master.txt tests from khronos. 3 fails: 2 internal crashes within deqp and one fail, which is transform_feedback.api_errors_test
17:24 imirkin_: ah cool. note that most of the GL2/3 tests aren't public =/
17:24 karolherbst: yeah
17:24 karolherbst: but I want to have a nice order in which I fix all public tests
17:24 karolherbst: and starting with the 3.0 list sounded like a good idea to me
17:24 imirkin_: no objections from me!
17:24 karolherbst: those are usually subsets of the higher levels anyway
17:24 imirkin_: they do seem to take pull requests
17:25 imirkin_: they took one from me on both VK-GL-CTS and OpenGL-Registry
17:25 imirkin_: i was surprised :)
17:25 karolherbst: yeah, I saw
17:25 imirkin_: although the VK-GL-CTS one took a long time.
17:25 karolherbst: first fixing KHR-GL30.transform_feedback.api_errors_test though
17:25 karolherbst: "INVALID_OPERATION was not generated by DrawTransformFeedbackInstanced and DrawTransformFeedbackStreamInstanced if <mode> did not match geometry shader."
17:26 imirkin_: see ARB_transform_feedback2 and ARB_transform_feedback_instanced for the details
17:26 karolherbst: yeah, already checking
17:27 imirkin_: that could either be a legit issue in mesa, or it could be them having multiple errors, where a different one "wins" on mesa than they expect
17:27 karolherbst: ahhh
17:27 karolherbst: okay
17:27 karolherbst: there is no error at all
17:28 karolherbst: well for those calls
17:28 imirkin_: ok, so then it's either a legit issue in mesa, or the specs don't require that error to be generated despite the test claiming that.
17:28 karolherbst: mhhh
17:28 imirkin_: what they're complaining about *sounds* like it makes sense
17:28 imirkin_: but ... who knows with these specs
17:28 karolherbst: "geometry shader is active and mode is incompatible with the input primitive type of the geometry shader in the currently installed program object"
17:30 imirkin_: also i forget how DrawTransformFeedback works ... does it skip the pre-rast pipeline? or does it go through it. if it goes through it, then yeah, the GS input primitive has to match the primitive that it's drawn with.
17:30 imirkin_: in which case it's definitely an oversight of validation in mesa
17:31 karolherbst: it's like calling DrawArraysInstanced with special things
17:32 MrBIOS-home_: imirkin are you still interested in Nouveau on Big Endian? Willing to take a look at a pastebin of a failed init of a G71 on ppc64?
17:32 MrBIOS-home_: https://pastebin.com/Vi2L7N8w
17:35 imirkin_: MrBIOS-home_: semi-interested i suppose... mine runs reasonably well now
17:35 imirkin_: MrBIOS-home_: is this an actual apple G71 or is this a random G71 you plugged in?
17:36 imirkin_: there was a bug in nvkm_outp_init a while back
17:36 imirkin_: https://github.com/skeggsb/nouveau/commit/30286e2bcd02d09c050b18b67f7d33776d44fa0c
17:36 imirkin_: note that those are warnings, not bugs
17:37 imirkin_: with that patch, should be all fixed up though
17:37 imirkin_: unless this is a diff issue... could be
17:38 imirkin_: that patch SHOULD have been in 4.13-rc3 which is what you appear to have
17:38 imirkin_: karolherbst: yeah, instead of drawing vertices from a VBO, you're drawing them from a TF buffer
17:38 MrBIOS-home_: imirkin: it's not an Apple G71, it's also not on Apple BE hardware
17:39 MrBIOS-home_: I'll happily test the patch
17:39 imirkin_: well... i think you already have that patch
17:39 imirkin_: commit 587f577e0beb4d20ee60bac8d21134b4c5a9fd29 upstream
17:39 MrBIOS-home_: I;ll check
17:39 MrBIOS-home_: it seems to initialize the card, but I get garbage on screen
17:39 MrBIOS-home_: it looks sorta like white noise
17:40 imirkin_: i think the WARN is from
17:40 imirkin_: ior = nvkm_ior_find(disp, type, -1);
17:40 imirkin_: if (!ior) {
17:40 imirkin_: WARN_ON(1);
17:41 imirkin_: MrBIOS-home_: can you boot with drm.debug=0x1e nouveau.debug=trace ?
17:42 karolherbst: mhh okay, they call both functions with mode = {QUADS, LINES, POINTS, PATCHES} and patches needs a special validation. Only QUADS is invalid for geometry shaders?
17:42 MrBIOS-home_: imirkin: I have the first part of that patch, but not the second, it weould seem
17:42 karolherbst: okay and patches, but this needs special handling anywas
17:42 karolherbst: *anyway
17:42 MrBIOS-home_: imirkin: sure, happy to
17:43 imirkin_: MrBIOS-home_: that'd be very surprising
17:43 imirkin_: karolherbst: nah, quads are valid
17:43 imirkin_: karolherbst: they get decomposed into tris
17:43 MrBIOS-home_: oh I was looking at the wrong file, nevermind :D
17:44 karolherbst: imirkin_: mhhh
17:44 imirkin_: karolherbst: if mode == points, gs input == points, if mode == lines/line_strips/line_strips_adj, gs input == lines, else gs input == tris
17:44 imirkin_: the gs input has to correspond to the mode
17:44 karolherbst: mhh okay
17:44 karolherbst: and mode = GL_QUAD is valid?
17:44 imirkin_: in THEORY yes
17:45 imirkin_: in practice no
17:45 imirkin_: GL_QUADS is only valid in compat contexts
17:45 imirkin_: and we don't have geometry shaders in compat contexts
17:45 karolherbst: okay
17:45 imirkin_: but if we did, mode = GL_QUADS would mean gs input == tris
17:45 karolherbst: so DrawTransformFeedbackInstanced should throw INVALID_OPERATION if mode == GL_QUADS, right?
17:45 imirkin_: not at all
17:45 karolherbst: mhhh
17:46 karolherbst: okay, but mhh
17:46 karolherbst: then the test must be wrong
17:46 imirkin_: i suspect that the test assumes that geometry shaders are a thing
17:46 imirkin_: anyawys
17:46 imirkin_: well, actually i dunno what it assumes
17:46 imirkin_: either way, i'd have to read it to understand what's going on.
17:46 imirkin_: perhaps you're forcing a GL version
17:46 karolherbst: maybe airlied knows more about this failing test?
17:47 karolherbst: ohh
17:47 karolherbst: that might be the issue
17:47 imirkin_: and so it thinks that you have GL 3.2+ in compat
17:47 karolherbst: it also fails if I leave out the override or force 3.0
17:49 karolherbst: fun
17:49 karolherbst: that tests even creates tess shaders
17:49 imirkin_: yeah, iirc the framework is messed up
17:49 karolherbst: yeah
17:49 karolherbst: this test is part of 4.4 and 4.5 though
17:50 imirkin_: right, and tess also plays into TF stuff
17:55 karolherbst: well sure, but this is also defined there: "mode is PATCHES and no tessellation control shader is active"
17:55 imirkin_: right.
17:55 karolherbst: maybe it complains simply about this case?
17:59 karolherbst: uhm
17:59 karolherbst: it complains about GL_POINTS
18:01 imirkin_: MrBIOS-home_: also ... can i assume that you're using 4K pages?
18:01 MrBIOS-home_: correct
18:01 imirkin_: [are you getting that dmesg with the extra debug things?]
18:03 MrBIOS-home_: imirkin: I just accidentally built this kernel sans Nouveau, rebuilding now
18:03 imirkin_: hehehe
18:04 MrBIOS-home_: should I set the max debug level to something other than the default of 5?
18:04 imirkin_: no
18:04 MrBIOS-home_: okay, building
18:04 imirkin_: also, what are you actually seeing on the screen?
18:04 MrBIOS-home_: I said before, I see what looks like multicolored white noise
18:05 imirkin_: hmmmmmm
18:05 MrBIOS-home_: I can take a photo but it won't mean much or be clear
18:05 imirkin_: i doubt it'd be too useful
18:05 MrBIOS-home_: right
18:06 imirkin_: and is that fbcon or X?
18:08 MrBIOS-home_: fbcon
18:09 MrBIOS-home_: also, if you have any interest in having a G71, I have a pile of them. I'll send you one for free
18:14 rhyskidd: ccaione: to confirm, with your setup are you manually setting nouveau.noaccel=1 kernel module parameter?
18:14 rhyskidd: i.e. in GRUB or somewhere similar
18:14 ccaione: rhyskidd: we have a quirk for it
18:14 ccaione: that's why you cannot see it as bootarg
18:15 rhyskidd: what happens if you don't set that, but instead set nouveau.runpm=0
18:15 ccaione: I can boot but I have a lot of WARNINGs in the journal
18:15 rhyskidd: Do you get actual problems though, like CPU soft locks?
18:16 ccaione: not that I remember of
18:16 ccaione: (https://bugs.freedesktop.org/show_bug.cgi?id=101764#c5)
18:17 ccaione: but I didn't spend much time on runpm=0 to be 100% sure about this
18:18 ccaione: stepping out, back later
18:19 rhyskidd: ok
18:22 MrBIOS-home_: imirkin: https://pastebin.com/vnBsaPbA
18:22 MrBIOS-home_: it locks up
18:22 MrBIOS-home_: "GPU lockup - switching to software fbcon"
18:22 MrBIOS-home_: on line 2402
18:23 imirkin_: on apple HW, that was the result of MSI being messed up
18:23 imirkin_: can you check /proc/interrupts
18:23 imirkin_: and see if > 1 intr has been delivered?
18:24 imirkin_: looks like you forgot to build in support for some fs as well? :)
18:24 MrBIOS-home_: sure
18:25 MrBIOS-home_: not sure what the deal with that is, figuring it out now
18:25 imirkin_: you can try booting with nouveau.config=NvMSI=0 to disable MSI
18:31 MrBIOS-home_: imirkin: so, once userland loaded properly, I do get Xorg starting
18:31 MrBIOS-home_: its garbage, though
18:31 MrBIOS-home_: white and black stripes with colored noise
18:32 imirkin_: did you see my above questions?
18:33 MrBIOS-home_: there is only one
18:33 MrBIOS-home_: 26: 0 0 0 1 fsl-msi-224 5 Edge nvkm
18:33 imirkin_: so ... yeah, 1 interrupt
18:33 imirkin_: so disable MSI
18:34 MrBIOS-home_: ack
18:34 MrBIOS-home_: success
18:35 imirkin_: works better when interrupts are delivered?
18:35 MrBIOS-home_: MSI works on the exact same system, with Radeon though
18:35 imirkin_: yeah, i'm guessing something's wrong with nvidia hw or how we program it
18:35 imirkin_: esp since benh swore up and down that MSI worked OK on PPC G5 as well
18:36 imirkin_: unfortunately MSI has largely resisted any of my attempts at understanding it
18:36 imirkin_: so i can't even venture a guess as to what might be wrong
18:37 MrBIOS-home_: is benh around here? is he mr waffle?
18:39 imirkin_: he's often logged in here, although he doesn't appear to be on right now
18:39 imirkin_: he's the ppc maintainer
18:39 imirkin_: and so knows one or two things about the platform :)
18:40 MrBIOS-home_: yeah I know who he is :)
18:41 MrBIOS-home_: just not if he ever comes here
18:41 imirkin_: definitely used to be
18:42 MrBIOS-home_: and now I'm rebuilding Mesa with Nouveau driver enabled ;)
18:43 karolherbst: MrBIOS-home_: --with-gallium-drivers=nouveau
18:44 MrBIOS-home_: way ahead of you :)
18:44 imirkin_: don't expect any miracles
18:44 imirkin_: there were a lot of bugs when i was getting my NV34 to wrok
18:45 MrBIOS-home_: I am well aware. it works fine with software rasterization
18:45 imirkin_: i suspect nv4x will have a lot of bugs too
18:45 imirkin_: very simple stuff works
18:45 MrBIOS-home_: do you want a board?
18:45 imirkin_: but once you get fancy, the LE <-> BE stuff got too confusing
18:45 MrBIOS-home_: free
18:45 imirkin_: wouldn't have anywhere to plug it in
18:45 MrBIOS-home_: I can help you fix that too
18:46 imirkin_: i have a PowerMac7,3 which only has AGP (and PCI)
18:50 MrBIOS-home_: weird, now I get "libGL error: core dri or dri2 extension not found"
18:51 imirkin_: restart X
18:51 MrBIOS-home_: I did, I restarted lightdm
18:51 imirkin_: X can't find the nouveau_dri.so
18:51 imirkin_: which it also needs for GLX things
18:52 imirkin_: which are all very deeply intertwined, even with client-side rendering
18:53 MrBIOS-home_: I suspect its trying to use the wrong nouveau dri module
18:53 MrBIOS-home_: the distro-provided one
18:54 imirkin_: the versions don't have to match
18:54 imirkin_: pastebin xorg log
18:54 imirkin_: oh, unless it's a very old version
18:54 imirkin_: in which case it didn't work on BE
18:54 MrBIOS-home_: I'm running debian sid
18:55 MrBIOS-home_: so I doubt it is
18:55 MrBIOS-home_: I just removed xserver-xorg-video-nouveau
18:55 imirkin_: that's not what provides nouveau_dri.so
18:55 MrBIOS-home_: mesa module?
18:55 imirkin_: nouveau_dri.so is provided by mesa
18:55 imirkin_: nouveau_drv.so is provided by xf86-video-nouveau
18:55 imirkin_: you want both.
18:56 MrBIOS-home_: both removed, or both present? ;-)
18:56 imirkin_: present.
18:56 imirkin_: and what you really want to do is pastebin the xorg log
18:56 imirkin_: so i can see what's going on instead of making random guesses
18:57 MrBIOS-home_: https://pastebin.com/hPTB6cBq
18:57 MrBIOS-home_: "couldn't open module nouveau"
18:57 MrBIOS-home_: lines 65/68
18:58 MrBIOS-home_: /usr/lib/powerpc64-linux-gnu/dri/nouveau_dri.so is present on my system, so I don't get it
19:00 karolherbst: you need nouveau_drv.so
19:00 karolherbst: which is a different thing
19:00 karolherbst: which is inside /usr/lib/xorg/modules/drivers/ or something simliar
19:01 MrBIOS-home_: its there on my system, it's 275k
19:01 MrBIOS-home_: at /usr/lib/xorg/modules/drivers/nouveau_drv.so
19:04 MrBIOS-home_: on Debian, xserver-xorg-video-nouveau provides /usr/lib/xorg/modules/drivers/nouveau_drv.so, according to dpkg
19:50 MrBIOS-home_: imirkin: got it working, getting around 600fps in glxgears, no apparent color issues
19:51 imirkin_: yeah, glxgears works
19:51 imirkin_: try something more complicated and it may not be so happy
19:52 MrBIOS-home_: I'm getting an illegal instruction in nouveai_dri when it tries to check for altivec support
19:52 MrBIOS-home_: its thrown at check_os_altivec_support, according to gdb
19:52 imirkin_: that's not even inside nouveau
19:52 imirkin_: that's in llvmpipe probably
19:52 MrBIOS-home_: that was when starting a build of ioquake3
19:53 MrBIOS-home_: works fine on Radeon
19:53 karolherbst: MrBIOS-home_: g4 or g5? afaik g5 has no altivec
19:53 imirkin_: g5 has altivec
19:53 MrBIOS-home_: karolherbst: you are wrong, G5 has altivec
19:53 MrBIOS-home_: e5500 does not
19:53 karolherbst: sure?
19:53 MrBIOS-home_: this is neither G4 or G5
19:53 MrBIOS-home_: it's Freescale quad-core ppc64 part
19:53 imirkin_: either way, llvmpipe is used in fallback scenarios
19:53 karolherbst: ohhh
19:53 karolherbst: k
19:53 imirkin_: where the hw doesn't support something
19:53 karolherbst: I thought g5 has no altivec or just a crappy one
19:53 MrBIOS-home_: it has altivec and there's nothing wrong with it that I know of
19:54 imirkin_: radeon might not have that fallback case
19:54 imirkin_: or it might be in a different spot
19:54 imirkin_: either way, figure out what the llvmpipe code does
19:54 imirkin_: this would be in src/gallium/auxiliary/util/u_cpu_detect.c i'm guessing
19:55 karolherbst: MrBIOS-home_: ohh okay, maybe I simply miss remembering something then
19:55 imirkin_: karolherbst: G3 has no altivec iirc
19:55 karolherbst: yeah, that I know
19:55 MrBIOS-home_: correct, G3 didn't have altivec
19:58 MrBIOS-home_: what provides check_os_altivec_support ? libdrm?
19:59 imirkin_: guessing it's in mesa
19:59 imirkin_: src/gallium/auxiliary/util/u_cpu_detect.c:check_os_altivec_support(void)
19:59 MrBIOS-home_: imirkin: I don't see it, I just grepped the tree
19:59 MrBIOS-home_: oh, I just saw the invocation
19:59 imirkin_: much as i had predicted....
20:00 MrBIOS-home_: I think its the brute force way that's causing the issue
20:00 imirkin_: wait, are you running it in gdb?
20:00 MrBIOS-home_: stupid assembly
20:00 imirkin_: in gdb, the signal will get caught
20:00 MrBIOS-home_: I was
20:00 imirkin_: it's basically seeing if it gets a SIGILL or not
20:00 imirkin_: ok, then just run "continue" when you see that
20:00 MrBIOS-home_: I get the same behavior when I run ioq3 outside of gdb as well
20:01 MrBIOS-home_: continue causes the whole screen to shift up and then lock up :)
20:01 MrBIOS-home_: very bizarre
20:04 MrBIOS-home_: it fails after I continue, once it tries to go fullscreen
20:31 karolherbst: KHR-GL33.shaders.struct.uniform.sampler_nested_vertex is broken on nouveau, like completly
20:39 Lyude: I hate to ask this here but lots of googling and troubleshooting hasn't helped me make any progress with this... has anyone managed to get any kind of machine working with the nvidia blob's KMS support?
20:40 imirkin_: i'm guessing you're having trouble? :)
20:40 Lyude: All I've been getting is "Failed to import NVKMS memory to GEM object" whenever I try to get any kind of eglstream client started...
20:40 Lyude: imirkin_: yes, unfortunately
20:40 Lyude: s/eglstream client/anything kms related/
20:40 imirkin_: Xorg + modesetting?
20:40 imirkin_: oh, that won't work
20:40 imirkin_: coz it wants MESA_drm_image or whatever
20:40 Lyude: no, wayland/gnome
20:41 imirkin_: i just meant testing that out
20:41 imirkin_: but wtvr. either way, no clue.
20:41 Lyude: yeah i've managed to get X running with no problems
20:41 Lyude: that isn't with modesetting turned on though
20:41 imirkin_: there's a #nvidia channel, not sure anyone of consequence pays attention to it
20:42 imirkin_: they also have those support forums where you can ask questions that won't get answered
20:42 airlied: also james and aaron are on irc
20:42 airlied: maybe xorg devel
20:45 Lyude: cool, thanks for the info
20:55 MrBIOS-home_: imirkin: most of the mesa demos seem to work fine
20:55 imirkin_: most.
20:55 imirkin_: and that was after some fairly nasty hacks.
20:56 imirkin_: this was a favorite: 78ec9e28ec759bcaf9781bcbd2b8e051f7df7896
21:04 MrBIOS-home_: imirkin: I switch back to Radeon on the exact same kernel and Mesa stack, and ioquake3 starts fine
21:04 MrBIOS-home_: I only get the illegal instruction with Nouveau
21:05 imirkin_: ok
21:05 imirkin_: i don't suppose you read what i wrote about that?
21:05 MrBIOS-home_: I did, but "either way, figure out what the llvmpipe code does" doesn't really help me
21:06 imirkin_: ok
21:06 imirkin_: that's the u_cpu_detect.c stuff.
21:06 imirkin_: try running ioquake with LIBGL_ALWAYS_SOFTWARE=1
21:06 imirkin_: observe same crash.
21:07 imirkin_: alternatively, try running ioquake with nouveau with DRAW_USE_LLVM=0
21:11 MrBIOS-home_: oh, as an aside, nouveau totally shits itself if you start it with no display attached
21:11 MrBIOS-home_: at least with this card
21:13 MrBIOS-home_: imirkin: ever seen this behavior before? https://pastebin.com/81nafBu1
21:15 imirkin_: yeah ... "something gets messed up"
22:09 MrBIOS-home_: /join #xorg
22:09 MrBIOS-home_: argh
22:10 tobijk: MrBIOS-home_: if you are runnig an early 4.13rc kernel you may observe nouveau oopsing for two reasons: an error printf is not accessible and or nouveau tries to disable vblank on a non-existent display
22:10 tobijk: i can check, your pastebin expired
22:11 tobijk: *can't
22:11 MrBIOS-home_: tobijk: it's not early, it's rc4
22:12 MrBIOS-home_: it's a day old :)
22:12 MrBIOS-home_: well, 72ish hrs
22:13 tobijk: k, whit that recent version both of those bugs should be fixed
22:13 imirkin_: MrBIOS-home_: where was that log with drm.debug=0x1e nouveau.debug=trace and the WARN's that you get?
22:13 imirkin_: MrBIOS-home_: i believe that's worth investigating + fixing
22:13 imirkin_: MrBIOS-home_: if it's not difficult, i'd appreciate it if you could file a bug with that log + your vbios at bugs.freedesktop.org
22:14 MrBIOS-home_: let me regenerate it
22:15 imirkin_: (you can get vbios from /sys/kernel/debug/dri/0/vbios.rom )
22:15 imirkin_: i highly suspect that the issue also affects non-BE environments
22:15 imirkin_: just not a lot of people on old hw who test rc's
22:16 MrBIOS-home_: I'm not on old HW :)
22:16 imirkin_: G71 is old hw.
22:17 MrBIOS-home_: ok I'll give it that ;)
22:17 imirkin_: MrBIOS-home_: if you have newer nvidia boards available, i'd be curious how they fare on BE.
22:17 imirkin_: i'm guessing "poorly"
22:17 MrBIOS-home_: I'd guess so as well
22:17 MrBIOS-home_: I don't have much
22:17 MrBIOS-home_: I have much newer AMD gear
22:17 imirkin_: since there's been nearly no testing of them
22:18 imirkin_: i do seem to recall someone saying that colormaps seemed messed up
22:18 imirkin_: but there was no super-concrete info
22:22 tobijk: imirkin_: is this really necessary(ssa state)? https://hastebin.com/rejicajuqe.pl
22:22 tobijk: looks strange to me...
22:22 imirkin_: what seems to be the problem?
22:23 tobijk: i'd have guessed builtin abs would take two random ssa regs
22:23 imirkin_: [yes, seems perfectly fine... you appear to be missing a nop - $r0 in there
22:23 MrBIOS-home_: tobijk: https://pastebin.com/rrkG0yAU
22:23 MrBIOS-home_: imirkin: ^^ https://pastebin.com/rrkG0yAU
22:23 MrBIOS-home_: that?
22:23 tobijk: the moving to $0/1 looks silly in that state
22:23 imirkin_: tobijk: it's "call abs" (i.e. absolute address)
22:23 imirkin_: tobijk: it's calling a library function which uses fixed registers, and returns values in fixed registers
22:24 imirkin_: MrBIOS-home_: perfect. and the vbios too.
22:24 MrBIOS-home_: how?
22:24 imirkin_: /sys/kernel/debug/dri/0/vbios.rom
22:24 imirkin_: MrBIOS-home_: wait, this was booted without NvMSI=0?
22:25 imirkin_: could you boot with that if possible?
22:25 MrBIOS-home_: oh
22:25 MrBIOS-home_: yes I can
22:25 MrBIOS-home_: sorry :D
22:25 imirkin_: [and make sure to attach the actual files in bz, not just links to pastebins, since those disappear]
22:25 MrBIOS-home_: /sys/kernel/debug/dri/0/vbios.rom does not exist
22:25 imirkin_: do you have other gpu's?
22:25 MrBIOS-home_: /1/vbios.rom does
22:25 MrBIOS-home_: no, one gpu
22:26 imirkin_: well, something is registering as /0/
22:26 imirkin_: anyways, grab the /1/ one
22:26 MrBIOS-home_: cat /sys/kernel/debug/dri/0/name
22:26 MrBIOS-home_: vgem unique=vgem
22:27 imirkin_: you must be loading the vgem module :)
22:27 imirkin_: that's for ... not sure what.
22:27 MrBIOS-home_: vbios is at http://alexperez.com/Cyrus/vbios.rom
22:28 MrBIOS-home_: imirkin: it's for https://cateee.net/lkddb/web-lkddb/DRM_VGEM.html
22:29 imirkin_: right, i know what it is. just not sure what it's for.
22:30 imirkin_: i think it's meant to help in VM scenarios?
22:31 tobijk: or if you dont have a card attached and running llvmpipe?! meh
22:43 tobijk: ah we could move consts dirctly to the abs regs instead of allocationg an register until it is moved to the abs reg $0 or $1
22:44 imirkin_: ignore the word "abs"
22:44 imirkin_: that's just in reference to a relative vs absolute call
22:45 tobijk: still, const should not eat up regs
22:45 imirkin_: i.e. if the address is relatively to the PC or absolute (relative to the start of the code page)
22:45 imirkin_:is confused
22:46 imirkin_: what const?
22:46 tobijk: https://hastebin.com/padoqegiva.bash
22:46 tobijk: $r7 it is
22:47 imirkin_: that's coz they're in different BB's i'm guessing?
22:47 imirkin_: although ... shouldn't matter. dunno
22:47 imirkin_: would have to look at the SSA to tell what's going on
22:47 tobijk: mh? that is in one BB
22:47 tobijk: and actually after RA is done
22:47 tobijk: but it looks the same in the ssa
22:48 imirkin_: perhaps $r7 is used elsewhere
22:48 imirkin_: where the 3 was needed?
22:48 tobijk: the complete bb: https://hastebin.com/ebecexebuz.bash
22:50 imirkin_: yeah dunno. weird.
22:50 tobijk: propagationg missing that case, imho
22:51 imirkin_: like i said, would have to look at SSA to have an idea of what's going on
22:51 imirkin_: and even that probably wouldn't be enough
22:51 tobijk: imirkin_: worth a try? https://hastebin.com/cifunojefa.pl
22:52 imirkin_: ok. that is *messed up*
22:52 imirkin_: i can't imagine why LoadPropagation would skip it...
22:54 tobijk: yeah, haven't check LoadProp, just noticed it while looking at that shader
22:57 tobijk: imirkin_:
22:57 tobijk: if (i->op == OP_CALL) // calls have args as sources, they must be in regs
22:57 tobijk: continue;
22:58 imirkin_: shouldn't matter... this is the MOV
22:58 imirkin_: not the CALL
23:25 MrBIOS-home_: imirkin: https://pastebin.com/pKyX7gAW
23:27 imirkin_: cool
23:27 imirkin_: and that works fine, right?
23:28 MrBIOS-home_: seemingly
23:29 imirkin_: great
23:29 imirkin_: getting that into the bug + vbios would help track the WARN issue
23:30 MrBIOS-home_: I'm happy to file a bug, any recommended subject line/description?
23:30 imirkin_: WARN_ON hit when loading G71 with v4.13-rc3
23:30 MrBIOS-home_: rc4 ;)
23:31 imirkin_: :)
23:32 MrBIOS-home_: imirkin: I don't see an appropriate component within DRI
23:32 MrBIOS-home_: general?
23:32 imirkin_: xorg -> Drivers/nouveau
23:32 MrBIOS-home_: got it
23:45 MrBIOS-home_: imirkin: filed, this look okay? https://bugs.freedesktop.org/show_bug.cgi?id=102135