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