00:19 mlankhorst: patch sent, could you try to get it in through drm-fixes for the cursor thingy? :P though that might be abusing things slightly
00:27 skeggsb: mlankhorst: i'll push it through -next, doesn't seem suitable for -fixes at all really
00:27 skeggsb: it's a big behaviour change, and who knows what else it might unearth
00:29 mlankhorst: yeah
00:29 mlankhorst: I'm mostly worried about vblank counters
00:30 mlankhorst: but that's true with suspend/resume in general
00:30 mlankhorst: the big behavioral change is that xorg will no longer be aware of suspend/resume
00:33 vinceh: gnurou: unfortunately the PMU stuff changed a bit in Maxell, and I haven't started working on that yet
02:23 night199uk: yo
02:45 mlankhorst: skeggsb: could we abuse Zero Bandwidth Clear to clear VRAM on allocation?
02:46 skeggsb: not really. it doesn't work everywhere, for starters
02:47 skeggsb: by that i mean, not on all kinds
02:48 pmoreau: skeggsb: Any thoughts on this patch? http://lists.freedesktop.org/archives/nouveau/2014-December/019380.html
02:49 skeggsb: pmoreau: honestly, i'd rather whatever issue you're having get fixed than add workarounds so problems don't get solved
02:51 pmoreau: skeggsb: The other fix is doing a `echo 1 > /sys/bus/pci/devices/.../reset` before loading Nouveau
02:53 skeggsb: sure, but *why* is that needed
02:53 pmoreau: But I'll try to find a proper fix, it just might take a long time
02:54 pmoreau: I'd like to know... :)
03:13 skeggsb: mlankhorst: doesn't appear to break my laptop, so, i'll merge it
03:13 mlankhorst: oh goodie :-)
03:13 skeggsb: i couldn't really tell any difference in the suspend/resume, but it happens pretty quickly, so, yeah
03:14 skeggsb: imirkin: btw, i was running with wayland for a bit recently (until it wasn't playing nicely with whatever crazy bullshit wine does with window management)
03:14 skeggsb: imirkin: i suspect we have some subtle bug in the 3d driver, gnome-terminal occasionally renders some text a bit oddly
03:15 skeggsb: mind you, i have nfi what was rendering the terminal.. i was assuming xwayland+glamor, nfi though
03:39 pq: skeggsb, which Wayland compositor have you tried btw?
03:39 skeggsb: pq: just g-s
03:39 pq: I'm not surprised at all that Wine would get messed up :-)
03:40 skeggsb: wine's always been a bit odd when it comes to window management, i've often wonder wtf exactly it is that it does that makes it so awful
03:40 skeggsb: wondered*
03:41 pq: I don't know, but I recall a rumour that it would be very very hard to port Wine for Wayland if not impossible.
03:41 pq: I'd guess the virtual desktop mode would be the one that could work.
03:42 skeggsb: a completely ignorant opinion i have is "how hard is it to map a win32 api window to a random rectangle and present it somewhere" ;)
03:44 mlankhorst: skeggsb: I've had weird text renders in xorg on all drivers before, sometimes shows up in terminal but also happens on radeon too
03:45 skeggsb: mlankhorst: ah, interesting.. these were like, occasional edges of an errant triangle showing through
03:46 mlankhorst: oh no, but on xorg sometimes things like a letter etc is wrong, selecting it clears the error though
03:47 skeggsb: yeah, i haven't seen that happen
05:46 imirkin: skeggsb: what gpu? kepler?
05:46 skeggsb: imirkin: yeah, gk107
05:48 imirkin: skeggsb: hm, well, if it's a regression, a bisect would be nice. otherwise let's hope it gets magically fixed by unrelated changes :)
05:48 skeggsb: no idea if it's a regression, it only happens when running wayland g-s, and i've only seen it in gnome-terminal so far too
05:50 imirkin: k
05:51 pq: gnome-terminal could be a native Wayland client, too, I believe...
11:43 pmoreau: imirkin: I did a new mmio trace with marks of plugging an external screen into my MCP79.
11:44 pmoreau: Currently sending it to mmio.dumps
11:51 RSpliet: imirkin: I just did some tests with those compiler patches
11:51 RSpliet: (MAD short opcodes)
11:51 RSpliet: one of your comments was that "dead" code should be automatically eliminated and thus I shouldn't have to check the references when folding the IMM into the opcode (long sentence is long)
11:52 RSpliet: however, dead code seems to be eliminated before RA and thus before this pass
11:53 RSpliet: I could always add a dead code elimination pass to PostRA
11:59 imirkin_: RSpliet: ohhhh, ok. i see what that's doing. add a comment there.
11:59 imirkin_: RSpliet: my main comment was that you didn't have to *delete* the thing... if you just unlink it, that's enough
11:59 imirkin_: RSpliet: it'll get deleted later
12:00 imirkin_: but you can't just unlink it if it's referenced by other stuff, so you need to check the ref count. annoying.
12:00 imirkin_: RSpliet: oh, but don't look at the refcount. check the def->uses() ir something
12:01 RSpliet: imirkin_: setSrc() and setDef should update the refcounter accordingly
12:01 imirkin_: RSpliet: yeah, they do
12:01 imirkin_: RSpliet: but very little other code looks at refcount iirc
12:02 imirkin_: it's mostly expressed in terms of defs/uses
12:03 imirkin_: in any case, add a comment to mention that there's no post-ra dce pass
12:03 imirkin_: (largely coz the splits/merges are gone and it would probably be a huge pile of fail)
12:03 imirkin_: pmoreau: try to get skeggsb to look at them :)
12:06 RSpliet: oh right... ifDead() has this condition where getDef(d)->reg.data.id >= 0) return false;
12:06 RSpliet: in other words, it always returns false after RA
12:06 RSpliet: why is that a thing?
12:09 RSpliet: oh right... that's to stop the compiler from eating the program from the output vars upwards
12:10 pmoreau: imirkin_: If they ever land in the mailbox! Maybe I just need to wait some more before the mail shows up.
12:11 imirkin_: pmoreau: it was in spam
12:12 pmoreau: Ah! I forgot to look in there! :D
12:12 pmoreau: Thanks! :)
12:14 imirkin_: fun. evo docs.
12:15 RSpliet: imirkin: btw, why not look at refCount?
12:15 RSpliet: inline int refCount() { return uses.size(); }
12:15 imirkin_: RSpliet: hah, ok. i guess it's ok then.
12:15 imirkin_: RSpliet: i guess i don't remember seeing .refCount() get used a lot
12:16 imirkin_: RSpliet: with a comment as to why that code is there, it should make sense.
12:19 RSpliet: yeah, plus an XXX inspiring others to turn it into a proper pass if we want to do more post-RA folds
12:25 imirkin_: sure, why not
12:27 RSpliet: it's free anyway
12:39 imirkin_: if(i->def(0).getFi
12:39 imirkin_: RSpliet: what's wrong with that? :p
12:49 imirkin_: RSpliet: also, is there a 3/3? i didn't get it...
13:01 pmoreau: What does EVO stand for?
13:03 RSpliet: imirkin_: no, I dropped it
13:03 RSpliet: and oh right, well, no there's nothing wrong with that
13:03 RSpliet: sorry, I missed that commend
13:03 RSpliet: kind of silly :/
13:03 RSpliet: sry
13:04 RSpliet: *comment
13:05 imirkin_: pmoreau: no clue... but it's the object that controls display stuff
13:06 pmoreau: imirkin_: Could the newly released doc help me figure out what to do in getting the external screen working?
13:07 imirkin_: pmoreau: dunno. read it, and then you'll have your answer :p
13:07 pmoreau: :D
13:15 skeggsb: pmoreau: i asked aritger at xdc one year, and he wasn't sure either
13:15 skeggsb: (about what it stands for)
13:16 pmoreau: :)
13:16 skeggsb: i stole the name from the nvidia ddx's error messages :P
13:16 pmoreau: Eh eh!
13:16 pmoreau: I have one card which has EVO in its name, but I guess it doesn't have the same meaning :D
13:19 pmoreau: skeggsb: If you have some time to have a look at the mmio traces I sent, it would be great. (External screen receives no signal from MCP79 card over DP port / or with flickering on another laptop)
13:20 pmoreau: But I guess you already have way too many things on your to-do list :)
13:22 imirkin_: pmoreau: with a DP->VGA adapter, which might be relevant...
13:23 pmoreau: Right. Will be interesting to see if the DP -> HDMI adapter yields better results, but still a week to go before I find it back.