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