00:22 RSpliet: Outlook :')
08:34 mogorva: 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:35 mogorva: it's one of your commits that broke it: http://cgit.freedesktop.org/mesa/mesa/commit/?id=9e94b87b6012450d714edc6d0c46b15a89d5ce61
08:35 Faux: <3 Nimbus.
08:41 imirkin: mogorva: hm, sadness
08:42 imirkin: errrrr
08:42 imirkin: yeah ok, a retarded monkey wrote that change =/
09:02 imirkin: er hm, on second through that patch looks ok. mogorva you could save me some time and make an apitrace
09:03 mogorva: is it enough to start the game and wait until the main menu appears?
09:03 imirkin: as long as the trace captures any of the bad behaviour, that's enough
09:04 imirkin: btw, i assume that reverting that patch on top of master "fixes" things?
09:04 mogorva: yes, that fixed the problem for me
09:05 imirkin: k
09:06 imirkin: mogorva: actually, really quick... can you try commenting out these two lines:
09:06 imirkin: + if (i->op != OP_CVT)
09:06 imirkin: + i->src(0).mod = 0;
09:07 imirkin: coz i just realized it might actually be OP_ABS/etc that gets returned
09:08 imirkin: er hm. actually that's what another place does too. so it might be right.
09:10 imirkin: oooh, interesting... ADD x, -a, -b doesn't appear to be supported.
09:21 mogorva: 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:23 imirkin: mogorva: great, repro'd on my hw. should be much easier to debug.
09:24 imirkin: can you file a bug about it so i don't forget? and any other as-yet-unfixed bugs you've found?
09:24 mogorva: k
09:26 imirkin: irc is great for discussion, but not so great for keeping track of things
09:26 imirkin: nor is my memory :)
09:26 mogorva: this game runs without steam, and renders properly with NV50_PROG_OPTIMIZE=0
09:26 imirkin: yeah that makes sense -- the constant folding is only activated with NV50_PROG_OPTIMIZE=1 or higher
09:40 imirkin: mogorva: btw, what kind of vram does your board have? ddr2 or gddr3?
09:41 imirkin: if gddr3 and you're feeling adventurous, you could try out reclocking on it
09:43 mogorva: 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:45 mogorva: is there a software for reclocking? i was never so keen on performance tuning
09:54 mogorva: 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:54 mogorva: nouveau related lines from that log: http://pastebin.com/veNuE8GZ
09:56 mogorva: is there anything in that log that might help overcome the problem?
10:05 mogorva: 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:05 imirkin_: mogorva: yeah, file it against Mesa core though, it's not a nouveau-specific issue
10:06 imirkin_: marek mailed out a different patch than i did
10:06 imirkin_: 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:07 imirkin_: if you can come up with an apitrace that repros the stack underflows, that'd be super-useful as well
10:07 mogorva: it usually happens after 5-10 mins gameplay, sometimes just after loading a saved game
10:07 imirkin_: 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:07 imirkin_: if it works
10:08 imirkin_: if not, it should make for a hung gpu :)
10:08 mogorva: and how can it be achieved?
10:08 imirkin_: you'd have to build a custom nouveau kernel module
10:08 imirkin_: there's an out-of-tree version, so if your main kernel is up-to-date-enough, it should be relatively easy
10:08 imirkin_: (4.0 kernel should def work, maybe even 3.19)
10:10 mogorva: when it hangs does it early during boot? is there a rescue mode?
10:10 imirkin_: and you'd have to make an additional patch, in that tree it's only enabled for nva0 of those early tesla's
10:10 imirkin_: nah, there's no automatic reclocking... it'd hang when you told it to reclock manually
10:10 imirkin_: so if it hangs, just don't do that again :)
10:11 mogorva: maybe later, i won't jump into it right now
10:11 imirkin_: kk
10:16 RSpliet: mogorva: don't expect much from reclocking on nouveau just yet... I've had several failed instances of non-NVA0 reclocks
10:16 RSpliet: it *could* work, but I'd be surprised :-)
10:16 imirkin_: RSpliet: for G92 + gddr3? seems like it could work :)
10:17 imirkin_: but you're the expert
10:17 RSpliet: imirkin_: well, PMoreau's G96(or 98)+gddr3 I'm thinking of in particular
10:18 imirkin_: G92 is a monster too though... G96 was a lot more ... limited
10:18 imirkin_: probably diff sets of clock speeds
10:19 RSpliet: I haven't had time to properly investigate :-)
10:24 specing: nouveau E[ PFB][0000:01:00.0] trapped write at 0x00414d0000 on channel 0x0001f7bc [mpv[20190]] PGRAPH/PROP/RT0 reason: PAGE_NOT_PRESENT
10:25 imirkin_: specing: what gpu are you on?
10:25 specing: 8600 M GT
10:25 specing: reflowed about 30 times
10:25 imirkin_: what does that translate to in Gxx or GTxxx terms?
10:25 imirkin_: (lspci -nn -d 10de: should tell you)
10:26 specing: G84 iirc
10:26 imirkin_: hm ok
10:26 specing: NVIDIA Corporation G84M [GeForce 8600M GT] (rev a1
10:26 specing: yes
10:26 imirkin_: 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:27 imirkin_: mogorva: btw, this is marek's proposed solution to that BlitFramebuffer crash -- http://patchwork.freedesktop.org/patch/52969/
10:28 mogorva: kk, i'll check the patch before sending the bug report
10:28 specing: according to dmesg this thing happened 11 days ago
10:29 specing: I have no idea what I was doing 11 days ago
10:29 specing: noticed just now
10:29 mogorva: imirkin: as far as i see this is a huge patch compared to your fix
10:30 imirkin_: mogorva: yeah, it's fixing it in a diff way
11:08 mogorva: imirkin: the patch works and fixes the crash in 2 of the games
11:11 imirkin_: but not all of them?
11:11 imirkin_: i.e. "my" patch worked better?
11:12 imirkin_: 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:14 mogorva: 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:14 imirkin_: with either my or marek's patch?
11:15 imirkin_: i.e. is there some additional issue that needs fixing?
11:16 mogorva: 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:20 imirkin_: mogorva: which latest patch? the one to do it from st_validate_state, or the one to do it on first make current?
11:21 mogorva: + _mesa_update_state(ctx);
11:21 mogorva: on handle_first_current
11:21 imirkin_: ok cool
11:22 imirkin_: can you file a bug and include all that in the summary, and add marek to the cc for it?
11:22 imirkin_: 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:24 mogorva: just one more test... i'll revert the offending commit on current git to see if those other 2 games run reliably
11:33 imirkin_: nah, that commit was just about blits. unlikely to matter for those... although who knows.
11:36 mogorva: 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:40 mogorva: imirkin: what do you think, is this a regression in mesa or not?
11:40 imirkin_: well, it's an issue. and a very annoying one. and it's interesting that my other patch fixes it, right?
11:40 mogorva: should i mention that commit that caused the problem in the bug report?
11:42 imirkin_: yeah, you can mention it, but that commit isn't necessarily the problem by itself
11:44 Yoshimo: 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:55 imirkin_: 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:56 imirkin_: 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:26 mogorva: 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:27 mogorva: the game uses opengl (in Wine) and the problem is present with the software renderer as well as when shader optimization is disabled
12:27 imirkin_: i dunno... could be a million diff issues
12:27 imirkin_: if you make a trace, i can test on i965 which i have here
12:34 mogorva: odd..replaying the trace it renders properly
12:37 imirkin_: 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:38 mogorva: i'd rather rule those 2 games out, there may be another bug hindering somewhere affecting the Unity games
12:39 imirkin_: ok, well it's a difference in approach
12:39 imirkin_: (in solving the bug)
12:39 imirkin_: 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:40 mogorva: imirkin: btw. you should try #winehackers channel , that's the place where wine devs can be found
12:41 imirkin_: meh... i'm not talking about wine development though.
12:41 mogorva: i just saw your question on #winehq a few minutes ago
12:41 imirkin_: 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:43 imirkin_: er hm, maybe it does
13:51 pmoreau: RSpliet: G96 it is :-)
13:52 pmoreau: 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:52 pmoreau: And the other PPCI writes from the blob didn't help.
13:53 imirkin_: pmoreau: do you also have gddr3?
13:55 pmoreau: Iirc, yes. Let me check
13:56 pmoreau: Yep
14:00 RSpliet: pmoreau: the PPCI writes are either to set the power budget or to increase the bus speed
14:00 RSpliet: they should be irrelevant for memory reclocking
14:01 pmoreau: That's for getting the G96 to run, not for memory reclocking.
14:01 pmoreau: If I do not clear the 8 LSB, EVO goes crazy
14:02 RSpliet: sorry, but G96 has quite a lot of words to have an LSB on
14:02 RSpliet: which reg are you talking about? :-D
14:03 pmoreau: 0x8841c
14:03 pmoreau: Are we talking about the same LSB?
14:03 pmoreau: Or did I miss a joke maybe
14:03 imirkin_: pmoreau: i thought you had gotten it to run?
14:04 pmoreau: imirkin_: The MCP79 yes, but not the G96 unless I PCI-reset it, or clear the 8 LSB of reg 0x8841c
14:04 pmoreau: But I do not consider that a proper fix
14:04 pmoreau: Especially as the blob keep them on, and still runs well
14:04 imirkin_: heh
14:05 imirkin_: the blob must know something we don't
14:06 pmoreau: :-)
14:07 imirkin_: i wonder if it just disables the engine in PMC
14:07 imirkin_: (0x200)
14:09 pmoreau: Disabling PMC seems rather extreme! :/
14:09 imirkin_: meh. whatever works, right?
14:09 imirkin_: seems like a reasonable thing to do in the gmux handler thing
14:10 imirkin_: i.e. flip the PDISPLAY bit off
14:10 imirkin_: and/or destroy the engine, not sure
14:10 imirkin_: or perhaps reinitialize it? dunno.
14:10 pmoreau: The thing is, it crashes similarly when using the G96 as main card
14:11 imirkin_: having 2 display engines driving one screen seems like a sure way to fail
14:11 pmoreau: (I didn't test if clearing the same bits work, but I would guess so)
14:11 pmoreau: Right
14:12 pmoreau: 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:33 pmoreau: Changing 0x8841c didn't affect 0x200.
14:33 pmoreau: I'll try again to not bring up a second PDISPLAY
14:35 imirkin_: right, well that makes sense
14:35 imirkin_: but ... well, it might not be so easy
14:35 imirkin_: when you switch gpu's, you also want to switch which pdisplay is active
14:35 imirkin_: that's why i was suggesting futzing with PMC
14:40 pmoreau: Oh, ok
14:40 imirkin_: but really you should figure out wtf blob does and just do that
14:40 imirkin_: perhaps it sends an EVO command that says "go to sleep"
14:42 pmoreau: 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:42 pmoreau: + some other strange things
14:42 imirkin_: that's on init? what about on switch?
14:42 imirkin_: does it destroy the EVO channel perhaps?
14:43 pmoreau: I never tried switching cards with the blob.
14:43 imirkin_: seems like a reasonable thing to do if that's what you're trying to do with linux :p
14:43 pmoreau: But, even the initialisation doesn't work for Nouveau :-)
14:43 imirkin_: er, with nouveau
14:43 imirkin_: oh
14:43 imirkin_: hm
14:44 pmoreau: 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:01 specing: Does nouveau handle GPU hotplug over pci-x (docking station)?
15:02 imirkin_: specing: should be fine... it doesn't handle it explicitly, but there's nothing really explicit to handle..
15:03 specing: I've heard Xorg's gpu switcing is nonexistent
15:03 imirkin_: that's right
15:03 imirkin_: perhaps we have diff ideas of what "handle" means
15:04 specing: can I run a seperate xorg in a linux containers environment that utilizes said GPU?
15:04 imirkin_: sure
15:04 specing: interesting
15:04 imirkin_: [not sure how the container modifies the situation... but i can't think of anything offhand]
15:05 imirkin_: obviously if you undock it, that X instance would probably get killed
15:05 specing: seperate PID/NET/MOUNT/... namespaces
15:05 imirkin_: or at the very least stop working
15:06 imirkin_: and if you use DRI3, you could even use it in your main X instance, probably
15:06 imirkin_: with DRI2 the X server has to know about the secondary gpu, but with DRI3 it doesn't
15:06 imirkin_: and i dunno if X handles gpu hotplug or not... airlied would know.
15:07 specing: since it is a 500 MB/s link, rendering to system ram is out of the question
15:08 imirkin_: ah yeah :)
15:08 imirkin_: anyways, a second Xorg instance should work fine
15:08 imirkin_: i definitely have very low expectations about a hot unplug though while that second X instance is running
16:21 imirkin_: wow, 4k decoding with vdpau doesn't kill the world. surprising!
21:27 mogorva: imirkin: thx for the patch you made for bug #91117, it indeed fixes the problem
22:01 mogorva: 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:45 mogorva: i managed to create another trace, it is still 920 MB uncompressed: https://drive.google.com/open?id=0B-tTbLKBl-tOZHNWR19xaUFNTU0&authuser=0
23:45 mogorva: here's the nouveau related lines from dmesg: http://pastebin.com/kSQtJdTv
23:47 mogorva: 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:48 mogorva: 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:55 mogorva: 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