00:22RSpliet: Outlook :')
08:34mogorva: imirkin: Hiho! When you have a little spare time, would you check this demo on Steam with Wine? http://store.steampowered.com/app/50000/ Most of the textures are semi-transparent, see the images on the left: http://imgur.com/aDhYehq (images on the right show the correct behaviour)
08:35mogorva: it's one of your commits that broke it: http://cgit.freedesktop.org/mesa/mesa/commit/?id=9e94b87b6012450d714edc6d0c46b15a89d5ce61
08:35Faux: <3 Nimbus.
08:41imirkin: mogorva: hm, sadness
08:42imirkin: errrrr
08:42imirkin: yeah ok, a retarded monkey wrote that change =/
09:02imirkin: er hm, on second through that patch looks ok. mogorva you could save me some time and make an apitrace
09:03mogorva: is it enough to start the game and wait until the main menu appears?
09:03imirkin: as long as the trace captures any of the bad behaviour, that's enough
09:04imirkin: btw, i assume that reverting that patch on top of master "fixes" things?
09:04mogorva: yes, that fixed the problem for me
09:05imirkin: k
09:06imirkin: mogorva: actually, really quick... can you try commenting out these two lines:
09:06imirkin: + if (i->op != OP_CVT)
09:06imirkin: + i->src(0).mod = 0;
09:07imirkin: coz i just realized it might actually be OP_ABS/etc that gets returned
09:08imirkin: er hm. actually that's what another place does too. so it might be right.
09:10imirkin: oooh, interesting... ADD x, -a, -b doesn't appear to be supported.
09:21mogorva: imirkin: after commenting out those 2 lines the problem is still there...here's the trace: https://drive.google.com/open?id=0B-tTbLKBl-tObmNTbmZLV08xMzA&authuser=0
09:23imirkin: mogorva: great, repro'd on my hw. should be much easier to debug.
09:24imirkin: can you file a bug about it so i don't forget? and any other as-yet-unfixed bugs you've found?
09:24mogorva: k
09:26imirkin: irc is great for discussion, but not so great for keeping track of things
09:26imirkin: nor is my memory :)
09:26mogorva: this game runs without steam, and renders properly with NV50_PROG_OPTIMIZE=0
09:26imirkin: yeah that makes sense -- the constant folding is only activated with NV50_PROG_OPTIMIZE=1 or higher
09:40imirkin: mogorva: btw, what kind of vram does your board have? ddr2 or gddr3?
09:41imirkin: if gddr3 and you're feeling adventurous, you could try out reclocking on it
09:43mogorva: it has 512 MB ddr3 vram (http://www.zotac.com/products/graphics-cards/geforce-200-series/gts-250/product/gts-250/detail/geforce-gts-250-3/sort/starttime/order/DESC/amount/10/section/specifications.html)
09:45mogorva: is there a software for reclocking? i was never so keen on performance tuning
09:54mogorva: one of my games always locks up the system completely, so that only the magic-sysRQ keys works. This is the journal for the session when such a lockup occured: http://pastebin.com/3MM7D7SC
09:54mogorva: nouveau related lines from that log: http://pastebin.com/veNuE8GZ
09:56mogorva: is there anything in that log that might help overcome the problem?
10:05mogorva: imirkin: shall I open a bugreport for the crash issue that we talked about yesterday? Now that mesa-10.6 hit the fedora 22 repos, the problem is reproducible with those version as well.
10:05imirkin_: mogorva: yeah, file it against Mesa core though, it's not a nouveau-specific issue
10:06imirkin_: marek mailed out a different patch than i did
10:06imirkin_: mogorva: the stack issue is some sort of control flow fail. man, i've never seen *any* of these before... i guess i almost never actually play games
10:07imirkin_: if you can come up with an apitrace that repros the stack underflows, that'd be super-useful as well
10:07mogorva: it usually happens after 5-10 mins gameplay, sometimes just after loading a saved game
10:07imirkin_: as for reclocking, your gpu boots at half of its rated core frequency, and 1/4 of the memory clock. should make for a huge change in perf
10:07imirkin_: if it works
10:08imirkin_: if not, it should make for a hung gpu :)
10:08mogorva: and how can it be achieved?
10:08imirkin_: you'd have to build a custom nouveau kernel module
10:08imirkin_: there's an out-of-tree version, so if your main kernel is up-to-date-enough, it should be relatively easy
10:08imirkin_: (4.0 kernel should def work, maybe even 3.19)
10:10mogorva: when it hangs does it early during boot? is there a rescue mode?
10:10imirkin_: and you'd have to make an additional patch, in that tree it's only enabled for nva0 of those early tesla's
10:10imirkin_: nah, there's no automatic reclocking... it'd hang when you told it to reclock manually
10:10imirkin_: so if it hangs, just don't do that again :)
10:11mogorva: maybe later, i won't jump into it right now
10:11imirkin_: kk
10:16RSpliet: mogorva: don't expect much from reclocking on nouveau just yet... I've had several failed instances of non-NVA0 reclocks
10:16RSpliet: it *could* work, but I'd be surprised :-)
10:16imirkin_: RSpliet: for G92 + gddr3? seems like it could work :)
10:17imirkin_: but you're the expert
10:17RSpliet: imirkin_: well, PMoreau's G96(or 98)+gddr3 I'm thinking of in particular
10:18imirkin_: G92 is a monster too though... G96 was a lot more ... limited
10:18imirkin_: probably diff sets of clock speeds
10:19RSpliet: I haven't had time to properly investigate :-)
10:24specing: nouveau E[ PFB][0000:01:00.0] trapped write at 0x00414d0000 on channel 0x0001f7bc [mpv[20190]] PGRAPH/PROP/RT0 reason: PAGE_NOT_PRESENT
10:25imirkin_: specing: what gpu are you on?
10:25specing: 8600 M GT
10:25specing: reflowed about 30 times
10:25imirkin_: what does that translate to in Gxx or GTxxx terms?
10:25imirkin_: (lspci -nn -d 10de: should tell you)
10:26specing: G84 iirc
10:26imirkin_: hm ok
10:26specing: NVIDIA Corporation G84M [GeForce 8600M GT] (rev a1
10:26specing: yes
10:26imirkin_: no idea why that'd happen =/ i know that G92's have serious issues with vdpau decode, but they're an anomaly in that generation
10:27imirkin_: mogorva: btw, this is marek's proposed solution to that BlitFramebuffer crash -- http://patchwork.freedesktop.org/patch/52969/
10:28mogorva: kk, i'll check the patch before sending the bug report
10:28specing: according to dmesg this thing happened 11 days ago
10:29specing: I have no idea what I was doing 11 days ago
10:29specing: noticed just now
10:29mogorva: imirkin: as far as i see this is a huge patch compared to your fix
10:30imirkin_: mogorva: yeah, it's fixing it in a diff way
11:08mogorva: imirkin: the patch works and fixes the crash in 2 of the games
11:11imirkin_: but not all of them?
11:11imirkin_: i.e. "my" patch worked better?
11:12imirkin_: btw, i've found the (a?) shader that gets broken with my OP_MAD thing, for some reason it flips the neg bits incorrectly. instead of a-b it does b-a. trying to figure out why
11:14mogorva: there's something strange with the other 2 games, both with Unity engine 3.5. The crash remains in them, and it's somehow related to the graphical settings. If it's high they crash, if I reduce e.g. texture quality or disable AA they run.
11:14imirkin_: with either my or marek's patch?
11:15imirkin_: i.e. is there some additional issue that needs fixing?
11:16mogorva: your latest patch worked better with those 2 games. Those games unfortunately don't produce a backtrace or crashdump, I can't really tell if it *is* the same problem. Skydrift and How to Survive definitely works with either patch.
11:20imirkin_: mogorva: which latest patch? the one to do it from st_validate_state, or the one to do it on first make current?
11:21mogorva: + _mesa_update_state(ctx);
11:21mogorva: on handle_first_current
11:21imirkin_: ok cool
11:22imirkin_: can you file a bug and include all that in the summary, and add marek to the cc for it?
11:22imirkin_: and make a mention of which games it is you're talking about... he works at amd, and suspect that he has access to a variety of titles
11:24mogorva: just one more test... i'll revert the offending commit on current git to see if those other 2 games run reliably
11:33imirkin_: nah, that commit was just about blits. unlikely to matter for those... although who knows.
11:36mogorva: the 2 Unity games don't behave consistently even when the commit is reverted: sometimes they start, other times they crash on start so I'd rule them out.
11:40mogorva: imirkin: what do you think, is this a regression in mesa or not?
11:40imirkin_: well, it's an issue. and a very annoying one. and it's interesting that my other patch fixes it, right?
11:40mogorva: should i mention that commit that caused the problem in the bug report?
11:42imirkin_: yeah, you can mention it, but that commit isn't necessarily the problem by itself
11:44Yoshimo: phoronix mentions a big change ben skeggs is working on and which didn't make it for the current kernel merge window, what is it about?
11:55imirkin_: mogorva: hah. so with that OP_MAD thing, the bug is actually not in that change. it just makes the path open for some old buggy code to have an effect.
11:56imirkin_: mogorva: in bug 91118 can you also discuss the effect of the various patches that have been proposed to fix it (specifically both mine and marek's)?
12:26mogorva: would you have a look at this video and tell if this is some kind of z-order issue that I have here: https://drive.google.com/open?id=0B-tTbLKBl-tOeFpYaVFXY1BSc1U&authuser=0
12:27mogorva: the game uses opengl (in Wine) and the problem is present with the software renderer as well as when shader optimization is disabled
12:27imirkin_: i dunno... could be a million diff issues
12:27imirkin_: if you make a trace, i can test on i965 which i have here
12:34mogorva: odd..replaying the trace it renders properly
12:37imirkin_: mogorva: didn't you say that the patch in https://bugs.freedesktop.org/show_bug.cgi?id=91118#c1 also fixed some other games that the other proposed patches didn't fix?
12:38mogorva: i'd rather rule those 2 games out, there may be another bug hindering somewhere affecting the Unity games
12:39imirkin_: ok, well it's a difference in approach
12:39imirkin_: (in solving the bug)
12:39imirkin_: marek's approach is just solving the most direct cause (i.e. null deref) whereas mine tries to figure out wtf happened and why an unexpected situation occurs
12:40mogorva: imirkin: btw. you should try #winehackers channel , that's the place where wine devs can be found
12:41imirkin_: meh... i'm not talking about wine development though.
12:41mogorva: i just saw your question on #winehq a few minutes ago
12:41imirkin_: anyways, wtvr. i don't really care. i also don't think d3d9 has depth volume textures either, so it might be the game directly using opengl
12:43imirkin_: er hm, maybe it does
13:51pmoreau: RSpliet: G96 it is :-)
13:52pmoreau: I didn't had much time to go back to it. I only find that turning bit 5 on while keeping bits 7:0 off would make it crash.
13:52pmoreau: And the other PPCI writes from the blob didn't help.
13:53imirkin_: pmoreau: do you also have gddr3?
13:55pmoreau: Iirc, yes. Let me check
13:56pmoreau: Yep
14:00RSpliet: pmoreau: the PPCI writes are either to set the power budget or to increase the bus speed
14:00RSpliet: they should be irrelevant for memory reclocking
14:01pmoreau: That's for getting the G96 to run, not for memory reclocking.
14:01pmoreau: If I do not clear the 8 LSB, EVO goes crazy
14:02RSpliet: sorry, but G96 has quite a lot of words to have an LSB on
14:02RSpliet: which reg are you talking about? :-D
14:03pmoreau: 0x8841c
14:03pmoreau: Are we talking about the same LSB?
14:03pmoreau: Or did I miss a joke maybe
14:03imirkin_: pmoreau: i thought you had gotten it to run?
14:04pmoreau: imirkin_: The MCP79 yes, but not the G96 unless I PCI-reset it, or clear the 8 LSB of reg 0x8841c
14:04pmoreau: But I do not consider that a proper fix
14:04pmoreau: Especially as the blob keep them on, and still runs well
14:04imirkin_: heh
14:05imirkin_: the blob must know something we don't
14:06pmoreau: :-)
14:07imirkin_: i wonder if it just disables the engine in PMC
14:07imirkin_: (0x200)
14:09pmoreau: Disabling PMC seems rather extreme! :/
14:09imirkin_: meh. whatever works, right?
14:09imirkin_: seems like a reasonable thing to do in the gmux handler thing
14:10imirkin_: i.e. flip the PDISPLAY bit off
14:10imirkin_: and/or destroy the engine, not sure
14:10imirkin_: or perhaps reinitialize it? dunno.
14:10pmoreau: The thing is, it crashes similarly when using the G96 as main card
14:11imirkin_: having 2 display engines driving one screen seems like a sure way to fail
14:11pmoreau: (I didn't test if clearing the same bits work, but I would guess so)
14:11pmoreau: Right
14:12pmoreau: I tried at some point to prevent the creation of the second display, but when starting X, it would query for some info about the cards and that crashed iirc
14:33pmoreau: Changing 0x8841c didn't affect 0x200.
14:33pmoreau: I'll try again to not bring up a second PDISPLAY
14:35imirkin_: right, well that makes sense
14:35imirkin_: but ... well, it might not be so easy
14:35imirkin_: when you switch gpu's, you also want to switch which pdisplay is active
14:35imirkin_: that's why i was suggesting futzing with PMC
14:40pmoreau: Oh, ok
14:40imirkin_: but really you should figure out wtf blob does and just do that
14:40imirkin_: perhaps it sends an EVO command that says "go to sleep"
14:42pmoreau: It creates a core + base channels on both cards, then deletes then on both cards, then recreate core + base + cursor (+ overlay?) on the main card
14:42pmoreau: + some other strange things
14:42imirkin_: that's on init? what about on switch?
14:42imirkin_: does it destroy the EVO channel perhaps?
14:43pmoreau: I never tried switching cards with the blob.
14:43imirkin_: seems like a reasonable thing to do if that's what you're trying to do with linux :p
14:43pmoreau: But, even the initialisation doesn't work for Nouveau :-)
14:43imirkin_: er, with nouveau
14:43imirkin_: oh
14:43imirkin_: hm
14:44pmoreau: Well, it kinda work, except that some PDISPLAY operation takes way longer at some point, and when it tries to stop vblank on base channel, it goes wrong
15:01specing: Does nouveau handle GPU hotplug over pci-x (docking station)?
15:02imirkin_: specing: should be fine... it doesn't handle it explicitly, but there's nothing really explicit to handle..
15:03specing: I've heard Xorg's gpu switcing is nonexistent
15:03imirkin_: that's right
15:03imirkin_: perhaps we have diff ideas of what "handle" means
15:04specing: can I run a seperate xorg in a linux containers environment that utilizes said GPU?
15:04imirkin_: sure
15:04specing: interesting
15:04imirkin_: [not sure how the container modifies the situation... but i can't think of anything offhand]
15:05imirkin_: obviously if you undock it, that X instance would probably get killed
15:05specing: seperate PID/NET/MOUNT/... namespaces
15:05imirkin_: or at the very least stop working
15:06imirkin_: and if you use DRI3, you could even use it in your main X instance, probably
15:06imirkin_: with DRI2 the X server has to know about the secondary gpu, but with DRI3 it doesn't
15:06imirkin_: and i dunno if X handles gpu hotplug or not... airlied would know.
15:07specing: since it is a 500 MB/s link, rendering to system ram is out of the question
15:08imirkin_: ah yeah :)
15:08imirkin_: anyways, a second Xorg instance should work fine
15:08imirkin_: i definitely have very low expectations about a hot unplug though while that second X instance is running
16:21imirkin_: wow, 4k decoding with vdpau doesn't kill the world. surprising!
21:27mogorva: imirkin: thx for the patch you made for bug #91117, it indeed fixes the problem
22:01mogorva: i have a trace from a game that completely locks up my system, usually after 5-10 mins. The trace file is 15 GB, is it worth the effort to compress and make it available somewhere for further analysis?
23:45mogorva: i managed to create another trace, it is still 920 MB uncompressed: https://drive.google.com/open?id=0B-tTbLKBl-tOZHNWR19xaUFNTU0&authuser=0
23:45mogorva: here's the nouveau related lines from dmesg: http://pastebin.com/kSQtJdTv
23:47mogorva: the problem first appeared @07:45:52 when the game halted for 5-6 secs then it resumed and everything seemed to be in order. At this point nouveau spit several messages in dmesg
23:48mogorva: in the next few minutes i was able to restart the game twice, the final system freeze occurred on the 3rd run nearly @08:01:17
23:55mogorva: the trace file is from the last run, it contains only ~1400 frames, on a freshly booted system I had to replay the trace 3 times in a row to reproduce the crash