09:08 pabs3: pmoreau: Linux 4.16 rc6 got into Debian experimental. I still get that GPU hang I mentioned a few days ago. I have a hang right now, is there a way to reset the GPU (I have SSH access)?
10:13 pmoreau: pabs3: There might be, using some PCI methods, but I am not sure how.
10:14 pmoreau: Do you have logs somewhere from the hang?
13:10 pabs3: pmoreau: I have everything from the systemd journal. is anything other than journalctl --dmesg of interest?
13:12 pabs3: pmoreau: https://paste.debian.net/hidden/7bfa5226/
13:17 pabs3: lspci -vv http://paste.debian.net/hidden/dff230fa/
13:21 pmoreau: pabs3: Ah, so it looks like you are hitting https://bugs.freedesktop.org/show_bug.cgi?id=105319
13:22 pabs3: hmm, ok. completely different (and vastly more ancient) GPU though
13:23 pmoreau: G98 vs GT216
13:23 pabs3: the hang it doesn't happen immediately. sometimes it works for hours
13:23 pmoreau: Both Tesla chips (though one v1 and the other v2)
13:23 pabs3: ah, ok
13:24 pmoreau: Are you in a position to try to bisect what commit introduced the regression?
13:24 pmoreau: *which
13:24 pabs3: wait, wasn't that patch mentioned at the end of the bug merged in rc6?
13:25 pabs3: it isn't my primary machine, so I guess. been a long time since did Linux builds though
13:25 pmoreau: It was. But I am not certain it did test the patch: sure he says “This patch [2] fixed my problem” but the next sentence is “I will test it”.
13:25 pmoreau: s/it did/he did
13:25 pabs3: hmm
13:26 pabs3: the other thing is I don't know where to mark the 'good' commit :)
13:26 pabs3: I think I got some hangs with the other kernel version I had before, 4.2
13:27 pmoreau: Ah :-/
13:27 pmoreau: So for you it’s not a regression in 4.16, but it was already an issue before that?
13:27 pabs3: yes. 4.15 definitely but I think also 4.2. I should re-test that
13:28 pabs3: been a while since I upgraded this box. mesa/etc are fairly old
13:29 pmoreau: There are some known issues with external screens on MCP79 (integrated Tesla chip), but it could be a different issue.
13:30 pabs3: this is discrete card, with monitor attached via DVI. ISTR it happens also with VGA
13:31 imirkin: pabs3: note that "hang" isn't a singular issue
13:32 pmoreau: I’ll try to plug in my G98 and my GT21x (can’t remember which one I have) over the weekend, but I won’t have time to try to fix it.
13:33 pabs3: ack
13:39 pabs3: trying 4.2
13:41 pabs3: hmm, some weird artefacts
13:44 pendingchaos: imirkin: the piglit tests should be submitted
13:46 imirkin: cool. i won't be able to look until tonight, i think
13:55 pabs3: ok 4.2 booted better this time, will see if it gets a hang
13:57 imirkin: the driver was rewritten in 4.3 btw
13:58 imirkin: (wow, skeggsb - good job. 10 full versions without a driver rewrite. i figured we were due by now :p )
14:03 pabs3: hmm, 4.2 works. but gets CPU lockup instead
14:10 mupuf: imirkin: :D
14:16 karolherbst: pmoreau: did you had a chance to check for the backlight regression?
14:19 karolherbst: imirkin: mind reviewing patches 1-7 of my last NIR series? Those tough common code and for me it makes sense if those actually get a review. Personally I don't care much about missing reviews in the _from_nir file, but everything else should get one.
14:19 imirkin: yeah ... i need to do that at some point
14:19 imirkin: karolherbst: got it all in a convenient branch somewhere?
14:20 karolherbst: yeah
14:20 karolherbst: nouveau_nir_v6: https://github.com/karolherbst/mesa/commits/nouveau_nir_v6
14:20 karolherbst: there are three additional patches: compile fix for my system + the two limm patches
14:21 karolherbst: thanks!
14:21 pmoreau: karolherbst: Mind refreshing my mind about that backlight regression?
14:21 karolherbst: pmoreau: stuff broke, so no backlight controls with nouveau being main
14:22 karolherbst: I guess it should show on your laptop with two nvidia gpus
14:22 pmoreau: No, because it is the gmux driver handling the backlight, not Nouveau.
14:22 karolherbst: pmoreau: uhh, I see
14:22 pmoreau: When did it break?
14:23 karolherbst: pmoreau: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c66c87dc9
14:23 imirkin: karolherbst: so it's probably obvious, but i likely won't have time until the weekend.
14:23 karolherbst: imirkin: no worries
14:23 imirkin: i.e. don't expect any miracles.
14:23 pmoreau: Wow, that’s a long time ago!
14:24 karolherbst: pmoreau: :D right
14:24 pmoreau: (Well, relatively speaking; I was expecting something more recent.)
14:24 karolherbst: it isn't common that you need backlight controls from nouveau though
14:24 karolherbst: there were some bug reports though
14:25 karolherbst: not sure if on the freedesktop bgzilla
14:25 karolherbst: mhh https://bugs.freedesktop.org/show_bug.cgi?id=100446 ?
14:26 karolherbst: I leave a comment
14:26 pmoreau: Is this only on Pascal or have you noticed it on other chipsets as well?
14:27 karolherbst: I tested on maxwell
14:27 pmoreau: Okay
14:27 karolherbst: the pascal issue might be a bit bigger though, no idea
14:28 pmoreau: Ah yes, I remember your fix now.
14:28 karolherbst: pmoreau: here is the RH bz bug: https://bugzilla.redhat.com/show_bug.cgi?id=1511786
14:32 pendingchaos: after modifying a few patches, should I repost the entire series on the mailing list or just the modified patches? and how should I do so?
14:33 imirkin: pendingchaos: in your case, probably the whole series. sometimes if you have, say, a 30-patch series, making a small change to one or two patches, you'd just remail those 2
14:34 pendingchaos: should I reply to "[Mesa-dev] [PATCH 0/4] Implement Various ..." or create a entirely new thread?
14:35 mupuf: pendingchaos: I would reply to the cover letter of the previous version
14:35 pendingchaos: reply to the previous cover letter with a new cover letter?
14:36 mupuf: pendingchaos: yes
14:37 pendingchaos: thanks
14:39 imirkin: meh. that stuff is overrated.
14:39 imirkin: some people try to be careful and all, i tend to not worry about it.
14:39 imirkin: i.e. just send and resend and not worry about threading
14:42 karolherbst: it doesn't matter in the inbox of the receiver anyway
14:42 pendingchaos: messed up the subject of the 4th patch
14:42 pendingchaos: hopefully that doesn't break anything
14:43 karolherbst: pendingchaos: usually you just send the patches as they are inside your git log
14:43 karolherbst: if you nee to modify the emails after git format-patch/send-mail you might want to fix it in yout git history directly
14:43 karolherbst: *your
14:44 karolherbst: pendingchaos: also you can do -v2
14:44 karolherbst: like git format-patch -4 -v2, then just send out the fourth patch or something
14:44 karolherbst: in your case
14:45 pendingchaos: cool, thanks
14:45 karolherbst: I tend to over use -$commit_count and should rather specify the base as a commit hash or branch
14:56 Vollstrecker: Hi, I read something about problems with multithreaded OpenGL, and in the bugreport I've found on that, there is a mention of llvmpipe which could solve the problem. I've checked how debian builds it's drivers, and llvmpipe etc. seems to be activated, but I don't find a way to use this one.
14:58 karolherbst: imirkin: I was wondering: is there a way to get the offset of the l[] memory space inside the shader? like reading some value out of c15 and you know where the local memory is located inside the global one?
15:03 feaneron: does nouveau implements gl_oes_egl_image ?
15:06 feaneron: (not sure if that question makes sense)
15:14 pendingchaos: It seems it implements GL_OES_EGL_image
15:14 pendingchaos: the state tracker seems to unconditionally enable it
15:15 pendingchaos: can someone with a GM200 GPU test the latest conservative rasterization patches?
15:15 pendingchaos: they can be found at https://github.com/pendingchaos/mesa/tree/nv-conservative-raster-v2 with the tests at https://github.com/pendingchaos/piglit/tree/nv_conservative_raster
15:16 pendingchaos: feaneron: it seems the state tracker unconditionally enables it, so yes
15:17 feaneron: right; yeah, i figured out i'm having a problem with glamor, but nouveau itself
15:23 imirkin_: (presumably GM20x would be sufficient for those conservative raster patches, not necessarily GM200 itself)
15:23 imirkin_: feaneron: glamor can trigger issues with nouveau. use xf86-video-nouveau for good times.
15:24 feaneron: nouveau is only used for my discrete gpu; the integrated gpu is intel
15:24 feaneron: and i'm on wayland
15:24 imirkin_: ah ok
15:24 feaneron: point is, xwayland requires that gl_oes_egl_image extension, but for some reason it's failing to find
15:25 feaneron: thus it's using the fallback llvm renderer
15:25 imirkin_: hmmm
15:25 imirkin_: should all be running on intel though, right?
15:26 imirkin_: or are you starting up XWayland with DRI_PRIME=1?
15:28 pendingchaos: sorry, I thought GM200 referred to GM20x and didn't realise it was a specific GPU
15:37 karolherbst: pendingchaos: I can check on my GP107
15:39 pendingchaos: I'm looking for Maxwell in particular
15:39 karolherbst: ahh, k
15:44 feaneron: imirkin_: doesn't matter. xwayland falls back to software rendering on startup.
15:44 imirkin_: cool. so not nouveau-related then.
15:44 feaneron: not at all :)
15:47 imirkin_: my favorite kind of problem :)
15:48 feaneron: Lyude: did your reclock work land already?
15:51 Vollstrecker: Soryy network problems. Did I miss something
15:56 imirkin_: Vollstrecker: LIBGL_ALWAYS_SOFTWARE=1
16:02 karolherbst: pmoreau: void SPIRV::SPIRVLifetime<OC>::validate() const [with spv::Op OC = (spv::Op)256]: Assertion `Size == 0 && "Size must be 0"' failed.
16:02 karolherbst: any idea?
16:02 Vollstrecker: With that witch I activate llvmpipe? I use it for kontact already. This works systemwide?
16:03 imirkin_: if you stick it in your environment, sure.
16:03 imirkin_: you can also just remove nouveau_dri.so
16:03 imirkin_: although it might come back with a system update
16:05 Vollstrecker: I tried removing this one, but then I just got a message that it wasn't found.
16:05 karolherbst: pmoreau: it is related to having "volatile float" as a stack variable
16:07 Vollstrecker: LIBGL_ALWAYS_SOFTWARE=1 vainfo gives /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so and LIBGL_ALWAYS_SOFTWARE=1 vdpauinfo doesn't tell me, or at least I can't find or interpret it.
16:09 karolherbst: LIBGL_ is really only for libgl ;)
16:10 karolherbst: there is VDPAU_DRIVER to select the vdpau driver
16:10 karolherbst: there should be something for vaapi as well
16:14 pmoreau: karolherbst: I haven’t played much with those OpLifetime* operands.
16:16 Vollstrecker: I've checked the options I have for LIBVA_DRIVER_NAME and for VDPAU_DRIVER, it seems that nouveau is the only choice
16:20 Vollstrecker: I tried with va_gl driver for vdpau, this works, but I'm not sure if it's just reversing the effects.
16:20 karolherbst: pmoreau: weird
16:21 karolherbst: pmoreau: it is kind of needed for those math bruteforce thest
16:21 karolherbst: *tests
16:21 karolherbst: I am sure they worked before
16:21 karolherbst: at least when I was working on your spirv stuff
16:21 imirkin_: Vollstrecker: there is no llvmpipe provider for video decoding stuff
16:22 Vollstrecker: So just for the rendering?
16:22 imirkin_: yes.
16:22 imirkin_: it provides a GL / DX-compliant software rasterization pipeline
16:22 Vollstrecker: How can I check if this gets used? Or configure to do so.
16:22 imirkin_: implemented using various SSE/etc primitives and llvm.
16:22 pmoreau: karolherbst: Ah, that could be because you were using a branch where I implemented those OpLifetime* opcodes in llvm-spirv, whereas the new branch uses the code that was in SPIRV-LLVM.
16:23 karolherbst: pmoreau: I see
16:23 Vollstrecker: I think this is what I tried to do in the beginning, I just went the wrong road.
16:24 pmoreau: karolherbst: Which version of llvm-spirv are you using?
16:26 karolherbst: pmoreau: yours
16:26 pmoreau: rebase2_integrate_with_mesa, something like that?
16:27 karolherbst: yeah
16:29 pmoreau: karolherbst: Could you break on that assert and check which of the two conditions in the if-statement are false?
16:31 karolherbst: pmoreau: !Obj->getType()->getPointerElementType()->isTypeVoid()
16:32 pmoreau: (The two conditions do match what the spec says, so the error is somewhere earlier.)
16:32 pmoreau: Okay
16:33 pmoreau: And which opcode is it: *Start or *End?
16:34 pmoreau: Oh, and what is the backtrace for the assert as well, please.
16:38 pmoreau: karolherbst: (And the LLVM IR while you’re at it :-D)
16:47 karolherbst: Start
16:48 karolherbst: pmoreau: https://gist.github.com/karolherbst/d010aa10aaf87ffd8d8666dbac14f6ec
16:48 pmoreau: Thanks
16:49 pmoreau: I guess the size is 4?
16:49 pmoreau: 'Size' in the assert
16:51 pmoreau: Or maybe 32
16:51 pmoreau: Nope, 4, I made up my mind. :-)
16:53 karolherbst: yeah
16:56 pmoreau: karolherbst: One sec, writing a small possible fix
16:59 pmoreau: karolherbst: I think this should fix it: https://paste.fedoraproject.org/paste/58lwcmysGwEVVwc-LUNIsw
17:02 pmoreau: karolherbst: Hum, it should be `!BM->hasCapability(CapabilityAddresses)` in both cases, I made a small mistake.
17:02 karolherbst: pmoreau: ../lib/libSPIRV/SPIRVModule.cpp:624: virtual SPIRV::SPIRVEntry* SPIRV::SPIRVModuleImpl::getEntry(SPIRV::SPIRVId) const: Assertion `Loc != IdEntryMap.end() && "Id is not in map"' failed.
17:03 pmoreau: What’s the backtrace of that one?
17:04 karolherbst: none if I call llvm-spirv directly :(
17:05 karolherbst: ahh, SPIRV::SPIRVModuleImpl::getEntry
17:05 karolherbst: pmoreau: https://gist.github.com/karolherbst/7d93f54dd29930500f128d06f06fe559
17:06 pmoreau: Oh, I thought it was a due error you were getting due to my patch.
17:06 karolherbst: OpEntryPoint Kernel %6 "IsTininessDetectedBeforeRounding"
17:06 karolherbst: OpFunction %void None %5
17:06 karolherbst: looks okay
17:06 karolherbst: *%6 = OpFunction %void None %5
17:07 pmoreau: So my patch fixed your issue?
17:07 pmoreau: (I’m not 100% sure we should be doing that, but it will do for now :-))
17:08 karolherbst: pmoreau: duh... we don't get a spirv debug file at that time
17:08 karolherbst: could we dump the spirv like directly after we have it?
17:08 pmoreau: Well, it’s kinda failing while generating it, isn’t it?
17:09 karolherbst: ohh wait
17:09 karolherbst: yeah, right
17:09 karolherbst: my mistake
17:09 pmoreau: So the lifetime patch is working?
17:09 karolherbst: seems that way
17:09 pmoreau: Okay, I’ll push it to my branch, and we can discuss whether it is the proper fix once we have that shiny new repo.
17:10 Lyude: feaneron: you mean powergating
17:10 Lyude: ?
17:11 karolherbst: pmoreau: sometimes with the C++ code around I think C++ was a mistake :(
17:12 pmoreau: I am not a fan of the SPIRV-LLVM code, but I think it is mostly due to their usage of macros than their usage of C++.
17:13 pmoreau: (Patch pushed)
17:13 karolherbst: pmoreau: I was more refering to the use of <<
17:14 pmoreau: Ah
17:14 karolherbst: ../lib/libSPIRV/SPIRVModule.cpp:1340 is quite the highlight
17:19 pmoreau: It seems weird that the ID would be present in NamedId, but not in the IdEntryMap.
17:23 feaneron: Lyude: that's what i meant, sorry
17:27 karolherbst: mhh getting "Max SendQ exceeded" kind of looks like a bot fetching list of all channels or something, no?
17:27 karolherbst: I mean if getting that many?
17:27 karolherbst: no?
17:28 karolherbst: seems like bad luck in this case though
17:30 Lyude: feaneron: it should be landing in 4.16
17:31 feaneron: Lyude: that's great news! i had the impression it was a 4.18+ thing. kudos for that
17:32 Lyude: mhm- that is probably the version we will start to enable it by default it (and hopefully I should also have support for more generations by then)
17:33 Lyude: right now it is behind a kernel param, nouveau.config=NvPmEnableGating=1
17:33 feaneron: that's fine. i'm gonna test it and eventually report issues if something goes wrong
17:34 feaneron: what are the supported generations?
17:34 Lyude: kepler 1 and 2
21:04 skeggsb: karolherbst: i think there's a system value for the lmem window base address
21:09 imirkin_: there is.
21:22 karolherbst: skeggsb: ahh
21:22 imirkin_: why do you need it?
21:22 karolherbst: I was just curious
21:22 imirkin_: i couldn't think of any useful reasons to use it
21:22 karolherbst: I could
21:22 karolherbst: reverse engineering
21:23 karolherbst: maybe there is some odd caching through l[]
21:23 imirkin_: of what?
21:23 karolherbst: maybe some perf differences
21:23 karolherbst: might be interesting to figure that out
21:23 karolherbst: to somebody
21:23 karolherbst: maybe there is indeed some weird caching going on
21:26 pmoreau: skeggsb: Did you see those mem errors since 4.15 on Tesla? https://bugs.freedesktop.org/show_bug.cgi?id=105687 and it is apparently not fixed by the MMU align_down patch.
21:26 pmoreau: I’ll try to reproduce and bisect, but any ideas what it could be?
21:27 karolherbst: pmoreau: do you know if all builtins are 64 bit with llvm-spirv?
21:28 pmoreau: I don’t know.
21:31 karolherbst: pmoreau: but mhh theoretically you can define them as 64 bit in spirv, no?
21:32 karolherbst: pmoreau: you can even declare struct members as builtins :(
21:34 karolherbst: pmoreau: I think llvm-spirv actually makes it depending on the physical memory thing
21:35 pmoreau: karolherbst: I hope it doesn’t. At least some of them are 64-bit, regardless of the size of the pointers.
21:36 karolherbst: yeah.. I will check it out
21:49 imirkin_: skeggsb: any objection to auto-linking at 12bpc over hdmi if the hw and monitor allow it?
21:49 imirkin_: (always, globally)
22:52 stoatwblr_: imirkin, would you take a quadro p600 DVI for $214+tax?
22:52 imirkin_: no
22:52 imirkin_: maybe if you removed the 2
22:52 stoatwblr_: that's uk wholsaler price.
22:53 stoatwblr_: noted
22:53 imirkin_: what would this be for?
22:53 imirkin_: (i have no context. i try not to spend more than $10 per board.)
22:53 stoatwblr_: replacing the NV440
22:53 imirkin_: and what's the desired setup?
22:53 imirkin_: 4x dvi?
22:53 stoatwblr_: 4 headed desktop, with an eye to moving to 4k heads later
22:54 imirkin_: that's a lot of heads
22:54 imirkin_: ok, so really you want DP
22:54 stoatwblr_: the outputs are mini DP with dp-DVI adaptors tossed in.
22:54 imirkin_: and you'd like to use this with nouveau?
22:54 stoatwblr_: 2GB ram, pci3x16
22:55 stoatwblr_: yes
22:55 imirkin_: realistically, i'd recommend AMD
22:55 stoatwblr_: ok
22:55 stoatwblr_: do and have any equivalent workstation card?
22:56 imirkin_: wow, these guys are not messing around. https://www.newegg.com/Product/Product.aspx?Item=9SIA2F83MX9921
22:56 stoatwblr_: zoinks shaggy!
22:57 imirkin_: you should ask in #radeon - i'm not up on the latest
22:57 imirkin_: i can say with some certainty that you'll get better support from amd than you will from us.
22:58 stoatwblr_: yeah, nvidia do seem to be fairly grudging with the linux support, it'd like tossing a few bones now and then.
22:58 imirkin_: (us = nouveau collective)
22:58 stoatwblr_: you can only be as good as docs that nvidia release plus reverse engineering
22:59 imirkin_: mostly RE
22:59 HdkR: Pretty much entirely RE, not much documentation comes out...
22:59 imirkin_: they did put out a handful of things recently
22:59 imirkin_: some of which may be interesting
23:00 stoatwblr_: interestingly NE is $50 more expensive in the uk than usa
23:01 imirkin_: brexit, man
23:02 stoatwblr_: never been about brexit. at one point usa stuff was more in £ than the $ price
23:02 HdkR: Oh? What sort of documentation was released?
23:02 stoatwblr_: and that was when $1 was $2
23:03 imirkin_: just kidding :)
23:03 stoatwblr_: it's about local importers putting 200% markups on things
23:03 imirkin_: HdkR: well, they've been releasing the display classes, which is pretty useful to not hanging the display
23:03 imirkin_: HdkR: they also recently released some vbios tables we hadn't decoded
23:03 HdkR: ah nice
23:05 HdkR: Not much but at least there is a bit
23:05 stoatwblr_: I can get a firepro W4100 for about the same as the quadro p600 dvi, but dp-dvi are extra
23:06 imirkin_: make sure you get something that's at least GCN
23:06 imirkin_: otherwise you'll be in for a world of pain
23:06 stoatwblr_: gcn?
23:06 imirkin_: graphics core next? something like that
23:07 imirkin_: southern islands or later
23:07 stoatwblr_: 2011, should be in nearly everything by now.
23:10 stoatwblr_: sheesh, 159 in usa retail, 220 academic pricing in uk.