00:15inglor: I think I've got the mmiotrace
00:15inglor: might be a lot of data
00:15inglor: mmiotrade log : https://dl.dropboxusercontent.com/u/7969252/mmiotrace.tar.gz
00:15karolherbst: imirkin_: the water reflection is also broken in talos princtiple
00:16inglor: right off to bed ;)
00:17inglor: too big? :D
00:19karolherbst: inglor: nope
00:20karolherbst: imirkin_: this might explain the issue we've got with talos principle
00:22imirkin: karolherbst: your gists with the backtraces are gone :(
00:22karolherbst: the old ones yes, because I don't trust me enough to not have messed up
00:22karolherbst: this is till there: https://gist.github.com/karolherbst/ced1b826fa3dc1343be0d0eff8bc069a
00:22imirkin: hm ok
00:22karolherbst: I might have or not have your patch applied
00:23karolherbst: so to be safe I created a new one where I am sure
00:23karolherbst: check this out: https://gist.github.com/karolherbst/ced1b826fa3dc1343be0d0eff8bc069a
00:24imirkin: that one doesn't (directly) show an issue
00:24karolherbst: well I know
00:24karolherbst: the broken reflection is odd though
00:25imirkin: talos is messed up bigtime
00:25karolherbst: the moving water reflection...
00:28imirkin: the water's broken, but it's not just that
00:28imirkin: a ton of stuff is broken
00:30karolherbst: yeah but I think it is all related
00:33karolherbst: imirkin: anything funny you encountered while looking at the talos trace?
00:33imirkin: not explicitly, besides "it's totally bonkers"
00:33karolherbst: inglor: 25MB now :p
00:35imirkin: karolherbst: fyi i pushed out a minor fix to my locking patch in a separate commit
00:35imirkin: karolherbst: however it's incomplete
00:36imirkin: karolherbst: and i may have to rip out some of the fence work logic to fix it "for real"
00:36karolherbst: could it fix the issue from crash I gave you?
00:36imirkin: no clue
00:36karolherbst: I see
00:36imirkin: totally untested too
00:36karolherbst: then I most likely wait
00:36imirkin: so it could just insta-deadlock
00:36karolherbst: sounds good to me then
00:36imirkin: it's in a separate commit, so the original is "safe" :)
00:38karolherbst: ohh right
00:38karolherbst: talos was the game with the funny shaders
00:42karolherbst: because I know you like that: https://gist.github.com/karolherbst/6f2b29b8911dc8941d26b2b22440cc0c :p
00:45karolherbst: imirkin: well at least those talos shaders have like _tons_ of comments, because we can figure something out if I find which "feature" adds those issues
00:50karolherbst: uhhh wow
00:55karolherbst: now I am stuck with the broken stuff
01:04karolherbst: okay, I think I found the thing which causes those water issues
01:05imirkin: oh yeah?
01:05imirkin: or you mean the setting? the setting is some sort of dynamic lighting setting
01:05imirkin: although iirc it's actually messed up even with that
01:06imirkin: but this makes it REALLY bad
01:06karolherbst: and another one
01:06karolherbst: found the second thing for the water
01:07karolherbst: yay, no flickering on the groun
01:07imirkin: what's the setting?
01:07imirkin: btw, the flickering on kepler is WAY worse than it was on fermi
01:07karolherbst: "rendering LOD BIAS"
01:08imirkin: huh ok
01:08karolherbst: "scale for LOD distance calculations"
01:08karolherbst: is the description
01:08imirkin: can you make a mmt of talos with nvidia (and that setting enabled)?
01:08karolherbst: okay and now another issue with the water
01:08imirkin: i want to see if it does anything special for texlod
01:09karolherbst: well first I want to find the next bad setting
01:09imirkin: with non-uniform lod's
01:09imirkin: although ... it should work
01:10imirkin: unless we get the argument order wrong. but there are a ton of tests that make sure we don't
01:10karolherbst: ahh meh, just got a flicker again :/
01:11karolherbst: I am sure that settings changed something though
01:13karolherbst: some cpu setting fixes the moving reflection in the water
01:14karolherbst: "mirror reflections" ... yeah well, that was too obvious
01:18imirkin: i'm gonna see if hakzsam's fixed texbar patch helps anything
01:19karolherbst: for talos?
01:19karolherbst: where is his patch?
01:19imirkin: his version was buggy though
01:19karolherbst: ahh I see
01:20imirkin: this is my redone fixed version
01:21imirkin: but that wouldn't fix anything on fermi
01:23karolherbst: that guy though: https://drive.google.com/file/d/0B78S7GSrzebIc0dxajMtQmJMNms/edit
01:24imirkin: nope, no change
01:28karolherbst: at least the flickering walls are there on lowest settings
01:28karolherbst: might should fix that issue first, allthough there are still tons of settings....
01:30karolherbst: this is the situation: when I increase the lod thing on lowest settings, after a specific threshold the walls start to flicker
01:31imirkin: could be messing up sampler settings
01:31imirkin: or could be messing up the instruction
01:32imirkin: perhaps i'm supposed to do some clamping that i don't? dunno
01:32imirkin: like if some jerk sets an lod bias of 35, is it my job to clamp it to 15?
01:32imirkin: (i should hope not, but who knows)
01:33karolherbst: well, no I really disabled everything and just maxed out the lod ting
01:33karolherbst: and yeah, the issue is still there
01:34imirkin: get an mmt of nvidia doing it
01:34imirkin: and i can look at the shaders and samplers
01:34imirkin: and see if they set anything we don't
01:35karolherbst: first tracing time! :D
01:37karolherbst: 315M apitrace
01:37karolherbst: that sounds small
01:40imirkin: does nvidia also flicker? that'd be amusing
01:40karolherbst: imirkin: how do you like that? https://gist.github.com/karolherbst/3fa8f69275dfb0de36026282c6fd5a1e
01:40karolherbst: nope, nvidia doesn'T flicker
01:40imirkin: karolherbst: yeah, i mentioned it to the guy who added that warning
01:40imirkin: the warning is bogus
01:41karolherbst: there is a big ground flicker at the start of the trace, but that already looked engine related
01:41karolherbst: anyway, nvidia has it too
01:42karolherbst: but no wall flicker
01:42karolherbst: it is like 3:40 am here
01:42karolherbst: and the sun is rising
01:48karolherbst: meh.. kernel crashed on nouveau unload
01:48karolherbst: and my trace broke
01:57karolherbst: imirkin: here is the apitrace at least: https://drive.google.com/open?id=0B78S7GSrzebIN2xiZnB5VFg0Q2c
01:58karolherbst: imirkin: what is the best way to let an mmt trace not growing so big? :/
01:58imirkin: mmt small things :)
01:59karolherbst: the thing is like 10 GB and I am not even past loading the level
02:00imirkin: look on the bright side - you're going to be the one analyzing the mmt trace :)
02:00imirkin: coz i'm not downloading a 100GB trace
02:00karolherbst: I will xz compress it before that :p
02:00karolherbst: but how do you know it will be 100 GB big :O
02:01imirkin: i dunno... "if these trends continue"?
02:01karolherbst: does a lower resolution apitrace also lead to smaller mmt traces?
02:01imirkin: i would assume so
02:04karolherbst: at least filling the disc cache before making the real trace will help
02:05karolherbst: mhh now the issue doesn't show on lower res
02:12karolherbst: seems to look better with a lower res
02:13karolherbst: 4.2 GB uncompressed
02:13karolherbst: much better
02:20karolherbst: imirkin: I've update the apitrace now with the low res version, I hope the mmt is compressed real fast now too
02:20karolherbst: if you want you could check if the flicker also happens for you, but it should, right?
02:23karolherbst: imirkin: wow, the mmt file xz compressed will be like 3% from the original file size...
02:23karolherbst: so around 100MB in total
02:34karolherbst: mhh no it is increasing meh...
02:58karolherbst: imirkin: and here the mmt : https://drive.google.com/open?id=0B78S7GSrzebIYm01YXp6aHFNSGM
02:58karolherbst: and now I go to bed
05:13mupuf: skeggsb_: I did not check for the FSRM, but at the very least, increasing the temperature to 120 (with nvaforcetemp) did not stop the voltage controller
11:18karolherbst: can we get somehow the current executed program on a WARP_ERROR on that warp?
11:46zeq: karolherbst: I've created an mmiotrace of the nvidia driver with my GTX 8800. Where shall I send it?
11:47karolherbst: zeq: upload it somewhere
11:47zeq: I can host it.
12:16mwk: karolherbst: you need to install a trap handler, no small feat
12:17RSpliet: zeq: please xz-compress your dump and send it to mmio.dumps at gmail
12:17RSpliet: and with dump, I mean trace...
12:17RSpliet: (although the e-mail address really is mmio.dumps ...)
12:22RSpliet: zeq: also, if you happen to be around Cambridge sometime after this month (not around the corner, I know...), physical access to the card could be very helpful to get all the details right. We can talk about that in July if you want. The info provided is already very helpful
12:59zeq: RSpliet: sent the dump. I do have a wedding to attend in Ipswich, next month, I think. It's probably doubtful my wife will let me take a detour to Cambridge, but you never know.
13:16RSpliet: hahaha, well, big chance I'll have a wedding in the Netherlands that week, so don't make too much effort for it :-P
13:19RSpliet: also, that is quite a detour... (sorry, I guess I deserve some stalker points for whois-ing your domain O:-) )
13:23RSpliet: zeq: could you double-check the URL to your VBIOS please? It appears to be missing on your server
14:18zeq: RSpliet: yes, sorry compressed it too.
14:18zeq: append an .xz
14:19karolherbst: imirkin: so what would be the next step regarding the talos traces?
14:20imirkin: karolherbst: have a look at (a) the shaders to see if they don't do the texlod stuff differently, and (b) the TIC/TSC's to see if they aren't setting some bits differently
14:20zeq: RSpliet: http://www.snewbury.org.uk/8800.rom.xz
14:21karolherbst: imirkin: do you have any script to extract those shaders the easy way?
14:21imirkin: karolherbst: demmt. search for START_ID
14:22karolherbst: well yeah, I tried pcregrep already, but it sucked
14:22karolherbst: crashed all the way
14:22imirkin: you have to look at it
14:22karolherbst: the shaders are full of texLOD stuff by the way
14:22imirkin: i'm sure.
14:24zeq: RSpliet: Nice stalking btw. I'm in The Netherlands fairly often myself, since my wife is Dutch, no immediate plans though. I might be able to talk her into a day trip to Cambridge though, it is one of her favourite cities.
14:25karolherbst: in CodeEmitterNVC0::emitTXQ is a comment: "const int src1 = (i->predSrc == 1) ? 2 : 1; // if predSrc == 1, !srcExists(2)"
14:26imirkin: karolherbst: right.
14:26imirkin: karolherbst: we want to point it at a non-existent source
14:27karolherbst: I was more unsure if that comment is a todo or more an explenation
14:29RSpliet: zeq: I'm afraid that the URL you provided links to a 404 page
14:30zeq: RSpliet: that's because I'm an idiot
14:30imirkin: takes some effort to make an xz'd vbios have the same text as an html 404 page... but apparently he's done it
14:30zeq: RSpliet: http://www.snewbury.org.uk/8800.bios.xz
14:31RSpliet: zeq: thanks, archived it
14:37imirkin: zeq: btw, i assume you're not planning on doing serious gaming on that thing, but nouveau on the G80 is a tiny bit lacking
14:37imirkin: a bunch of stuff is G84+, and so some things on G80 just don't work
14:38zeq: imirkin: is that, they work differently and the code doesn't exist, or the hardware isn't capable?
14:38imirkin: the hardware doesn't have certain features. that can be worked around in code, but the code to work around it doesn't exist
14:39imirkin: it's *mostly* little things that you'd find in spec conformance tests
14:39imirkin: rather than actual real software
14:39imirkin: but every so often a real piece of software will rely on that functionality
14:39zeq: Anyway, serious gaming and a 9(?) year old GPU probably isn't a viable premise :)
14:40zeq: it was a pretty serious GPU in its day though
14:40imirkin: i think the min/max LOD restriction doesn't work right, and gl_VertexID is going to be wrong in the presence of base vertex usage
14:41imirkin: and ... iirc we have some situations where we mess up and try to do tiling in sysram, which isn't supported at all by the hw
14:41imirkin: whereas G84+ is happy to do it
14:41imirkin: we try not to do that, but ... i've seen it happen
14:41zeq: I'm mostly hoping to use it for TV based web/media light gaming
14:42imirkin: so like i said, generally minor things, but if an app happens to rely on one of them, it can be unfortunate.
14:42imirkin: if you run into issues, please report
14:42zeq: visual corruption likely then?
14:42imirkin: thankfully the G80 is nothing (in terms of gotchas) compared to R600 though
14:43imirkin: R600 (the original) is so bad, they couldn't even expose GL 3.0 on it
14:43zeq: was it intended to be GL3.0?
14:43imirkin: well, DX10
14:43imirkin: so GL 3.3
14:43imirkin: R600 was the competitor to the G80
14:44imirkin: (which was rushed out the door, i suspect, hence all the problems)
14:44zeq: I had a quiet period in GPU terms in that era.
14:46zeq: Matrox (since that's where the early Linux 3D efforts were), then various ATIs.
14:46imirkin: actually i just had an idea for fixing the gl_VertexID thing
14:46imirkin: if you're interested in testing stuff out, i can whip up a patch
14:47karolherbst: imirkin: mhh found an areay where it also happens with the lod settings on lowest... but it has to be like really near to the viewer
14:47imirkin: but it'll require (a) rebuilding mesa and (b) grabbing piglit
14:47imirkin: karolherbst: i wonder if we're configuring aniso settings properly
14:48karolherbst: well I can play with any setting here and try what affects that flickering
14:48zeq: imirkin: that's no problem, I'm on Gentoo :)
14:48imirkin: ok cool.
14:48karolherbst: one thing for sure: if I don't move, the flicker state doesn't change
14:49imirkin: zeq: here's the patch (to mesa): http://hastebin.com/usokamuqah.m
14:49imirkin: zeq: grab piglit, and run ... (this will take me a minute to find)
14:50zeq: Imirkin: at least I should have a better chance of having the G80 work well compared to the NV35 ;)
14:51imirkin: zeq: bin/gl-3.2-basevertex-vertexid -fbo -auto
14:51imirkin: zeq: i have a NV34 plugged in [for testing]
14:52imirkin: but yeah, a NV34 + modern desktop would probably not work so great
14:52imirkin: in part because the NV3x series is a piece of shit, but also in large part because the nouveau nv3x mesa driver is a hunk of junk
14:53zeq: imirkin: yeah I noticed that
14:53zeq: NV35 wasn't *that* bad
14:53imirkin: the hw is early DX9, which means it can't even do GL 2.0 properly
14:54imirkin: the nvidia blob driver exposes 2.0, but if you do anything slightly off, it'll fall off the fast path
14:54zeq: compared to the NV34 anyway :)
14:54zeq: I remember at the time, the NV34 was widely derided
14:54imirkin: it's the same architecture
14:55zeq: where as the NV35 was I remember considered a somewhat fixed version
14:55zeq: my memory might be a bit fuzzy though
14:55imirkin: NV35 had one feature the other nv3x's don't have ...
14:55imirkin: the depth bounds test :)
14:55imirkin: which iirc is heavily used by quake or doom or one of those games
14:55zeq: and much better performance
14:55zeq: maybe that was why
14:56zeq: I used to play a lot of UT2004 back then
14:57imirkin: i think in 2004 i was still using my r100 ati video card, with VIVO :)
14:57imirkin: which worked in linux, to my vast surprise
14:57zeq: the nv35 was definitely better than the original Radeon :)
14:58imirkin: which meant i could use my computer monitor as a dreamcast screen :)
14:58zeq: I used an R200 for years and years though
14:58karolherbst: imirkin: what do you mean by "aniso"?
14:58imirkin: karolherbst: anisotropic filtering
14:58karolherbst: I have that disabled though
14:59imirkin: karolherbst: hm. ok. next theory.
14:59karolherbst: keep in mind: I run it on the lowest possible settings currently
15:00karolherbst: allthough some settings can't be disabled like parallaxing
15:01zeq: The FX 5900 was the only NVidia card I ever bought though, excluding the NVS in my laptop.
15:01karolherbst: ohhh :O
15:02karolherbst: imirkin: changing parallaxing settings also has a kind of big impact on the issue
15:03karolherbst: imirkin: parallexing mapping: Low+ -> flickering on the ground; none -> no flickering on the ground
15:05Rush__: I wonder how CPU involving reverse PRIME is? I am observing display lags if I'm doing CPU intensive things like compiling, watching youtube etc. Could running LTO Mesa binaries bring any improvements?
15:05karolherbst: nearly none
15:06Rush__: so I gather all the buffer transfer magic happens on the GPU, nice
15:06karolherbst: Rush__: what your issue is, is mainly responsiveness of the system
15:06karolherbst: Rush__: well, it is a frame copy over the PCIe bus
15:08imirkin: Rush__: with reverse prime, the mouse cursor has to be composited onto the image, probably by the cpu - it's not efficient.
15:08Rush__: karolherbst: could giving more priority to X process help in this case? what's weird is I don't recall my issuess to be so big when running without Optimus and NVIDIA blob along. Generally I'm seeeing better responsiveness than my previous setup. It's just when things are busy it can become vastly more unresponsive than previous setup.
15:09karolherbst: Rush__: mhh, well I never used reverse prime, but I doubt that impact is noticeable...
15:09karolherbst: imirkin: any ideas about parallaxing mapping? afaik it is some viewport based texture transformation, no idea how that maps to glsl or hardware
15:10imirkin: karolherbst: as with all these things, the name doesn't really matter. it's not like it's some core GL feature they're using/not using
15:10zeq: Rush__: I think all you can do is make sure you have every PCIe performace option is enabled for the relevant devices, perhaps adjust the latency?
15:10imirkin: karolherbst: it's a question of wtf the thing actually does, and why it's messing up nouveau.
15:11karolherbst: "#if defined(HAS_PARALLAX)" :3
15:11imirkin: zeq: let me know if you end up testing that piglit out on your G80
15:11karolherbst: and a PARALLAX_METHOD edfine
15:11karolherbst: I like those shaders
15:11Rush__: zeq: this is a thinkpad t420 so BIOS options are really poor
15:11zeq: Mesa is still rebuilding, it will take a while. The machine isn't the quickest...
15:11imirkin: zeq: it should fail before my patch, and should work after my patch
15:11karolherbst: imirkin: is there any way to enfore specific values of macros?
15:11imirkin: zeq: no rush
15:11imirkin: karolherbst: they are #defined at the top
15:12imirkin: karolherbst: one could also adjust glcpp to predefine them
15:12karolherbst: yeah, but I would like to overwrite them in the compiler
15:14karolherbst: "static const float sc_fParallaxSteps = float(PARALLAX_STEPS);" could that mess up?
15:14karolherbst: PARALLAX_STEPS is an int value
15:15karolherbst: okay, I hope that thing won't be 0 at any point
15:15imirkin: karolherbst: it's not a core compilation issue, since it works fine on (a) nv50 and (b) radeonsi
15:15karolherbst: ahh okay
15:16karolherbst: so nvc0+ only
15:16imirkin: as far as i know, yes
15:16imirkin: try it on your NVAC
15:16karolherbst: good idea
15:19karolherbst: "vOffset.z = 1.0f- saturate( fViewDist2 / (float(PARALLAX_STEPS*PARALLAX_STEPS)*25.0f*25.0f));" funny :D
15:20karolherbst: imirkin: something odd with our ddx/ddy things?
15:20karolherbst: they seem to use that quite a lot for parallaxing
15:20imirkin: i mean... are you asking me, "could there potentially be something odd with dfdx/dfdy"? then yes. there could potentially be something off.
15:20imirkin: but i'd say that about nearly anything
15:21karolherbst: I see
15:24karolherbst: where would I predefine macro values in glcpp?
15:24imirkin: search for add_builtin_define()
15:25karolherbst: k, thanks
15:26karolherbst: mhh what happens if I predfine something to 0 and the glsl code has #define something 2?
15:33karolherbst: huehuehue https://i.imgur.com/84e8JrK.png
15:34karolherbst: mhh odd
15:34karolherbst: you can still notice the flickering
15:36karolherbst: this is most likely caused by a /0 operation
15:36karolherbst: or not :O
15:53karolherbst: imirkin: yeah, looks okay on nvac
15:56karolherbst: I think I know what I will do now
16:00uramekus: hi people, yesterday i was playing some CSGO using nouveau then my gpu hanged up and i didnt had any video at all, since then in trying to fix it but it seems that the gpu got completely broken, can anyone give me advice before i throw it in the trash can?
16:00uramekus: that is my dmesg, seems really bad http://pastebin.com/5rFsicm0
16:02imirkin: uramekus: have you tried doing a cold reboot?
16:04imirkin: i.e. power the thing off for a bit, then turn back on?
16:05imirkin: uramekus: i'd definitely try with blob driver and see if it can load ok
16:05imirkin: if even it can't load, then you're sunk
16:06imirkin: uramekus: also maybe try re-seating it in the pcie slot
16:07imirkin: anyways, sorry, no great ideas =/
16:07karolherbst: uramekus: do you reclock on boot or something like that?
16:07uramekus: nope, only enable nouveau pstate, but i only reclock when needed
16:07karolherbst: I see
16:09uramekus: imirkin: ive already removed it and opened it, ive tried to see if anything was burnt in the circuit
16:09Klinnex: I tried nouveau with debian and ubuntu on gtx 750 ti and i have got artifacts from top to almost bottom
16:09imirkin: Klinnex: what xorg version?
16:09Klinnex: artifacts means the screen looks broken, random white, yellow and green pixels all around the screen
16:09Klinnex: standard installed with recent debian jessie and ubuntu
16:10Klinnex: with lxde or gnome/unity
16:10imirkin: Klinnex: i haven't the faintest clue what version they ship, nor am i particularly interested in searching myself
16:10Klinnex: Well I am going to install debian right now.
16:11imirkin: anyways, here are a few fun facts:
16:11uramekus: Klinnex: go on your terminal (tty2 or via SSH) and exec "Xorg -Version"
16:11imirkin: (a) xf86-video-nouveau does not support GM107, it is supported by xf86-video-modesetting
16:11Klinnex: gm107 includes gtx 750 ti stormx?
16:11imirkin: (b) xf86-video-modesetting is shipped as part of Xorg (nowadays) and uses GLAMOR to accelerate X operations, which is a GL-based acceleration implementation
16:12Klinnex: its like reading chinese while being japanese
16:12imirkin: (c) GLAMOR manages to hit some undiagnosed issue on nouveau's GL driver backend
16:12Klinnex: it would be the best if i could make a picture of the artifacts
16:12imirkin: (d) i'm told that in recent versions of GLAMOR and/or nouveau GL backend, the issues no longer come up
16:13Klinnex: so i will be back in no time
16:13imirkin: you can find out what chip you have by doing "lspci -nn -d 10de:"
16:13uramekus: im installing propietary drivers right now, i hope nouveau is broken and not my gpu LOL
16:13Klinnex: i am writing both commands on paper
16:15karolherbst: imirkin: ........... this is a big wtf... at some point in the frame, it looks right and it gets messed up later
16:15karolherbst: and this happens in like the last 100 gl calls
16:19karolherbst: ohh wrong frame...
16:29glennk: karolherbst, most likely that parallax define is set by the engine from code depending on game settings
16:30glennk: that one in particular tends to be a bit heavy so presumably not enabled on the lower quality settings
16:30uramekus: no video in prop driver ://///
16:30karolherbst: glennk: yeah most likly, I also feed in values the shader wasn't written against
16:31glennk: how expensive parallax mapping is also tends to be pretty data and viewing angle dependent
16:33karolherbst: I found now two calls where the same hting is rendered
16:33karolherbst: the output differes allthough it shouldn't
16:33karolherbst: the fragment shader is the same
16:33karolherbst: the vertex shader on the right call has a "#define HAS_NORMAL_MAP 1" more
16:34karolherbst: otherwise the vertex shaders are the same
16:34karolherbst: I might have looked at the wrong draw call again
16:35karolherbst: doesn't matter
16:35karolherbst: same shaders
16:35karolherbst: so the wrong thing misses that define
16:38uramekus: wasnt even able to see my POST or enter in UEFI
16:38uramekus: so my gpu is oficially unusable? (not dead, can see on lspci and even updated the firmware)
16:39karolherbst: uramekus: you could try to unplug it or totally electrically unload your entire machine
16:40uramekus: how much time should i wait?
16:41Klinnex: hi again, im back
16:41Klinnex: this is how it looks
16:41Klinnex: dirty artifacts
16:41Klinnex: tested on tails no root
16:42uramekus: its not xorg, its Xorg
16:42Klinnex: is this very important? do i have to reboot again?
16:43Klinnex: the second command has gm107
16:43Klinnex: and that guy told that gm107 is not part of nouveau
16:43karolherbst: Klinnex: it's not part of the ddx
16:43uramekus: its not part of xf86-video-nouveau
16:44uramekus: remove it from your system, xorg has a integrated driver that will work fine
16:44Klinnex: with gtx 750 ti?
16:44Klinnex: so i have to reboot to tails with root enabled and use sudo apt-get remove xorg-xf86-nouveau ?
16:45uramekus: yup, it only wont work if your xorg version is too much old or you are using a old kernel
16:45uramekus: i think in debian its xserver-xorg-video-nouveau, i use arch so im not 100% sure
16:46Klinnex: hm, you know what i will turn on other pc and boot this one to tails so i can operate with you live
16:47uramekus: hey Karol, is 970 fine to use now with nouveau? or still worse compared to an 770?
16:47karolherbst: imirkin: but you are right, that game is just so broken on nvc0+ :/
16:47uramekus: already looking to replace my card
16:48karolherbst: uramekus: the only think I can say is, that keplers _can_ work pretty good
16:51uramekus: welp, my PSU cant handle an 780ti, used to have a 770 but now is oficially dead, it seems that i will have to spend money on a downgrade or use the propietary drivers
16:51uramekus: but i prefer using windows or mac osx than using linux + prop drivers
16:51karolherbst: you should unplug your gpu for a few minutes
16:52karolherbst: or bake it in the oven! :p
16:52karolherbst: allthough I am sure that won't do on newer cards anymore
16:52imirkin_: uramekus: no reclocking with GM20x. and until recently, no accel at all.
16:52imirkin_: uramekus: if you're looking at buying a new gpu, i'd recommend amd - it's much better supported than nouveau
16:58karolherbst: imirkin_: the wrong frame does two calls in addition: "glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_LINEAR)" and "1274471 @0 glTexParameteri(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_LINEAR)"
16:59karolherbst: ohh wait
16:59karolherbst: the other does that too, just earlier
16:59imirkin_: we could be missing a TSC flush
16:59imirkin_: or we could be doing that flush incorrectly
17:04karolherbst: maybe yeah
17:04karolherbst: because the stuff looks the same API wise
17:05karolherbst: well one uniform is set differently
17:05karolherbst: but it is also within a different frame, so it should have valid reasons
17:08karolherbst: mhh a "glFrontFace(mode = GL_CW)" is fone before the draw
17:19zeq: imirkin: failed
17:21zeq: imirkin: http://pastebin.com/Wtf74DA6
17:21imirkin_: zeq: that's with my patch applied? :(
17:21zeq: imirkin: I'll make sure it applied... hang on
17:22zeq: imirkin: yep. with the patch
17:23imirkin_: ok :(
17:23imirkin_: i thought that should have worked.
17:23imirkin_: there might be deeper vertex id issues
17:24imirkin_: these are the failures from ... like a year ago: https://people.freedesktop.org/~imirkin/nv50-comparison/problems.html
17:24zeq: imirkin: shall I perform a full piglit run?
17:24imirkin_: this is the type of crap i'm talking about btw: https://people.freedesktop.org/~imirkin/nv50-comparison/nv50-2015-07-09-hakzsam/spec@email@example.com
17:25imirkin_: that "WRONG_MEMTYPE" thing
17:25imirkin_: that's not a thing on G84+
17:25zeq: hw bugs?
17:25imirkin_: no, sw bugs
17:25imirkin_: but as a result of the hw being different :)
17:26imirkin_: and since ~no one actually has these G80's
17:26imirkin_: not a ton of effort has gone into fixing them
17:26imirkin_: anyways, you can see how it compares to the rest of the tesla family
17:27zeq: yeah... GTX 8800's were pretty expensive and quickly superseded I suppose
17:27imirkin_: (at that nv50-comparison link)
17:27imirkin_: nv50 = G80
17:28imirkin_: nva0 = G200
17:28imirkin_: oh right... the sprite coord stuff is messed up there too
17:28imirkin_: coz they decided to change how it was all indexed on G84+
17:28imirkin_: (guess which mapping style nv50 implements)
17:30zeq: presumably the change was an improvement in some way??
17:30imirkin_: dunno, i haven't RE'd exactly how nv50 does it
17:30imirkin_: i just know it's different
17:31imirkin_: but anyways, hopefully it's working better than a NV35 with a modern desktop
17:31imirkin_: and if you're interested in fixing G80-specific issues, let me know, i'd be happy to give some pointers
17:31zeq: oh it's definitely doing that! the nv35 just fails due to no NPOT texture implementation
17:32Klinnex: hi, im back
17:32Klinnex: so Xorg -version printed 1.16.4 (2014-12-20
17:33imirkin_: Klinnex: ah yeah. you definitely want 1.18.x
17:33Klinnex: damn, then i need reboot coz i disabled network in tails :D
17:33Klinnex: and also there is no package xf86-video-nouveau
17:33Klinnex: and xf86-xorg-nouveau isnt there either
17:33imirkin_: there is. but your distro probably helpfully renamed it
17:33Klinnex: ive read about xserver-xorg-video-nouveau
17:33zeq: imirkin: I'm happy to do what I can. My C skills are okay, and I know the graphics stack well enough, but I'm a bit ignorant about OpenGL/graphics APIs generally...
17:34imirkin_: in order to reduce confusion :)
17:34Klinnex: the only instructions i found were involving kernel rebuild
17:34zeq: I could do something about that I suppose
17:34imirkin_: zeq: not an issue. i started in nouveau having 0 knowledge of modern GL
17:34imirkin_: [but also i wasn't trying to do graphics stuff, my first contribution was VP2 decoding]
17:35zeq: I spent yesterday evening trying to fix the MGA DDX driver fwiw :-)
17:35imirkin_: how'd that go
17:36zeq: The UseFBDev support has been broken for a long time, the option is tested before the option table is processed. So I fixed that up but there's more broken. At least it fails differently now ;-)
17:37zeq: I don't think it gets much use
17:37zeq: certainly not on a mga1064sg with fbdev
17:38Klinnex: ok so do i have to first do apt-get update && apt-get dist-upgrade and then manually install newest xorg, and after all that remove xserver-xorg-video-nouveau?
17:38zeq: maybe I should look at adding 1064sg support to the matrox kms driver instead
17:38imirkin_: Klinnex: removing xserver-xorg-video-nouveau is unnecessary - it just won't do anything.
17:38zeq: off topic here anyway ...
17:39Klinnex: so only update and dist upgrade?
17:39imirkin_: Klinnex: sorry, i don't do distro support
17:39imirkin_: if you need help operating your distro, ask in a distro support channel
17:42glennk: 1064sg, is that the nerfed display-only "mga" device they like to put in blade servers?
17:44karolherbst: imirkin_: you can't think of any dirty trick we could try out for talos?
17:45imirkin_: karolherbst: plenty
17:45imirkin_: i've already tried them :)
17:45karolherbst: okay, and besides those you tried out?
17:46zeq: glennk: it's a Matrox Mystique 220 - it's one of the first 3D GPUs
17:46glennk: oh, pre g200
17:46imirkin_: as if there even were such a time
17:47glennk: i remember it being around ati mach64 level in what it accelerated
17:48imirkin_: my favorite game from that era - megarace
17:49glennk: g400 is pretty much the oldest matrox thing that can run a compositor
17:53zeq: it has *much* better idle power consumption than the low-end radeonhd I had in the system previously
17:54zeq: hd4350 I think
17:57Klinnex: i am downloading lxle maybe it will have newest version of xorg and artifacts won't show
17:58imirkin_: Klinnex: if you want to play with a livecd, you can try pmoreau's at https://nouveau.pmoreau.org/
17:58Klinnex: has it got newest version of xorg?
17:58imirkin_: it has the newest version of everything that matters
17:59imirkin_: (the super-newest version... usually from git)
17:59Klinnex: ok, i am downloading it now
18:00Klinnex: hope my nvidia will start to work properly so i can switch proprietary windows 10 for cooling open source debian jessie :)
18:04Klinnex: 5 minutes ago there was new patch for diablo 2
18:04Klinnex: amazing :P
18:07glennk: zeq, yeah evergree/NI are much better than hd4xxx on idle power consumption
18:10karolherbst: imirkin_: okay, no idea, it has to do with us. one odd thing though: in the wrong frame, the missrendered wall is the first wall part ever rendered in that frame. I guess something gets flushed too late maybe? Or too late updated on the gpu or something stupid like that
18:15glennk: interaction with fast clear perhaps?
18:15karolherbst: glennk: do you know the issue we are talking about?
18:15karolherbst: the flickering wall thing
18:16karolherbst: wait a sec
18:17karolherbst: glennk: that's one part of the issue: https://drive.google.com/open?id=0B78S7GSrzebIRmE0Sm1helRBa00
18:18glennk: hmm, is that shadow map updated just prior to that draw call?
18:19karolherbst: no idea
18:19glennk: looks like the shadow map has front/back face culling backwards
18:21imirkin_: glennk: does winsys vs fbo have any effect on front/back faceness? no, right?
18:22imirkin_: anyways, there *is* an issue with texturing from a cleared surface
18:22imirkin_: i do have a patch to fix it
18:24karolherbst: let me guess, it would be if that would fix it, because we don't have the issue on nv50 in the first place
18:25Klinnex: ok i used dd to make that iso of nouveau livecd and there is isolinux.bin error, means uefi related stuff?
18:26Klinnex: nevermind all fixed :)
18:26karolherbst: Klinnex: uhh I doubt the gentoo livecd has uefi support
18:26Klinnex: i used bios boot instead of uefi
18:26karolherbst: well I never installed gentoo from a gentoo live cd anyway
18:27Klinnex: ok so there is root on arch tty, now should i use startx?
18:27Klinnex: nice, black screen with mouse pointer
18:27Klinnex: and no artifacts :)
18:27Klinnex: jesus christ its great :D
18:27Klinnex: no artifacts :>
18:28Klinnex: what a beauty of open source engineering :]
18:28root_: its me
18:30karolherbst: imirkin_: I think this patch fixes _some_ stuff
18:31Klinnex: ok so now i only need to know wheter i will be able to install debian with the version of xorg that was on that livecd that you guys suggested me
18:31glennk: imirkin_, well, y flips direction
18:31karolherbst: imirkin_: okay, it seems like it fixes nothing
18:31karolherbst: maybe on higher quality setings, who knows
18:32karolherbst: glennk: the ground stuff is part of the parallaxing settings
18:32karolherbst: only happens when parallaxing mapping is enabled
18:33karolherbst: if I would have to count there are like 5 or 6 different visual issues, maybe all with the same cause though
18:33glennk: hmm, something with explicit derivatives then?
18:33root_: anyway thanks for help guys, no artifacts :)
18:33karolherbst: glennk: well it works on nv50+ gpus
18:34glennk: i know darkplaces parallax mapping gets different results with coarse vs fine derivatives
18:38karolherbst: glennk: well no idea, I still have to learn all that stuff. I can just make either bad or good guesses and hope something changes :D
18:43imirkin_: glennk: right, but the faceness shouldn't be any different right?
18:44imirkin_: esp coz the y flip is on the rasterized thing, while faceness is based on the polygon winding which is way before any sort of raster
18:44imirkin_: glennk: we only have fine derivatives... non-fine derivatives would take more effort
18:57imirkin_: karolherbst: oh hm, i probably need to stick a serialize in there too
18:57imirkin_: before the TEX_CACHE_CTL thing
19:26karolherbst: imirkin_: SERIALIZE(?);?
19:26imirkin_: karolherbst: yes.
19:26imirkin_: karolherbst: have a look at nvc0_texture_barrier in nvc0_context.c
19:27karolherbst: IMMED_NVC0(push, NVC0_3D(SERIALIZE), 0);
19:27karolherbst: in front of all TEX_CACHE_CTL?
19:34imirkin_: karolherbst: i wonder if this also wants a serialize before it: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_tex.c#n476
19:34karolherbst: before "if (unlikely(s == 5))"?
19:35imirkin_: anyways, you can just stick in a call to texture barrier in nvc0_draw_vbo() somewhere
19:35imirkin_: which should have the effect of things moving like molasses
19:35imirkin_: but at least it'd be a good test to see if we're missing it somewhere
19:36karolherbst: where inside nvc0_draw_vbo?
19:37imirkin_: after the call to validate
19:37imirkin_: before other stuff
19:40karolherbst: doesn't help a thing
19:41karolherbst: that is what I changed on top of your change: https://gist.github.com/karolherbst/e10c0f6f806f610244f3edf03e9805ae
19:42karolherbst: maybe we should just do the most brute force way possible which may make performance real bad, but should help with like everyhing :D
19:44karolherbst: but it may behave more like a state issue, not like a single draw call goes wrong or something like that
19:44karolherbst: because this is always like the entire frame is messed and never partly
19:45karolherbst: and also
19:45karolherbst: it doesn't happen randomly
19:45karolherbst: it highly depends on where you are standing in game
19:45karolherbst: and in which direction you look
20:09hakzsam: karolherbst, this issue is hard to track down :)
20:13imirkin_: i spent _quite_ a while on it
20:32karolherbst: imirkin_: maybe we just go the wrong way. Maybe we have to break nv50 the same way to know what we do wrong in nvc0 :)
20:32hakzsam: have fun :)
20:37karolherbst: imirkin_: would it help to get the path mesa goes with the messed up draw call?
20:37hakzsam: karolherbst, what draw call are you talking about?
20:37karolherbst: in the trace
20:37imirkin_: karolherbst: i tried to figure it out, and i failed. i have no additional information to provide.
20:37hakzsam: sure, which one?
20:38karolherbst: in my trace wrong: 1273145 right: 1347719
20:38karolherbst: both calls draw the same thing
20:38karolherbst: just a bit different
20:38hakzsam: did you check with apitrace diff-state?
20:38karolherbst: for funny reasons the order the objects are drawn is different
20:39karolherbst: but if you compare the the previous draw calls of both, you will see what I mean
20:39hakzsam: "a bit different", ok :)
20:41hakzsam: anyways, hard to figure out
20:43karolherbst: the color is different
20:44hakzsam: imirkin_, same issue on kepler I guess?
20:44hakzsam: I mean *exactly* ?
20:44karolherbst: hakzsam: I shall give you a screenshot
20:44imirkin_: hakzsam: not *exactly* - it's a lot more flickery on kepler than i remember it being on fermi
20:45hakzsam: karolherbst, I have a trace
20:45hakzsam: *the travce
20:46karolherbst: though now i am not sure what is the right thing :O
20:47karolherbst: there is a filter drawn on top of the scene later...
20:47karolherbst: intel to the rescue then
20:47karolherbst: intel looks like 1347719
20:48karolherbst: better check 1273145 too
20:49karolherbst: yep, on intel 1273145 looks different
21:24karolherbst: hakzsam: before you dig too much time into talos, you could also check my dual issue stuff :p I think I will try to break it somehow on my nvac or check what code paths are used and try to think about something
21:30hakzsam: karolherbst, yep, anyway I won't figure out today :)
21:31hakzsam: it would be very nice to be able to compare each parameters of every draw call between two frames
21:31hakzsam: but it seems like that apitrace diff-state doesn't do exactly what I want
21:32hakzsam: and "apitrace diff" doesn't seem to help too
21:39karolherbst: yeah maybe that would help, but somewhat I doubt that
22:56imirkin_: i guess that's the cool new pascal thing?
23:01karolherbst: sounds like it
23:04karolherbst: GLX over vnc
23:04karolherbst: mhh why only softpipe though
23:11karolherbst: now it works :)
23:17karolherbst: it renders decently fast too
23:23karolherbst: imirkin_: ehm...
23:23karolherbst: I think with recent master talos broke on nv50
23:23imirkin_: aka i broke it?
23:24karolherbst: ERROR: operation should have been lowered
23:24karolherbst: well I will do a clean build on master to confirm it
23:24karolherbst: OpenGL over vnc is really awesome :)
23:34karolherbst: imirkin_: okay, seems like unclean build striked again :/
23:36imirkin_: or one of your patches? :p
23:37karolherbst: nope, I didn't touch the tgsi to something thing :p
23:37hakzsam: maybe, it's me :)
23:37hakzsam: imirkin_, anyway, we should do a full piglit before the official release
23:38hakzsam: I did on fermi and kepler
23:38hakzsam: but not on tesla
23:38imirkin_: yes ... we ...
23:38hakzsam: you have a tesla plugged in your box right? :p
23:38karolherbst: well now I have to find a way how to debug that special draw call in gdb...
23:38imirkin_: i do, but i don't want my box to die
23:38imirkin_: which is usually what happens when i run piglit
23:38hakzsam: should not die
23:38imirkin_: you're right. should not.
23:38hakzsam: at least, it doesn't on my gf119
23:39karolherbst: well I could run it over the night
23:39karolherbst: just tell me what I should do
23:41karolherbst: but I don't have that fancy f64 stuff I think?
23:42imirkin_: that's ok, i never flipped on fp64 for tesla
23:42karolherbst: I see
23:42karolherbst: just have to build all the deps first and piglit
23:42karolherbst: if you tell me how I should start piglit I will start it then