00:58mlankhorst: imirkin: well I just made the entire state invalid on a context switch, my intention was to send the full state after each flush
00:58mlankhorst: which means no locking required. :p
00:58imirkin: mlankhorst: imho i'd rather take it one step at a time
00:58imirkin: mlankhorst: step 1: just give each context its own pushbuf and don't fix anything else
00:59imirkin: then we can worry about subsequent steps at a later date
01:35pmoreau: skeggsb: Nouveau crashes while being mmiotraced, during VBIOS retrieval through PRAMIN https://phabricator.pmoreau.org/P33
01:36pmoreau: (tested on top of 4.3-rc1)
03:44mlankhorst: imirkin: that was my first commit too..
03:45mlankhorst: gallium/nouveau: decouple nouveau_fence implementation from screen
03:45mlankhorst: gallium/nouveau: move pushbuf and fences to context
03:46mlankhorst: imirkin: I still have those in my branch
03:55pmoreau: curro: I guess this is the latest version of your work on getting compute support for NV50: https://github.com/curro/mesa/commits/nv50-compute
08:24qq[IrcCity]: http://nouveau.freedesktop.org/wiki/KernelModuleParameters/#config : The values are all boolean (0/1) except for NvBios which is a string.
08:24qq[IrcCity]: but: NvClkMode: Force a particular clock level on boot. Note that this does not parse hex, so for clock mode f, pass in 15.
11:25karolherbst: pmoreau: did you create the trace on nouveau?
11:25pmoreau: karolherbst: I would have, if Nouveau didn't crashed while mmiotracing
11:26karolherbst: does it always happen?
11:26karolherbst: I know I had issues with the blob a year ago
11:27pmoreau: Out of 3 times, 3 times
11:27karolherbst: did you change your kernel?
11:27pmoreau: With two different kernel versions and Nouveau versions
11:27pmoreau: Didn't had time to try a bisect
11:27karolherbst: do you have mmiotrace support always in your kernel or do you enable it?
11:28pmoreau: Always on
11:28pmoreau: No sorry
11:28pmoreau: I echo mmiotrace > current_tracer
11:28karolherbst: "mmiotrace: unexpected secondary hit for address 0xffffc90002619f04 on CPU 0."
11:28pmoreau: As I have always done, except it crashed yesterday
11:33karolherbst: but mmiotrace is unhappy about something
11:34karolherbst: pmoreau: this is from the blob: https://gist.github.com/karolherbst/75317fa9a5e452af012a
11:35karolherbst: you can run nouveau and check if some other regs are different
11:35karolherbst: here: https://gist.github.com/karolherbst/75317fa9a5e452af012a#file-gistfile1-txt-L758-L759
11:35karolherbst: is the first difference we found yesterday
11:35karolherbst: you hade something like 0x2.. in this reg
11:36pmoreau: I'll grab some food, finish rebasing some 4 years old patches, and then I'll be ready to mess with my system. :-)
11:36karolherbst: I would check all PLLs first
11:36imirkin: qq[IrcCity]: hope it's clearer now
11:38karolherbst: or first the stuff done inside the hwsq script or whatever
11:38karolherbst: but you should start from the bottom ;)
11:38karolherbst: pmoreau: you will see that some regs modified in the script are read back later
11:39karolherbst: pmoreau: I generated this snippet through "demmio -f G96+MCP79_340.76-5_reclocking.mmio.xz | grep -A9418 -e "MARK 113.646459 Clocking to highest level" | grep -v -e PTIMER -e PCOUNTER -e PPCI -e PDISPLAY -e INTR_EN_HOST -e "\[1\]" -e "PMC.*ID.* => " -e SLEEP -e PFIFO -e PBUS"
11:39karolherbst: in case you want to remove/add stuff
11:52karolherbst: pmoreau: usually poking new values into the regs isn't the best thing todo, it could mess up your card immediatly
11:52karolherbst: so you should rather hardcode them and check if 0f is more stable
12:56RSpliet: pmoreau: https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/646220c92decd07343f0ff770db64d08be66f90c
12:56RSpliet: that one is for you ;-)
12:56RSpliet: oh, let me fix that first
12:56RSpliet: haven't given it a test drive
12:57pmoreau: RSpliet: Is it Christmas already? O:-)
12:57pmoreau: RSpliet: Almost done with the rebase, I'll test it afterwards.
12:58RSpliet: no, Saint Nicholas rather
12:58RSpliet: christmas will come after I took another proper look at 0x100710
12:58pmoreau: Eh eh! :-)
12:58RSpliet: but that patch (or rather, the updated one I pushed seven seconds ago) should stop HWSQ from timing out
13:08pmoreau: Nice! :-)
13:08pmoreau: Though it only happened when trying to reclock from the MCP79
13:10RSpliet: well, there's two reasons I can imagine HWSQ timing out
13:10RSpliet: one is endless waiting for a never arriving VBLANK signal
13:10RSpliet: the other one is the GPU going tits up
13:17karolherbst: pmoreau: ohh so your X server runs again on nouveau?
13:17karolherbst: as I asked before, could you test glxgears with the fixed value?
13:18karolherbst: usually glxgears only uses some gpu core stuff and if the core is stable enough, it should work even if something is odd with the memory
13:18pmoreau: karolherbst: I did test it, sorry for not reporting back.
13:19pmoreau: karolherbst: So, it *worked* with some flickering, and then the geards were gone
13:19karolherbst: mhhh okay
13:19karolherbst: could you test with RSpliet patch again?
13:19pmoreau: And the wm wasn't refreshing as it should have
13:19pmoreau: Will do that in a second
13:19karolherbst: might be related
13:20karolherbst: pmoreau: did you restart the wm?
13:20RSpliet: pmoreau: no rush, I'm first seeing if I can find any reason why your 100710 is so much different from what I'd expect :-)
13:21pmoreau: karolherbst: Well, not while I was running glxgears.
13:22pmoreau: RSpliet: I still have some Mesa stuff to compile
13:24karolherbst: pmoreau: ohh so after glxgears the deskopt was useable again?
13:25pmoreau: karolherbst: I don't really remember, but it wasn't probably in a good state either as I decided to go back to tty and reboot the laptop.
13:26pmoreau: I should still have the dmesg
13:27pmoreau: The only error I had was: "nouveau 0000:02:00.0: fifo: DMA_PUSHER - ch 2 [systemd-logind] get 0020277000 put 002001112c ib_get 00000017 ib_put 0000001c state 80000000 (err: INVALID_CMD) push 00406040"
13:28karolherbst: why would logind try something with the gpu
13:28imirkin: pmoreau: that's fairly common on tesla apparently
13:28imirkin: karolherbst: because systemd is fun
13:28imirkin: why *wouldn't* pid 1 need to use opengl/opencl
13:28karolherbst: I don't think this is gl related at all
13:28karolherbst: I know that there is some backlight handling
13:28karolherbst: also some suspend hooks should also be there for various stuff
13:29pmoreau: maybe running X as the user?
13:29karolherbst: pmoreau: ohhhh
13:29imirkin: well, unless you think they're sending nouveau pushbuf commands by hand, mesa is the only lib that produces them
13:29karolherbst: still it should be X then
13:29imirkin: and the xf86-video-nouveau ddx
13:29imirkin: but presumably that's not it either, that normally runs in the X process
13:30karolherbst: ohhh, logind claims ttys
13:31pmoreau: imirkin: Have you used / played with clover?
13:31karolherbst: imirkin: could it be anything tty related?
13:31imirkin: pmoreau: no
13:31imirkin: karolherbst: not in that process space
13:31karolherbst: I see
13:32karolherbst: loginds also has some event fds open, but nothing else could produce a something like that :/
13:33pmoreau: imirkin: Ok. I have some troubles with the convert_to_tgsi function, which expects to find a COMP in the kernel source, for some reason. And goes out-of-bounds otherwise.
13:34imirkin: pmoreau: it wants TGSI input
13:34imirkin: pmoreau: there's no OpenCL C -> TGSI adapter
13:34imirkin: pmoreau: so your opencl "source" has to be TGSI
13:35imirkin: but you should also create a new ir type for spir-v
13:35imirkin: the PIPE_SHADER_CAP_PREFERRED_IR thing or whatever
13:35pmoreau: Oh, ok. But it's weird to have two functions with the same name (one for LLVM and one for TGSI), that take the same input, but expect it in different format
13:36imirkin: you're somewhat missing what's going on
13:36imirkin: the llvm one wants llvm ir, the tgsi one wants tgsi
13:36imirkin: which is expected
13:37imirkin: however there's a opencl c -> llvm ir adapter
13:37imirkin: which feeds the opencl c into a llvm frontend which spits out bitcode
13:37imirkin: whereas the opencl c -> tgsi adapter is just a strcpy :)
13:37pmoreau: the LLVM one is happy if I feed it with source code
13:37imirkin: which is why there's no opencl support on nouveau
13:37imirkin: there's a conversion that happens
13:37imirkin: to get bitcode
13:38imirkin: and then you're feeding the bitcode into the driver
13:38pmoreau: compile_program_llvm's source argument is the kernel source code, and the function works
13:38imirkin: basically convert_to_tgsi *should* take the opencl c code and produce tgsi
13:38imirkin: but instead it just does a strcpy
13:39imirkin: so the "opencl c" code you feed it has to just be TGSI
13:39imirkin: perhaps you've noticed how opencl isn't supported on nouveau?
13:39imirkin: why do you think that is if there were a way to go from opencl c -> tgsi?
13:40pmoreau: Then why have a function inside clover which is not *supposed* to work?
13:40imirkin: it's a fake impl
13:40pmoreau: Better to have nothing
13:40imirkin: r600/radeonsi take llvm bitcode
13:40imirkin: no, coz this lets you deal with the driver end of the opencl stuff
13:40imirkin: and/or compiler
13:41imirkin: without worrying about one of the steps
13:41imirkin: also curro started a tgsi backend in llvm to spit out tgsi at the end
13:41imirkin: but never completed it
13:42imirkin: i believe that calim used versions of this to do the initial compute support in nouveau
13:45karolherbst: pmoreau: or add a nouveau backend to llvm :p
13:45pmoreau: Hopefully, when SPIR-V final spec is released, the LLVM IR -> SPIR-V frontend will be released
13:46imirkin: karolherbst: probably not a good idea... would take a *ton* of dev time, and vastly complicate just about everything i can think of
13:46karolherbst: I know :D
13:46karolherbst: so this is a taks for the time, where the nvidia chips get completly different?
13:47pmoreau: karolherbst: As long as previous versions of OpenCL can be transformed into SPIR-V, we can avoid it
13:47imirkin: if i were handed a fully working llvm backend that output the proper stuff, i still wouldn't want to take it
13:47karolherbst: and why is that?
13:47imirkin: llvm makes it impossible to ship fixes, complicates debugging, etc
13:47karolherbst: I see
13:47karolherbst: but they started to ship fixes
13:48imirkin: imo it's a huge mistake that the radeonsi guys use it
13:48karolherbst: there are now point releases
13:48imirkin: karolherbst: if i commit a fix *today*, how long will it be before users get it?
13:48imirkin: for mesa, there are point releases every 2 weeks, which distros generally pull in
13:49imirkin: for llvm, i have to (a) deal with both old and new llvm versions in mesa, and (b) they do releases once every 100 years
13:49qqz: why is there no support for USB3.0 UHD graphics cards under Linux?
13:49imirkin: qqz: wrong channel?
13:50qqz: which one to go?
13:50imirkin: qqz: i don't think nvidia ships any USB3.0 adapters, UHD or not
13:50karolherbst: imirkin: I think 3 months?
13:50karolherbst: imirkin: yeah I get what you mean
13:50karolherbst: didn't thought about that way
13:51karolherbst: but the question is rather how much "easier" is it to use llvm?
13:51imirkin: qqz: dunno. if you want to bitch about lack of support for some proprietary undocumented hw, i doubt there's a chan for that.
13:51imirkin: karolherbst: well, it'd be a huge time investment to learn it. given that it's taken the radeonsi guys at least 2 years to get their GCN stuff really working, and they are doing this fulltime... not a good sign.
13:51qqz: imirkin: it would be a good question if there is an nvidia or ati graphics chip inside external graphics cards like this one: http://www.ebay.de/itm/I-TEC-USB-3-0-4K-Display-Video-Adapter-ext-Grafikkarte-/141723987317?hash=item20ff686d75
13:52karolherbst: imirkin: right
13:52karolherbst: qqz: look it up?
13:52imirkin: qqz: usually it's displaylink
13:52karolherbst: there is no gpu in it
13:52imirkin: afaik they're the only ones that make this sort of hw
13:53karolherbst: I think this thingy is just a "display port" and uses the built in gpu for that
13:53karolherbst: I think there was patches for that for linux recently
13:53imirkin: karolherbst: displaylink is a company
13:54karolherbst: imirkin: I know i know
13:54imirkin: which makes USB display adapters
13:54karolherbst: I think there were patches for these recently
13:54imirkin: they recently released drivers allowing their proprietary blob to hook into the kernel to provide drm devices
13:54imirkin: sort of like fuse, but for drm
13:54karolherbst: udl is the driver name
13:55imirkin: that driver only supports USB2 devices
13:55karolherbst: seems like it uses DRI_PRIME
13:55karolherbst: ohh right
13:55imirkin: their USB3 devices use some sort of encryption
13:55karolherbst: seems like it uses the modesetting ddx for those
13:56imirkin: see http://airlied.livejournal.com/ for some experiments with it
13:56karolherbst: qqz: maybe this helps too? https://wiki.archlinux.org/index.php/DisplayLink
13:56karolherbst: it should work when you have a nvidia card using nouveau
14:41qqz: nice to hear, karolherbst.
14:41qqz: good n8, all.
14:41RSpliet: pmoreau: okay, I figured out most of the differences with the 0x100710 register
14:42RSpliet: apart from the 0xe on the end... I have some theory, but I can't test it :-P
14:42RSpliet: so to keep things holiday themed... I'd say it's halloween!
14:44pmoreau: Do you want me to test your theory?
14:45RSpliet: can you successfully fake a VBIOS?
14:46RSpliet: and well, not trace NVIDIA, but just run it and peek 0x100710 in any frequency
14:46pmoreau: I can try at least to fake
14:46RSpliet: pmoreau: or is that not working with your dual-GPU set-up
14:46pmoreau: I have that data already
14:46pmoreau: Never tried, so I can't say :-)
14:46RSpliet: right, okay
14:47RSpliet: nvafakebios kind of depends on PRAMIN, which might fail if the G96 is powered off on boot
14:47pmoreau: It is not powered off on boot
14:47RSpliet: oh good!
14:49RSpliet: so what I'd like you to try, is run with a fake bios with byte d3de set to 02
14:49RSpliet: for the G96 that is
14:50RSpliet: hmm, or actually, do that for d3de and d404
14:50pmoreau: Grrr... For some reason Mesa and some other soft are failing to properly detect my llvm version
14:50imirkin: pmoreau: just disable llvm
14:50imirkin: you don't really need it
14:50RSpliet: if that causes 0x100710 to return 310 instead of 31e, then we're good :-P
14:51pmoreau: imirkin: Well, at least I could explore a bit how clover is interacting with Nouveau, whereas the tgsi path is a right dead-end. :D
14:51imirkin: pmoreau: it's not
14:52imirkin: pmoreau: the llvm path produces amd-specific bitcode
14:52imirkin: pmoreau: it could be altered to generate SPIR-V though
14:52imirkin: pmoreau: which would mean specifying a diff target for llvm... should be quite simple assuming llvm supports it
14:52karolherbst: pmoreau: what is ram->mr ?
14:53karolherbst: RSpliet: I meant you :D
14:53pmoreau: imirkin: At least, it didn't crash when taking the kernel code, and it tried to get compute_params from Nouveau, tried to call the launch_grid() from Nouveau, which made it easier to find out which bits to fill in :)
14:53karolherbst: there is a note about this in the source
14:53karolherbst: but I couldn't see which reg it is
14:53imirkin: pmoreau: fyi there's a branch somewhere that implements a lot more of the nv50 compute bits
14:53imirkin: either curro or... someone else
14:53imirkin: plombo maybe?
14:53imirkin: [Bryan Cain]
14:54pmoreau: imirkin: khronos or LunarG is working on a LLVM IR <-> SPIR-V compiler, and they will open-source it. But they will most likely wait until the final draft is published
14:54pmoreau: yeah, I found curro's branch. but... it is a bit old :)
14:55pmoreau: Though, I managed to partly get it compile on a recent Mesa
14:55karolherbst: pmoreau: would you like to peek 0x1002c4 and 0x1002cc on nouveau at 0f
14:56pmoreau: karolherbst: Sure, just going to generate the fake bios and reboot
14:58RSpliet: karolherbst: it's the eMR1 value
14:58RSpliet: well documented in GDDR3 spec sheets
14:58RSpliet: generated in gddr3.c
14:59RSpliet: and for pmoreau's G96 it's correct
14:59RSpliet: 0x1002cc is probably not going to buy you any information
14:59pmoreau: RSpliet: When should I load the fake vbios? Before loading Nouveau, on the preceeding boot?
14:59RSpliet: pmoreau: err... I was hoping you had the blob ready :-P
15:00RSpliet: but yes, a VBIOS must be faked prior to loading the driver
15:00pmoreau: I can load the blob as well
15:00RSpliet: that'd be great!
15:01pmoreau: So fake VBIOS and load the blob after that?
15:01pmoreau: And peek 100710 on the same run or a separate one?
15:01RSpliet: same run, various perflvls
15:01RSpliet: the lower ones are the important ones
15:02RSpliet: peek 0x1002c4 along side them if you can, just to verify the VBIOS change took effect :-)
15:02RSpliet: if the last digit of 0x1002c4 is an 8, it's good
15:04karolherbst: the blob writes 0x100088 into it
15:06karolherbst: I don't see how nouveau can mess this up actually
15:06RSpliet: probably 10XXX0 for the lower levels
15:06karolherbst: I just wanted to check all these "XXX" comments first on the source
15:07RSpliet: which XXX in particular are you looking at?
15:07RSpliet: oh, that's kepler-only
15:07karolherbst: how so
15:07karolherbst: ohh 0x20
15:08karolherbst: kepler has gddr3?
15:08RSpliet: probably not
15:08RSpliet: this is likely to be copy-pasta
15:08pmoreau: 03: 0x100710=0x31e, 0x1002c4=1000c8
15:08karolherbst: on 0f?
15:08RSpliet: pmoreau: thanks! so much for my theory :-D
15:08pmoreau: 05: 0x100710=0x31, 0x1002c4=0x10088
15:09RSpliet: eh wait
15:09RSpliet: 0x31 or 0x310?
15:09RSpliet: or 0x31e? :-D
15:09pmoreau: 0f: 0x100710=0x70, 0x1002c4=0x100208
15:09pmoreau: 0x31e, you're right
15:09karolherbst: another difference
15:09karolherbst: 0x1002c4 this is 0x100088 on the blob
15:09karolherbst: on of
15:10RSpliet: karolherbst: this *is* the blob
15:10pmoreau: and 0e: 0x100710=0x70, 0x1002c4=0x100208
15:10karolherbst: then I got the wrong part from the trace
15:11karolherbst: pmoreau: you could check if the values are the same with nouveau
15:11RSpliet: karolherbst: MR values are fine
15:11RSpliet: I already verified those
15:11RSpliet: and timings
15:12karolherbst: pmoreau: would you like to nvapeek your entire gpu? :D
15:12karolherbst: mhhh, sadly tracing nouveau doesn't work yet for you
15:12imirkin: pmoreau: ok, just wanted to make sure you were aware of the work that was already done
15:12RSpliet: karolherbst: it might be better if you leave this to me, most of the stuff I can reproduce on my (well, pmoreau's, but it's in my PC) G94
15:13pmoreau: karolherbst: last time I tried, the laptop just froze!
15:13karolherbst: ohh okay
15:13karolherbst: yeah then it is easier I guess
15:15pmoreau: imirkin: No problem :-)
15:15RSpliet: I appreciate you thinking along though, don't get me wrong :-)
15:16karolherbst: yeah I know what you mean
15:17karolherbst: I am somtimes _overenthusiastic_ with helping, that's all
15:17karolherbst: so will tackle pcie speed changes for fermi then
15:18imirkin: RSpliet: fwiw i have a G92 trace that touches 100da0
15:19airlied: pmoreau: get llvm to spit out nvptx and feed that into nv50 :-)
15:19imirkin: RSpliet: but no g84/g86 traces that do. could be coincidence.
15:19airlied: might be the easist translation
15:19imirkin: airlied: unlikely
15:19airlied: even nvptx->tgsi might be easier
15:19airlied: than llvm->tgsi
15:20airlied: beignet was doing that at some point, not sure if they still do
15:20imirkin: airlied: ptx has a *ton* of random crap in it =/
15:20airlied: imirkin: does the llvm compiler produce it it?
15:20airlied: produce the random crap
15:21karolherbst: ohh my nouveau master indeed comiles against 3.19, good to know though
15:21imirkin: airlied: tbh i've never tried it :)
15:21imirkin: i'm kinda allergic to llvm
15:22karolherbst: anything wrong with that PR so far? https://github.com/envytools/envytools/pull/21
15:23karolherbst: until I figure more stuff out, this is the most I can do about those
15:23imirkin: <reg32 offset="0x1c0" name="UNK1">
15:23RSpliet: imirkin: thanks, that's good to know
15:23imirkin: probably want UNK1C0 or something
15:25karolherbst: updated: https://github.com/envytools/envytools/pull/21/files
15:25karolherbst: imirkin: any good name for that unk so far?
15:25karolherbst: this seems like a cap reg for various stuff
15:25karolherbst: or what the card actually can support
15:26karolherbst: but then this LNK_CAP_SPEED is writeable
15:27RSpliet: pmoreau: okay, please go and test my tree (or at least the patches inside :-))
15:27RSpliet: force-pull, I do overwrite my history
15:32imirkin: RSpliet: there's no way that stuff is right... gotta be junk in the vbios
15:32karolherbst: I am silly
15:33RSpliet: imirkin: vbios is full of junk, but what are you referring to in particular?
15:33karolherbst: returning -EINVAL in a function with u8 return type makes a lot of sense
15:33imirkin: RSpliet: nvkm_hwsq_wait(hwsq, head_sync ? 0x3 : 0x1, 0x0); -- is that right? should this be ? 0x2 : 0x1
15:33imirkin: RSpliet: oh, just all your chipset checks
15:33imirkin: RSpliet: i bet they're all just various vbios bits
15:34RSpliet: imirkin: the hwsq_wait_vblank values I got from envydis/hwsq.c
15:34imirkin: RSpliet: oh ok. seems weird that 0x3 is for head 1
15:34imirkin: RSpliet: i would have guessed that head 1 would be 0x2
15:34RSpliet: 0x2 is CRTC0_HBLANK
15:34imirkin: and 0x3 is "both" heads, which will never happen
15:35imirkin: good to know :)
15:35RSpliet: for the odd moment you want to wait for HBLANK yes
15:35RSpliet: anyway, as far as the chip checks go... I've seen it happen on NVA3/5 vs NVA8 too
15:36imirkin: yeah.... nva8 has that weird thing
15:36RSpliet: I verified this stuff against my G94
15:37RSpliet: I can't say for sure whether the checks are 100% correct, but they seem to be right between G94 and G...200
15:37RSpliet: of course G84 could bring all sorts of fun I haven't seen
15:37imirkin: well tobijk has a g86 laptop
15:39RSpliet: one thing I did notice is that NVIDIA seems to scan all the rammap entries, and for every feature that's like always disabled, it's not going to bother even reading the value
15:39RSpliet: or masking away
15:39imirkin: iirc i sent you his traces, he has them going between each level on his board
15:39RSpliet: for instance, on my G94, 0x100710[3:1] are untouched and I can set them to whatever, until I set rammap_04_04 high in my VBIOS for one entry, in which case it suddenly masks it out
15:40RSpliet: in other words, we can't rely on the absence of registers as an indicator when a certain feature was introduced
15:40RSpliet: *absence of registers in trace
15:40pmoreau: RSpliet: Patches compiled, going to reboot. I guess I shouldn't fake the vbios before loading Nouveau.
15:40imirkin: that's why the chipset checks seem potentially random
15:40RSpliet: pmoreau: rather not no :-)
15:41imirkin: i realize it might be the best you can do with limited hw
15:41RSpliet: well, the chipset checks are added in cases where the same VBIOS value had a different value on NVA0 than it had on NV94
15:42RSpliet: *G200, G94 :-P
15:42RSpliet: only the 100da0 check is out of place, I will give you that
15:43imirkin: i think it has to do with something other than chipset
15:43imirkin: but... dunno what
15:43RSpliet: could always be a combination of chipset and GDDR3
15:43imirkin: could be
15:44RSpliet: I already fear the first DDR2 G9x I get to see, because if I look back at GT215+ that will have a lot of impact on the 10071x family
15:47karolherbst: I am working on my fermi card now, anything special I should check on that?
15:48airlied: yes so beignet generates nvptx from llvm still
15:48RSpliet:nudges pmoreau... firework and explosions?
15:48airlied: instead of writing a intel gen llvm backend
15:49imirkin: airlied: i'm just not sure that it'll be easier or more useful to do nvptx -> nv50 ir than spir-v -> nv50 ir
15:49airlied: yeah probably best to wait for spir-v at this point
15:50imirkin: airlied: also compute in GL is going to be a thing soon... i'm going to figure out how to access gmem from the graphics pipeline if it's the last thing i do
15:50airlied: imirkin: you can't trace the blob?
15:50imirkin: airlied: i can
15:50imirkin: and i did
15:50imirkin: and i'm doing everything it's doing
15:50airlied: oh some other magic nice
15:50imirkin: although... apparently not :)
15:51imirkin: coz when the piglit runs on blob it says "pass", whereas for me it says "MP error" in dmesg
15:51airlied: I currently can only do tess on evergreen if I run fglrx first
15:51pmoreau: RSpliet: 0e seems stable, but 0f is still wrong
15:51imirkin: airlied: what if you run r600 first, does fglrx still work afterwards?
15:52RSpliet: pmoreau: and no more timeouts when there's no monitor plugged in? :-D
15:52airlied: imirkin: if I run r600 first, I get lockups and machine dies
15:52pmoreau: RSpliet: a tiny bit of random corruption, plus at some point display freezes gears disappears from glxgears
15:52pmoreau: RSpliet: Yeah! It works nicely! :-)
15:52RSpliet: excellent, progress!
15:52imirkin: airlied: sadness.
15:52karolherbst: pmoreau: nice
15:52imirkin: airlied: well, without knowing any details, i'm going to go for some sort of register setup missing in the kernel
15:53karolherbst: the hell
15:53airlied: imirkin: yes, same across all gpus?
15:54imirkin: airlied: as for my issue, i really need to try it with the blob ctxsw fw, but that was recently made more difficult
15:54imirkin: airlied: no, fermi fails more silently
15:54imirkin: airlied: and my GK208 is the one with the MP error
15:54imirkin: airlied: and i have no other nvc0+ gpu's available.... ooh, except the TK1
15:55airlied: they might have it setup correctly :)
15:55imirkin: anyways, now that ssbo has landed, i'm going to use that to debug
15:55imirkin: i suspect it might only be atomics that are broken, not gmem
15:56imirkin: and when i feed bogus addresses in, i do see it complain about the bogosity of those addresses, so *something* is working
15:59pmoreau: RSpliet: Any thing I could provide you with to help?
15:59RSpliet: pmoreau: well, erm... eheh
15:59RSpliet: can you keep it running in that not-so-right state
16:00RSpliet: and then nvapoke -c1 0x100714 0x33102 ? (I presume -c1...?)
16:00pmoreau: I can probably keep it running, but the mouse is the only living thing out there
16:00pmoreau: -c1 is the MCP79 ;)
16:00RSpliet: -c0 then :-D
16:01RSpliet: so no wobbly glxgears
16:01RSpliet: hmm, I'll go and dig deeper to see which bit asserts that 0x100 there
16:02pmoreau: The not-so-right state is in two phases: 1) flickering + some screen corruption 2) gears disappears and the mouse is one living
16:02pmoreau: s/one/the only one
16:02pmoreau:is getting tired
16:03pmoreau: So I can try to poke during phase 1, but before phase 2
16:03karolherbst: any idea why the blob reads PMC.ID that much?
16:04pmoreau: It's fun!
16:04pmoreau: With mmt information on top of mmio, it makes more sense
16:04imirkin: karolherbst: for good luck
16:05karolherbst: imirkin: yeah well, but without doing anything else in between and like 50 times?
16:05karolherbst: mor than 50 times actually
16:05imirkin: need lots o' luck
16:05imirkin: probably makes something in the driver easier
16:05pmoreau: As you discover that it reads it one or twice at the beginning of each IOCTL, and sometimes the IOCTL will not write or read through mmio
16:06karolherbst: pmoreau: this isn't what I meant
16:06karolherbst: pmoreau: https://gist.github.com/karolherbst/523e780dee976074bb3a
16:06pmoreau: This is what I mean
16:07karolherbst: ohhh didn't get your last part
16:07karolherbst: why not just saving this in sys ram or something
16:07pmoreau: In case you hotswapped GPUs? :D
16:08karolherbst: yeah because the blob doesn't notice when the gpu is suddenly gone
16:08pmoreau: You never know users! :D
16:08karolherbst: maybe there are fast users out there
16:08karolherbst: switching gpus so fast the blob never knows
16:09pmoreau: RSpliet: They are a bunch of TRAP_MP_EXEC in the dmesg from the last run with your patches
16:09karolherbst: somehow I doubt that the card itself tells the blob whether it supports pcie v2 :(
16:09RSpliet: pmoreau: those are "oh my god the card has gone mental" warnings
16:09RSpliet: expected when the memory (/controller) misbehaves
16:11pmoreau: Probably corresponding to when the gears disappeared
16:11pmoreau: and I have a TRAP_M2MF some time before that
16:11karolherbst: oh man, I don't like this, not even a tiny bit. It just doesn'T feel right putting the card into v2 mode without even knowing if the card supports this
16:13karolherbst: skeggsb: any ideas about how to handle that? I just don't want to try out if the card supports this, but the blob seems to do it that way (even several times, even when switching to v2 mode failed)
16:34RSpliet: pmoreau: I hate to ask it to you, but erm... I just fixed up 100714
16:34RSpliet: which seems to rely on the FBVDDQ value
16:34RSpliet: hence... well, if on the highest perf lvl the voltage was incorrect, that would explain a lot of mess :-P
16:36RSpliet: now I don't see any difference any more between the 10071x family values
16:37RSpliet: so when you feel like it, please try ;-)
17:00karolherbst: argh, this annoys me now
17:01karolherbst: it would be fine, if there were only v1 2.5 pcie cards, but there are some which support the v2 protocol, but only at 2.5 speed
17:31karolherbst: can anybody explain to me why not all fermi cards are using the GF100 pci subdev?
17:32imirkin: GF100 and maybe a couple other cards had a weird msi situation
17:32karolherbst: ohh right I see this msi_rearm thingy
17:32imirkin: the gf100 pci subdev is to account for that situation
17:32imirkin: the rest can use the original method
17:33karolherbst: then I most likely I need a new pci subdev for fermis with no weird msi situation
17:34karolherbst: I already wondered why my code doesn't have any effect on my fermi card here :D
17:34imirkin: now you know
17:36karolherbst: now how should I call that fermi subdev not used for GF100, GF104, GF110 and GF114. gf1x6_pci ? :D
17:37imirkin: gf106 probably
17:37karolherbst: only because of one different func pointer :( oh well
17:44karolherbst: oh wow, this ubuntu machine is unexpected slow :O
17:45karolherbst: double compile time for nouveau
17:45karolherbst: and the cpu is just ivb, but same speed generally
17:46karolherbst: pcie version upgrade works on fermi now :)
17:47karolherbst: imirkin: do you have a tesla card somewhere which boots at v1?
18:41karolherbst: okay, pcie version upgrade done for tesla+, and actual speed changes for kepler+ :)
18:42karolherbst: anybody want to test that out?
22:56slacka123: A webGL app is causing my system to hard lock. Are there any guidelines on filing a good bug report? Like debug logging or something?
23:00imirkin: slacka123: what gpu?
23:01slacka123: gtx 650
23:01slacka123: mesa edgers (11.0)
23:01imirkin: hrm ok
23:01imirkin: that's unfortunate.
23:01imirkin: try to get dmesg after the issues happen
23:01slacka123: it's all good
23:01imirkin: also if the webgl is publicly available, you could mention what it is.
23:02imirkin: can you ssh into the system and/or set up netconsole?
23:02imirkin: usually nouveau spits out logs before shitting itself
23:02slacka123: haven't tested ssh, but GUI locked up so was doing magic SysRq
23:03slacka123: where are the logs? is there a guide or web page I should read?
23:03imirkin: run "dmesg"
23:03slacka123: ok, I can do
23:03imirkin: try to ssh in after the hang happens
23:03imirkin: and run dmesg
23:03slacka123: got it!
23:04imirkin: if you can't ssh in, but you have other network-attached devices, try to use netconsole to see if it lets you a last gasp before death
23:05slacka123: when I did some googling I found out Radeon users should -> RADEON_DEBUG=vp,fp . Nothing like this for nouvea?
23:06imirkin: there's NV50_PROG_DEBUG=1 but that won't help much with hangs
23:06slacka123: how about RADEON_NOOP=1 to disable command submission, ?
23:06imirkin: i guess radeon hw can get hangs due to incorrect shaders... that's not really an issue on nvidia hw
23:07slacka123: nice...OK I'll try to ssh...thanks for the tips!
23:07imirkin: there's no mode that doesn't submit commands
23:07imirkin: actually.... maybe there's something in libdrm
23:07imirkin: i've never used it though if it exists
23:55imirkin: slacka123: bug 92136 -- that you?
23:56slacka123: imirkin: yes. Is there anything else I should add?
23:56imirkin: heh. no. but... don't do that ;)
23:56imirkin: pretty sure i knew that max-texture-size could cause fail
23:57imirkin: but in practice no application actually does that
23:57imirkin: skeggsb: do we not allow bo's over 2G?
23:58imirkin: skeggsb: nouveau W[ DRM] skipped size 80010000
23:58slacka123: anyways, would be nice to fail a little more gracefully
23:58imirkin: slacka123: yeah, no argument there
23:58imirkin: slacka123: however due to no real-life usecases this sort of thing gets low priority
23:59slacka123: OK, no worries. You guys are doing an amazing job