00:40 karolherbst: nice, tropico 4 runs on native d3d9 with nouveau on ultra pretty smooth :)
01:03 pmoreau: RSpliet: I have some G80-G96 I could send you, or send you their mmiotrace if you want.
01:04 pmoreau: Though only one G92 (iirc) has multiple perf levels, but most of the other ones do not boot on their single perf level.
01:05 pmoreau: And I'm finally back home, ready to test patches :-)
01:39 RSpliet: pmoreau: I can only do so much with trace unfortunately... it's really difficult to trial-and-error with them :-P
01:40 pmoreau: :D
01:41 pmoreau: I could send them to you then. I had bought them for reclocking as I wasn't sure you would finish NV50 reclocking.
01:43 pmoreau: Or, maybe I'll manage to get some kind of Reator at home... But that might take a lot of time before happening. :)
02:25 sigod: my nouveau driver keeps crashing x randomly after a certain amount of time. Where is the best place to find a crash log? I'm using a variant of archlinux.
02:26 sigod: do i need to turn on video logging?
02:32 RSpliet: sigod: what kind of crash, what are you running and how modern is your software stack?
02:50 sigod: RSpliet, x freezes. Latest kernel and driver for arch/parabola
02:50 RSpliet: ugh, infamous freezes.... yes; is that by any chance a card from the G200 series?
02:51 sigod: it's a gtx660
02:51 RSpliet: ... oh, I never saw those freeze
02:51 sigod: im running compton on xfce so it might be related to that?
02:52 karolherbst: mhh, I have found an unused nvidia FX 5500 here
02:58 jushur: sigod: is it cooled properly?
02:59 sigod: jushur, yep its 33deg atm
02:59 jushur: sigod: i have a few machines with those card and all of them i had to apply extra cooling to
02:59 jushur: 33deg? you watercoling it?
02:59 sigod: nope
02:59 sigod: that's what xsensors says
03:00 sigod: nouveau-300 33deg
03:01 jushur: sigod: is it only X that freezes?
03:01 jushur: like can you ssh in to it still?
03:01 sigod: jushur, actually now that you mention it the whole computer needs to be restarted
03:02 sigod: so it might be a kernel issue
03:02 jushur: could be power / or chipset overheating
03:02 jushur: asuming you do not OC
03:02 sigod: yea tends to happen during games
03:02 sigod: 3d games'
03:03 sigod: its fine in windows though
03:03 jushur: sigod: you using a ssd?
03:04 sigod: i have one with windows on it but its not part of my linux setup
03:04 sigod: i just have 1 2tb hd for arch
03:06 jushur: sigod: you should switch sheduler and se if it helps.
03:07 sigod: what's that?
03:08 jushur: why are you running a arch derivate if you dont know this?
03:11 sigod: jushur, i know a bit about linux, not everything
03:12 jushur: sigod: i consider that part to be basics one would know when running arch, i think you should go read abut it :)
03:13 sigod: jushur, IO schedulers?
03:14 jushur: yes
03:14 sigod: so you reckon it
03:14 sigod: its my hd?
03:14 jushur: no, its more likely the kernel
03:15 jushur: and it matters how/what scheduler you use. and my experience is this actually can matter a lot for stability.
03:16 sigod: oh ok, you don't need to reinstall the whole system do you?
03:18 karolherbst: sigod: read about if and you will know ;)
03:20 sigod: karolherbst, ok I will!
03:53 sigod: http://mynixworld.info/2011/11/10/how-to-choose-the-right-kernel-io-scheduler/
04:14 hno: I thought process scheduler would matter more for GPU matters. Don't see how I/O scheduler can make a difference.
09:45 psofa: does 2d acceleration for nv30 touch mesa at all?In other words can the commits i see at mesa fix my bad 2d performance with nv30?
09:46 imirkin_: psofa: depends what you mean by "2d performance"
09:46 imirkin_: if you mean the xorg ddx, there is no connection
09:46 imirkin_: however you might be running insane applications that think it's hilarious to use OpenGL to draw the whole screen
09:47 imirkin_: like gnome-shell
09:47 imirkin_: or many others
09:47 psofa: i mean mainly firefox /chrome slow rendering
09:47 imirkin_: psofa: to go about:gpu in chrome -- does it say "disabled" for everything?
09:47 imirkin_: if so, that's good
09:49 imirkin_: and fwiw all of my nv30 commits to mesa were about correctness, not speed
09:49 imirkin_: (/ not crashing... heh.)
09:50 psofa: cant check now (box runs the nvidia blob) but i remember in firefox i had tried to disable the layers acceleration thing and it made no difference
09:51 psofa: unfortuanately the box is remote/not mine and i cant do serious profiling
09:52 psofa: however nouveau is unusable with firefox/chromium on that card/so much that i had to install old kernel/legacy nvidia
09:55 imirkin_: well, i would totally expect a modern desktop to not be usable on a nv30
09:55 imirkin_: is it an actual nv30 btw, or nv4x?
09:57 psofa: its a 5200
09:58 psofa: on xfce
09:58 imirkin_: ah ok, that should be fine
09:58 psofa: however its fine on the blob
09:59 imirkin_: weird, i thought the nouveau 2d stuff was in pretty good shape
09:59 imirkin_: perhaps chrome is secretly trying to do 3d, which is probably a big fail
10:00 psofa: actually 1 year ago when i tested this firefox was the slowest
10:00 psofa: and im pretty sure i disabled the layer accel thing to be sure
10:01 psofa: do you ahve 'live' nv30 hardware to test on?
10:01 imirkin_: have? yes.
10:01 imirkin_: it's resting comfortably on my shelf.
10:02 imirkin_: and the idiot thing won't do 1920x1200 through DVI ;(
10:02 imirkin_: and either the electronics on mine are damaged or the whole card is crap to begin with, but 1920x1200 over VGA looked like total ass
10:10 psofa: well shit then there's no one to fix it :(
10:11 imirkin_: i also have the faint recollection that running either chrome or firefox (but not the other) would hang the whole box *hard*
10:11 imirkin_: and i couldn't get serial going to see what was up
10:11 psofa: thats not true
10:12 imirkin_: it was def true for me.
10:12 imirkin_: this was a PCIe NV34, which is a bit odd
10:12 imirkin_: it had that bridge chip
13:47 imirkin: skeggsb: any chance you could push even a prelim version of your WIP? that'd help karolherbst get going on the pcie link speed stuff
13:47 imirkin: skeggsb: or do you expect it to still change substantially?
14:51 karolherbst: imirkin: whould something like that be okay? https://github.com/karolherbst/nouveau/commit/3330d811011b672e7778426bf3c7c1068033d303
14:51 karolherbst: *they in commit message :/
14:51 imirkin: karolherbst: yeah, generally seems fine.
14:52 imirkin: karolherbst: or perhaps you can even just avoid having those "early" ones get called at all
14:52 imirkin: and just call them by hand
14:52 karolherbst: also I think the stubs could be safly removed, because they are used only guarded by #ifdef
14:52 karolherbst: mhh
14:52 karolherbst: we have to deal with the drm_minor pointers then
14:52 imirkin: ah ok, well i don't know what all core drm does
14:53 imirkin: just pointing that out as an option
14:53 karolherbst: yeah I know
14:53 karolherbst: was thinking about that same
14:53 karolherbst: but I rather not mess with core drm
14:54 karolherbst: also if you look at this https://github.com/karolherbst/nouveau/commit/8a2b9a51eb865db99487aa9087da16c341b3b606 and https://github.com/karolherbst/nouveau/commit/66e2bd3f5b8747e6d4eea9716ee67772b9d9da52
14:54 karolherbst: I used different init methods for both
14:54 karolherbst: which also is not that good I guess
14:55 imirkin: the ifdefs in nouveau_drm.c shouldn't be there...
14:55 imirkin: otherwise looks fine
14:55 karolherbst: okay, then emtpy stubs is better?
14:55 imirkin: ya
14:56 karolherbst: because the debugfs callbacks are also guarded by that
14:56 karolherbst: https://github.com/karolherbst/nouveau/blob/66e2bd3f5b8747e6d4eea9716ee67772b9d9da52/drm/nouveau/nouveau_drm.c#L964-L967
14:56 karolherbst: I have to write the stuff down, else I forget everything :/
14:57 imirkin: yeah, that's fine. but the thing you add should have stubs.
14:57 karolherbst: okay
14:57 imirkin: there it's the diff between setting and not setting
14:57 imirkin: whereas here the compiler would just inline the no-op
14:58 imirkin: and you avoid the jarring ifdef in the middle of code flow
14:58 karolherbst: okay
14:58 karolherbst: this would be the "main part" btw: https://github.com/karolherbst/nouveau/commit/0e8a889dfa77a55ee183b512fb88ef8b1c3c5756
14:59 imirkin: that looks great
14:59 karolherbst: yeah, I left the code as it was mostly
14:59 karolherbst: only replaced the s*printf with seq_printf
15:00 karolherbst: only the copy_from_user part is a bit messy
15:00 karolherbst: somebody on ppc should test it I suppose
15:06 karolherbst: imirkin: when nouveau_debugfs(m->private) == NULL, should I return -ENOSYS?
15:06 karolherbst: mhh no, doesn't make that much sense
15:06 imirkin: sure... or einval
15:06 imirkin: but ideally that should be impossible
15:06 karolherbst: ENODEV?
15:06 karolherbst: mhh
15:07 imirkin: i guess someone can open(), then rmmod nouveau, then read
15:07 imirkin: that would suck.
15:07 karolherbst: currently nouveau_debugfs_init fails silently
15:07 imirkin: as long as it doesn't add the pstate file, that's fine by me
15:07 karolherbst: imirkin: I think then everything is done already
15:07 karolherbst: will try that out :D
15:15 karolherbst: imirkin: "rmmod: ERROR: Module nouveau is in use"
15:15 imirkin: ah convenient.
15:15 karolherbst: yeah
15:16 karolherbst: still, errors in nouveau_debugfs_init aren't handled
15:16 imirkin: just don't add the file and be done with it
15:17 karolherbst: sadly the file is added before, because the drm_debugfs function is called earlier
15:17 imirkin: you can always add it later.
15:17 karolherbst: yeah, but then I need all the drm_minors
15:17 karolherbst: I guess there is an easy way to get all?
15:19 karolherbst: maybe it would be really better to add this to core drm itself :/
15:19 karolherbst: I mean, that you can set any fop you want and not just "read"
15:21 imirkin: drm does it somehow...
15:21 imirkin: also if you just add it to 1, i don't think anyone would cry too loudly
15:21 imirkin: you do have to do it per device though
15:21 imirkin: i.e. one might have multipel nvidia gpu's
15:21 karolherbst: yeah
15:21 karolherbst: :/
15:22 imirkin: it's annoying that it's done per minor
15:22 karolherbst: this is just too messy in total
15:22 imirkin: instead of per device
15:22 karolherbst: there could be good reasons for that, but yes, its not that "intuitve", also that drm itself restrict the actual drivers that much
15:22 imirkin: i guess handle the case where ctrl is null and return EINVAL or ENODEV or something
15:24 karolherbst: should never happen anyway (tm)
15:25 karolherbst: kzalloc or nvif_object_init may fail