00:22orbea: I'm having some graphical tearing in a game with PCSX2 towwards the top of the screen when moving left to right in full screen (not windowed), is it possible its related to nouveau? Apitrace shows it a little bit, but its greatly reduced compared to without apitrace. Additionally the tearing was a lot worse before vsync was turned on in PCSX2, but that tearing did not show up in apitrace at all. Screnshots
00:22orbea: do not show it at all. Trace: http://ks392457.kimsufi.com/orbea/stuff/trace/PCSX2_TOL_tearing.trace.xz Issue: https://github.com/PCSX2/pcsx2/issues/1578
00:22imirkin: when in doubt, the answer is always 'yes, it's possible it's related to nouveau'
00:23orbea: heh, fair enough
00:39imirkin: i see the tearing as well on my GK208
00:40imirkin: both DRI3 and DRI2
00:41orbea: seems only that game, but someone said they did not experience it with nvidia drivers in windows so I thought it may have somehting to do with nouveau.
00:41imirkin: unfortunately i haven't the *faintest* clue what causes tearing
00:41imirkin: [beyond the obvious]
00:41imirkin: so i couldn't even say whether the issue lay in mesa or in the kernel
00:42imirkin: (or, *gasp*, the X server. let's hope not.)
00:43imirkin: skeggsb: i'm going to do a xf86-video-nouveau release like tomorrow. please yell loudly if i shouldn't.
06:06pmoreau: imirkin: Ok. I’ll send it along with a proper description of the bug to you, most likely after XDC.
06:11skeggsb: imirkin: ack
07:51gnurou:hurts looking at the Nouveau status update
07:51gnurou: (talk, that is - thanks for the XDC livestream!)
07:52skeggsb: gnurou: hey! it's not you, i think you find all this stuff as frustrating as we do :P
07:52gnurou: yeah, but I'm pretty pissed by how things have been stalled for so long
07:57gnurou: hehe, Andy
07:59gnurou: sorry again for not being there... it was a close call :/
07:59Riastradh: Hm, XDC happening right now?
07:59gnurou: Riastradh: yup
07:59Riastradh: Where is it this time?
07:59gnurou: Riastradh: https://www.youtube.com/watch?v=2ryvYS47V0E
07:59gnurou:would like to join his apologies to Andy's
08:00gnurou: if only it was up to us... :/
08:00Riastradh: Nearly made it a couple years ago in Tolouse to yammer about NetBSD and DRM/KMS, but scheduling didn't quite work out.
08:01gnurou: the live streaming quality is really amazing, it's almost like being there
08:01Riastradh: Well, I should hope the streaming quality at a graphics conference is good!
08:02gnurou: it varies a lot depending on where it takes place and the infrastructure available
08:02gnurou: also you will notice that it is relying on Youtube...
08:03Riastradh: (Yeah, I realize it doesn't actually have much to do with the subject of the conference.)
08:06gnurou: mupuf: sorry btw, just realized I forgot to contribute to the slides >_<
08:07gnurou: mupuf: but you summarized the situation much better than I would have anyway
08:13RSpliet: gnurou: no worries... let's try and learn how we should look forward
11:22iterati: Hi, any ideas what causes an error like: kernel: nouveau 0000:01:00.0: gr: TRAP ch 12 [003f4fe000 Xorg]
11:22iterati: it happened some times when I used flash in chromium
11:23iterati: then the graphics not responding anymore
11:35karolherbst: gnurou: thank for your moral support and everything :p
11:35karolherbst: iterati: simply put, flash sucks
11:35karolherbst: but yeah, also out fault somewhat
11:41iterati: it looks an issue similar to: https://bugs.freedesktop.org/show_bug.cgi?id=93629
11:41iterati: I use the stable kepler recklock v5, not sure if it's the same for the upstream one
11:42karolherbst: well personally I would avoid flash, nouveau also has some concurrency issues overall
11:42iterati: never happened before, I use firefox, I tried chromium the last couple days for I needed flash for a site and it occured then
11:44karolherbst: yeah, it is something flash does, but it still might be nouveaus fault doing something silly
11:44RSpliet: iterati: which graphics card is it?
11:45iterati: RSpliet: it's 650 gtx
11:46RSpliet: what is the kernel version reported by uname -r ?
11:46karolherbst: I guess 4.7, otherwise my branch wouldn
11:46karolherbst: 't work
11:46iterati: 4.7.4 but the driver is from there https://github.com/karolherbst/nouveau/tree/stable_reclocking_kepler_v5
11:49RSpliet: iterati: thanks. Just had to double check the other firmware fixes had landed
14:32imirkin: mlankhorst: i get the error "Error: the path "/srv/xorg.freedesktop.org/archive/individual/driver" on the web server does not exist."
14:33waltercool: by some reason, under you guys experience, is good to switch from xf86-video-* drivers to just modesetting for all? There is some gain?
14:34waltercool: I mean, some gain to keep using the xf86 drivers
14:34imirkin: waltercool: i have no plans on supporting users using modesetting and running into issues.
14:35waltercool: imirkin: ohhh I see, I thought modesetting was some unified replacement
14:35imirkin: the people who created it certainly think so
14:36imirkin: and all the distro folk are super-happy about it
14:36waltercool: I think would let any kernel issue too wide open also
14:37waltercool: btw, tough meeting from karol today
14:37imirkin: not sure what this has to do with the kernel
14:37waltercool: imirkin: Between nouveau kernel module and nouveau mesa driver
14:38imirkin: it's a question of "do i use simple, error-handling, and well-tested paths, or do i use a clever hack on top of libGL which gets me all of the associated issues like not battle tested, not designed for long sessions, doesn't handle error conditions"
14:38imirkin: i'll let you take your pick.
14:39imirkin: of course the modesetting fans will say "fix your libGL!"
14:39imirkin: to which my response is "patches welcome"
14:39waltercool: but for example, I took my intel problem, it been working awful under xf86-video-intel driver, but some issues were solved using just modesetting, but also, that's also because that driver is quite huge basecode
14:40imirkin: oh, and note that if you get a gpu hang on intel at the wrong time, the GL driver just does an exit(). great to have inside an X server.
14:40waltercool: so, this is centralizing everything to libGL?
14:40imirkin: well, all the accel comes via GLAMOR, which is effectively an OpenGL application
14:41imirkin: i've never had any serious problems with SNA-based accel on HSW or SKL, but i guess others have
14:41imirkin: [admittedly the SKL accel bits were missing up until a few months ago]
14:41waltercool: My SKL had LOT of flickering since I bought my machine
14:42waltercool: but using modesetting just fixed that
14:42imirkin: interesting. well - did you report it to ickle?
14:42imirkin: also flickering is usually watermarks-related
14:42waltercool: Is quite known issue and very updated
14:43imirkin: dunno. worksforme.
14:43imirkin: i assume you've been using latest git, not a 1+ year old release
14:43waltercool: imirkin: Yeah, I just have ~1 month or less of updates on my gentoo
14:44imirkin: i'm not sure what you're trying to prove. either way, let ickle know and he may be able to help you. if you want to use modesetting for everything, go right ahead
14:44imirkin: if you get hangs, my condolences.
14:45waltercool: I mean, I know, I thought xf86 drivers were gonna be replaced, but now I understand the pro/cons of keeping those drivers also
14:45waltercool: I think I will have only nouveau configured, because intel is a for me until that nasty behavior can be fixed
14:46imirkin: it's just as likely that the intel thing is happening by coincidence. perhaps sna ends up keeping the gpu in a lower power state. who knows.
14:46waltercool: yup, this problem is related with rc6
14:47imirkin: so being more efficient is shooting it in the foot
14:49waltercool: but a question, keeping everything at libGL, wouldn't be better for Wayland?
14:50waltercool: because you don't need to worry about mesa
14:54imirkin: "keeping everything"?
15:23waltercool: yeah, I meant, the communications between the window server and the kernel module
15:25waltercool: well, I saw someone already asked that at freedesktop bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=94844
15:49mlankhorst: imirkin: ask daniels about it in #dri-devel?
18:02mlankhorst: imirkin: hm lets see if i can check it out..
18:04mlankhorst: oh gpg key is still valid for a bit longer, might as well release it for now
18:05imirkin_: while you still can! :)
18:40imirkin_: fancy. can you send the announcement too?
18:41imirkin_: (the release script generates the email)
18:41imirkin_: (but you probably already knew that)
18:42mlankhorst: yeah, once i figure out how to mail it from here
18:42imirkin_: git send-email? :)
18:42imirkin_: and/or the plain mail application
18:42imirkin_: depending on your local mta setup
18:44mlankhorst: yeah, need to figure out how
18:45woshty: Is there documentation on how power management currently works? Apparently setting pstate=1 is no longer required?
18:45imirkin_: woshty: "how it works"? meaning what exactly?
18:45imirkin_: like how to operate it? or what?
18:46woshty: imirkin_: Yes. Is it enabled by default? Can I set stuff somehow? Like making it run at lower freq and voltage etc.
18:46imirkin_: woshty: the pstate file is in debugfs now. works same way as it did before.
18:46imirkin_: woshty: what GPU do you have?
18:46imirkin_: what does lspci -nn -d 10de: say?
18:47woshty: 01:00.0 VGA compatible controller : NVIDIA Corporation G98M [GeForce G 105M] [10de:06ec] (rev a1)
18:47imirkin_: that _might_ be supported... do you know if it's DDR2 or GDDR3?
18:48imirkin_: (nouveau should print that as it initializes)
18:49woshty: 512MiB DDR2
18:49imirkin_: hrmph, ok. i think that's less likely to work.
18:50imirkin_: give it a shot and see what happens ;)
19:05mlankhorst: forgot how to use sendmail
19:07mlankhorst: I'll send it tomorrow morning
19:08imirkin_: iirc last time i had to do this i just telnetted into a SMTP server and did it by hand ;)
19:24imirkin_: yeah, i think that was annoying last time too ;)
19:24imirkin_: stelnet or something
19:24imirkin_: and then the goddamn thing grey-listed me
20:10mlankhorst: rightfully so!
20:11imirkin_: coz i always forget the right commands
20:11imirkin_: and apparently sending wrong commands causes you to get grey-listed
20:11imirkin_: i think sending wrong commands should cause you to be auto-whitelisted