00:46imirkin: MrBIOS-home_: great, thanks!
00:46imirkin: mwk: any thoughts on why MSI might be broken on BE platforms (at least for nv4x, haven't tested others)
00:46mwk: no idea
00:47MrBIOS-home_: do any of you guys have accces to BE hardware?
00:47MrBIOS-home_: with PCIe
00:48imirkin: i believe skeggsb has access to one (now off-site for him though). and there's the guy who was in here earlier with a ppc that had pcie slots.
00:49airlied: at one point therer was some problem with msi and 40-bit vs 64-bit address spaces
00:49airlied: but I think that was a radeon bug
00:49imirkin: airlied: by all accounts, MSI works fine on those platforms, and those same (or extremely similar) nvidia chips work fine with MSI on x86 platforms
00:50airlied: imirkin: hence why this sort of bug might happen
00:50airlied: x86 never assign 64-bit msi addresses
00:50airlied: https://patchwork.kernel.org/patch/5042741/ is the radeon fix
00:50imirkin: i wonder if some register is being written as BE but interpreted as LE
00:50imirkin: ahh interesting!
00:50imirkin: so the "fix" was to disable MSI :)
00:50airlied: imirkin: that is also a possiblity somewhere maybe
00:51airlied: no this patches it down to 32-bit space only
00:51imirkin: oh hm. dunno if that's entirely possible on a G5
00:51airlied: yeah I'm not sure if that can happen on a G5 either
00:51imirkin: the MSI address was like 0xffe000......
00:52airlied: it could also be G5 chipsets are shit, but MSI is pretty much a pci message so shouln't fail
00:52imirkin: nah, other things work with MSI (albeit on hypertransport rather than PCIe)
00:58imirkin: MrBIOS-home_: if you still have that system booted... as root, lspci -nnnvvvv -d 10de:
01:00MrBIOS-home_: airlied: it's not a G5
01:00MrBIOS-home_: this is on a Freescale SoC (e5500 core)
01:00MrBIOS-home_: ppc64 sans Altivec
01:03airlied: oh so maybe it could suffer from the same problem
01:03imirkin: well, both this platform and the G5 failed at MSI
01:04imirkin: [with nvidia gpus]
01:04imirkin: which leads me to suspect the issue might be on the nvidia end
01:04airlied: imirkin: do we know it it happens with later gpus?
01:04imirkin: we do not.
01:05imirkin: although i do vaguely recall you plugged a GK208 into your G5, but i don't know what kernel that was on, or what the results were
01:05airlied: probably need someone with a logic analyzer a lot of time :-P
01:06imirkin: well, easy enough to see if it works... if it doesn't work, easy to declare it broken
01:06MrBIOS-home_: and MSIs are known to work with non-Nvidia GPUs on this exact same platform
01:06imirkin: (as i believe they are on G5's)
01:07imirkin: could be that the address gets byte-swapped
01:07imirkin: or word-swapped
01:08MrBIOS-home_:waves at matst88
01:08MrBIOS-home_: haven't seen that nick in a LONG time
01:10MrBIOS-home_: mattst88, rather
01:10mattst88: I've been here all along :)
01:14imirkin: skeggsb: hrm... have you tested v4.13-rc with any pre-nv50 boards?
01:14imirkin: i think they might all be busted with this ior rework
01:17imirkin: skeggsb: the nvkm_outp_init_route logic expects ior stuff to be there, but i don't think pre-nv50 was ever ported to using it
01:18MrBIOS-home_: when did the ior rework slide in? during 4.13-rc?
01:18MrBIOS-home_: or earlier?
01:18skeggsb: imirkin: yeah, i seen the bug go by
01:18MrBIOS-home_: is there a commit I can reference?
01:18Hoolootwo: I would offer to debug, but my nv18(?) box already has a bug with recent kernels
01:19imirkin: MrBIOS-home_: yeah, v4.13-rc1 is where it went in.
01:19skeggsb: let me fix that now, as i'm a bit stuck on something anyway and the break might help :P
01:19MrBIOS-home_: please :)
01:20imirkin: MrBIOS-home_: 78f1ad6f655847411b36bda2b2acbd0648a03d5c was the first in the series
01:20MrBIOS-home_: if anyone would like a free G71, I'll send you one for nothing within the US, or for the cost of shipping abroad
01:20skeggsb: of course i picked the board with bad vram (bios screen corrupted)....
01:20MrBIOS-home_: AKA NV49
01:21skeggsb: meh, at least it booted first time without too much wiggling in the pcie slot.. that's rare for my older boards
01:21imirkin: yeah, that's another reason i don't like switching boards left and right. want to make the slots last. :)
01:22skeggsb: i think it's the contacts on the boards themselves, i've got a second pciex16 slot that almost never gets used, and it's a challenge there too
01:24imirkin: blow on it, like an NES cartridge? :)
01:25skeggsb: ah, the good old days
01:25airlied: one of those old pencil erasers
01:25airlied: on both sides?
01:26MrBIOS-home_: skeggsb: it's far more likely to be your worn out PCIe connector.
01:27skeggsb: MrBIOS-home_: as i said, i have a nearly completely unused slot that it happens to too
01:27MrBIOS-home_: could certainly be hand-oils on the contacts,then
01:27MrBIOS-home_: give it a good lick
01:28imirkin: just make sure to be wearing one of those anti-static wrist grounding thingies when you do
01:32MrBIOS-home_: ...around your neck
01:35skeggsb: there we go, that was nice and simple
01:37imirkin: nv50 == dcb4.0?
01:37imirkin: did not know that.
01:44MrBIOS-home_: imirkin: any idea where I might try adding "rdev->pdev->no_64bit_msi = 1;" to in drivers/gpu/drm/nouveau to see if it solves the MSI situation?
01:46imirkin: MrBIOS-home_: well, i'm curious what lspci says
01:46MrBIOS-home_: let me pop that goddamned card back in :)
01:49MrBIOS-home_: imirkin: with or without nouveau.config=NvMSI=0 ?
01:49imirkin: mmmm... let's try without
01:52MrBIOS-home_: I am not able to get to a console without
01:52imirkin: can you ssh in?
01:53MrBIOS-home_: I tried, nope
01:53MrBIOS-home_: it hangs before the interface is up
01:53MrBIOS-home_: it gets as far as initializing the display to the point where it's displaying noisy garbage
01:53MrBIOS-home_: without disabling MSI
01:53imirkin: ok, so let's try with
01:58imirkin: with disabling msi
02:02MrBIOS-home_: okay, at least one of these boards may be hosed
02:03MrBIOS-home_: imirkin: https://pastebin.com/iT2jJS9F
02:03MrBIOS-home_: that's _without_ nouveau.config=NvMSI=0
02:03imirkin: Capabilities:  MSI: Enable+ Count=1/1 Maskable- 64bit+
02:03imirkin: Address: 00000000df044140 Data: 0005
02:04imirkin: so ... the address fits in the lower 32 bits
02:04imirkin: so ... the no_64_bit thing won't help :)
02:04MrBIOS-home_: MSI is def broken though
02:04imirkin: oh, i believe you
02:05imirkin: can you get envytools installed on there?
02:10MrBIOS-home_: checked out and built. what do you want me to do with it?
02:11imirkin: nvapeek 88068
02:11imirkin: nvapeek 8806c
02:11imirkin: nvapeek 88070
02:13imirkin: well.... for shits and giggles ... nvapoke 8806c 404104df
02:14MrBIOS-home_: returns nothing
02:14imirkin: do interrupts start flowing?
02:14imirkin: (cat /proc/interrupts)
02:15imirkin: otoh i'm not even sure they would
02:15MrBIOS-home_: they do not
16:04mangix: karolherbst: so commenting out line 1549 in ramgk104.c : ram->pmask = nvkm_rd32(device, 0x022554); brings the MMIO read errors from 3 to 1. read error at 022554 and 137200 are gone. 1371f0 remains.
16:07karolherbst: well yeah, sure, but do you know when it is safe to read 0x022554? I mean I could take a look and check what the dependencies are and I am sure there are some features on maxwell we should use and don't. But simply removing those lines is not a valid fix
16:08mangix: no idea. 4.11 did not error on 022554. skeggsb's RAM rework makes it error now.
16:09karolherbst: why do you think it's related to skeggsb RAM rework? I thought you were using one of my branches
16:10karolherbst: mhh, but it indeed seems to be unrelated to my changes
16:12karolherbst: mangix: I think this commit may have introduced this? https://github.com/skeggsb/nouveau/commit/53cb9a340d1f4c5aaab71b065d97940eca10d0d2
16:12mangix: hmmm good point. i've tested skeggsb's branch and compared to your master 4.11 onr
16:12karolherbst: see how 0x021c14 was used on maxwell
16:12mangix: i tried reverting that commit on master 4.11. still shows up
16:13karolherbst: mind doing a git bisect?
16:13mangix: i think it's the commit before that one
16:13mangix: the preparation one
16:14mangix: i can do that later, yeah. at work atm.
16:14karolherbst: I highly doubt it'S the parent one
16:14karolherbst: because that one is a no-op
16:15karolherbst: and it only affects gm200 GPUs
16:16karolherbst: well if you have a 980 Ti ot Titan X, yes that might affect you
16:16karolherbst: but no, there is no functional change
16:16mangix: hmmm ok.
16:16karolherbst: anyway, a git bisect would show more
18:15karolherbst: nice, there are a few CTS tests which fails due to bugs inside our optimizations
18:17karolherbst: ohh wait, no they fail when I disable the optimizations
20:06karolherbst: issue with "KHR-GL44.shaders.struct.uniform.sampler_array_vertex": https://imgur.com/a/JkJvm
20:19RSpliet:grumbles a bit
20:19RSpliet: the RegisterSet class isn't really made for arch-specific operations
20:20RSpliet: Neither is the RegAlloc class, judging by the todo above the target-specific instructions in there
20:37karolherbst: please no, please no... I am sure this silly "mediump" is important
20:38karolherbst: and one uniform is [0.5, 0.5, 0.10000000149011612]
20:41karolherbst: and I am sure radeonsi even fails this one
20:42karolherbst: because llvmpipe also does
20:42karolherbst: airlied: do you know how many tests radeonsi passes on the public CTS? is it close to 97.5% or more like 99%?
20:44imirkin_: mediump is allowed to be upgraded to highp
20:45karolherbst: at least llvmpipe and nouveau fail this test then
20:45airlied: karolherbst: id say 99, but havent ran against open cts
20:45karolherbst: airlied: okay, I see
20:45karolherbst: nouveau is around 97%
20:45imirkin_: RSpliet: yeah, it's not perfect - a couple RA things "know" about the chipset, which is unfortunate
20:46airlied: karolherbst: is there a gl4.5 mustpass list?
20:46imirkin_: RSpliet: just never enough to perform the work required for the nastiness.
20:46karolherbst: airlied: yes
20:46airlied: then it likely passes at least all of those
20:46karolherbst: there are some radeonsi can't pass without nouveau passes them and they fail
20:47airlied: since it has passed gl 4.5
20:47karolherbst: yeah, that's what confuses me as well
20:47airlied: and the mustpass list isnt meant to regress
20:47karolherbst: maybe they do indeed pass all
20:47karolherbst: but I want to be sure about it
20:47karolherbst: can you quick check "KHR-GL45.shaders.struct.uniform.sampler_array_vertex"?
20:50karolherbst: on llvmpipe it fails a little more though, 0.15 vs 0.13 difference compared to nouveau
20:51airlied: ill try run it today
21:17karolherbst: mhhh, okay, odd
21:20airlied: karolherbst: radeonsi fails that sampler array one
21:20karolherbst: something is odd with the uniform
21:21karolherbst: that setUniform seems to have no affect at all
21:21karolherbst: on nouveau
21:23karolherbst: here is the glsl + TGSI: https://gist.github.com/karolherbst/a28b7dc66e37b2ef3094aad2abfd2764
21:24karolherbst: the glsl is printed after the nouveau stuff :/
21:25karolherbst: or not, no idea, this output is always confusing me
21:27karolherbst: better version: https://gist.github.com/karolherbst/1a6ae701cb46ee82ff9b2a46faac4f9f
21:28karolherbst: airlied: is the different round about "0.130769" in TestResults.qpa ?
21:28karolherbst: +- 0.03?
21:33airlied: karolherbst: 0.13068
21:33karolherbst: yeah I assume something goes wrong from the glsl -> tgsi translation
21:33karolherbst: airlied: mind checking if it works when using the NIR thing on radeonsi?
21:35airlied: driver I have doesn't seem to handle R600_DEBUG=nir without dying might be untested GPU
21:35airlied: I haven't tried the nir paths on anything yet
21:36karolherbst: but to me the generated TGSI looks wrong
21:37karolherbst: no idea where this IMM value comes from
21:39karolherbst: intels diff is 0.130132 when I set s.b to (0,0,0)
21:41karolherbst: and nouveaus diff didn't change
21:41airlied: don't see any issues filed against thaat test
21:41karolherbst: it passes on intel
21:42karolherbst: I think the test is correct
21:42karolherbst: just we don't compile it properly in tgsi
21:42karolherbst: changing s.b should have an affect on this shader, shouldn't it?
21:42karolherbst: but it does have none whatsoever
21:42karolherbst: on nouveau
21:56RSpliet: karolherbst: do you happen to have time for benchmarks?
21:57karolherbst: but usually yes
21:58RSpliet: let me push my Mesa tree
21:59RSpliet: https://github.com/RSpliet/mesa with Fermi or Kepler (preferably Kepler on full clocks) compare performance between normal and NV50_PROG_OPTIMIZE=4
22:00RSpliet: no need for a debug build, I made it pick up on the env variable in normal builds too
22:01karolherbst: you should rebase your stuff more often
22:01RSpliet: I... seem to have nothing but shitty benchmarks. Xonotic hangs irregardless of how I launch it and with which mesa. OpenArena just finishes in 2 seconds, pixmark piano I can see a 1ms difference on 135, which is hard to validate... and all the Steamy stuff is 32-bit and impossible to get to load alternative libraries
22:02RSpliet: this... is Mesa from last Sunday.
22:02karolherbst: this seems to be the base: https://github.com/RSpliet/mesa/commit/3753dc896dfe98b246ba8b030aab27a9928533af
22:02RSpliet: Ah... nope, not sure
22:02RSpliet: let me rephrase that
22:03RSpliet: I *failed* to rebase this properly last sunday
22:03karolherbst: well, because some other performance relevant patches were added after this
22:03karolherbst: anyway, can't build it here
22:03karolherbst: or did you test against llvm 4.0.1?
22:04RSpliet: I didn't
22:17RSpliet: karolherbst: rebased for real now
22:17karolherbst: looks good, thanks
22:25karolherbst: RSpliet: I use my systems libraries for all steam games
22:26karolherbst: mhh +1 point in pixmark_piano
22:26karolherbst: ohh wait, I have the unigine benchmark
22:27karolherbst: +2 points with furmark
22:29karolherbst: RSpliet: unigine heaven is a nice benchmark
22:33RSpliet: yeah, it's also not really rendering anything here
22:33karolherbst: on fermi?
22:33RSpliet: I bet it's an old version though
22:33karolherbst: it always worked for me
22:34RSpliet: yeah, pretty sure mine is just outdated
22:34karolherbst: there was no update since ever afaik
22:35karolherbst: except you have the non 4.0 version
22:35RSpliet: indeed... but th screen stays white when running
22:36karolherbst: what GPU?
22:36RSpliet: GT640, GK107
22:37karolherbst: I think something is odd with your system then
22:37RSpliet: tried it with both "my" mesa branch and stock Fedora
22:37karolherbst: I am sure it worked with 13.x already
22:38karolherbst: is this s3tc stuff enabled by default? not that this is the issue
22:38RSpliet: I have libtxc_dxtn-1.0.1-2.gitef072983.fc26.x86_64
22:39karolherbst: no idea then
22:39RSpliet: which implies d3tc it should work
22:39karolherbst: maybe your computer doesn't like you
22:39karolherbst: or your gpu
22:39RSpliet: it's mutual
22:39RSpliet: anyway, +2 in Unigine heaven... what does that mean?
22:39karolherbst: score on ultra low: 1795.34 -> 1817.39
22:40karolherbst: 71.2721 -> 72.1473 fps
22:40karolherbst: but this could be random noise
22:40karolherbst: allthough heaven is quite stable in the output
22:40karolherbst: min/max also increased
22:40karolherbst: seems like a solid +1% perf should be possible overall
22:41RSpliet: not bad, but kinda hard to measure
22:41karolherbst: maybe there is a counter for it
22:42karolherbst: do you still have that 32gprs max threshold in the code?
22:44RSpliet: I redid the lot
22:44RSpliet: left out the liveness analysis bits, because they were unhelpful
22:44RSpliet: (didn't consider colour, didn't look at in/out sets for BBs)
22:45karolherbst: okay nice
22:47imirkin: RSpliet: there's a quirk for that
22:47imirkin: RSpliet: probably your drirc isn't quite right
22:48imirkin: something with dual-source blending iirc
22:48imirkin: RSpliet: <option name="dual_color_blend_by_location" value="true" />
22:48karolherbst: wasn't there a extension midshader thing as well or did this one got fixed?
22:48RSpliet: imirkin: thanks, I'll take a peek
22:49imirkin: yeah, there was
22:49imirkin: but my guess is that RSpliet's drirc is merely outdated
22:49imirkin: RSpliet: rm ~/.drirc
22:51imirkin: RSpliet: or if your system mesa is old, make sure you "make install" mesa and use LD_LIBRARY_PATH rather than LIBGL_DRIVERS_PATH or whatever
22:56RSpliet: removing drirc did the trick just fine, tnx
22:57imirkin: cool =]
22:57imirkin: should hopefully be a prettier image
23:01RSpliet: and a more realistic framerate
23:02imirkin: i guess when it's all white, it goes a bit faster?
23:03RSpliet: a one-off measurement gives me the same as karolherbst on the GK107, about a 1% performance increase with the bank conflict avoiding stuff
23:03RSpliet: (30.1->30.6 fps)
23:04RSpliet: or, well... looking at the logs more like 30.1442->30.5694 - that's very optimistic rounding
23:07RSpliet: meh, when I have time I'll re-run at higher quality and see what they mean with that (more complex shaders, or just bigger textures)
23:07RSpliet: imirkin: if you feel like it, I'd be happy with any comments you have on the patch series @ github
23:07imirkin: RSpliet: i suspect it's above my knowledge level
23:07imirkin: if you have any specific questions, happy to answer them
23:07imirkin: assuming it doesn't regress anything, can probably merge it wholesale
23:08RSpliet: even just checking code-style etc. would be helpful, I normally don't do mesa dev
23:09RSpliet: and before merging, I'll pull out the silly "NV50_PROG_OPTIMIZE >= 4" restriction, that one's just for comparison tests :-)
23:12imirkin: yeah, sure, happy to do that
23:17airlied: karolherbst: so radeonsi used to pass that test
23:17airlied: in mesa 17.1
23:18karolherbst: guess I'll bisect it then
23:18karolherbst: or do you want to?
23:18karolherbst: chances are high that nouveau also passed it back then
23:18airlied: I'm not that well set up for radeonsi at the moment, if I had to guess I'd blame precise work :-P
23:19karolherbst: well, I'll bisect it
23:22airlied: the tgsi changes
23:22airlied: what used to be a const read is now an immediate read
23:22karolherbst: yeah, makes sense
23:23karolherbst: "spirv_info.h: No such file or directory" :( this annoys me
23:27karolherbst: it also passes on nouveau now
23:33karolherbst: okay not my changes \o/
23:43karolherbst: fcbb93e860246375d03f280f927f79d3645a8988 broke it
23:44airlied: might have to take it to #dri-devel
23:45karolherbst: there are more tests which get fixed by this