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