00:03pmoreau: RSpliet: I can test it in about two weeks on my NVA0.
00:04pmoreau: Or *maybe* I could test it sooner: I don't remember if we have an NVA0 or not at work. I'll check when I arrive.
00:10pmoreau: Cool! The switch error is due to this unresolved PDISP EVO error thing on the G96.
00:11pmoreau: So most likely the serie of patches is correct, and I still need to fix the error separately.
00:12pmoreau: And it seems like suspending/resuming the card cancels the bonus from the PCI-reset.
00:24hakzsam_: pmoreau, thanks for adding me to the board
00:27pmoreau: hakzsam_: Np! I thought I didn't had the right to do it, but apparently when I had a look this morning, I was able to do it. :)
02:14pmoreau: hansg: Not sure if it will help, but you could probably have a look at http://lists.freedesktop.org/archives/dri-devel/2015-May/083613.html
03:35hansg: pmoreau, thanks that is interesting.
03:59imirkin: hansg: fwiw a non-totally-horrible fix would be to default GLXVblank mode to off :)
04:00imirkin: hansg: you might also try to reach out to Mario Kleiner about all this... he seems to know an awful lot about vblanking
04:01imirkin: [er, i meant to default glxvblank to off for < nv50]
04:09hansg: Thanks for the tips
08:01pmoreau: All those evo_wait issues... :D
08:03imirkin_: diff ones though
08:04pmoreau: Could be that we're missing some step, but it only uncovers under different failing environment?
08:15pmoreau: Hum, it should be a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=90632, right?
08:15tobijk: pmoreau: yeah right ishould have checked that :)
08:21pmoreau: They have different side issues, but seem to share the main one at least.
08:21pmoreau: Hopefully it could be bisected, on the contrary to the HUB_INIT TIMEOUT one.
08:41hakzsam: imirkin, did you see? Detlev gets a segfault with apitrace while tracing League of Legends ...
08:41hasenov: hey everyone, what would happen if I set nouveau fan control to None?
08:41hasenov: am i in danger?
08:42hasenov: my desktop keeps cranking up the fan and then slowing it down at random intervals
08:42hasenov: when nouveau fan control is set to auto
08:46imirkin_: hasenov: you can play with the trip points
08:46imirkin_: hasenov: basically it uses information in the vbios about when it should speed the fan up and down in response to temperature changes
08:47hasenov: i used this: https://wiki.archlinux.org/index.php/Nouveau#Fan_Control
08:47imirkin_: hasenov: iirc "none" means "max speed", so probably not what you want. but you can flip it to manual which will let you set the pwm duty cycle
08:49hasenov: imirkin_: so what will happen if I set to manual at 40%?
08:50hasenov: when the gpu at 40% of maximum temp it will turn the fan on?
08:50hasenov: and setting it to none will turn the fan on when the gpu temp reaches max?
08:50hasenov: ie 100%?
08:50imirkin_: hasenov: 40 = 40% of max fan speed
08:51imirkin_: it's a constant rate irrespective of anything else going on
08:51imirkin_: none means "nouveau doesn't touch anything ever". of course if you set it *after* nouveau has touched things, it won't undo what it did
08:57megari: Are there plans to merge the nvc0 tessellation patches within the following few weeks?
08:58megari: (just curious, no hurry of course)
08:59imirkin_: megari: i sorta meant to push them
08:59imirkin_: megari: but i'm going away for a few weeks, don't want to break everything and leave :)
08:59megari: Ah, I see.
09:00imirkin_: nvc0-tess in my tree.
09:03megari: I see there have been patches which seem to lay some groundwork for tessellation in mesa in general, and then there are patches to enable for specific drivers, such as nvc0-tess. What is the relation between them?
09:05megari: I mean, are the nvc0-tess patches independent from the groundwork ones.
09:06imirkin_: megari: well, marek and i pushed the gallium support patches
09:06imirkin_: which means that the gallium driver dev can happen separately from the mesa core dev
09:06imirkin_: instead of all having to be in a single awkward tree
09:07imirkin_: so my nvc0-tess branch enables tess support in the gallium driver, but no state tracker makes use of it, so it's limited in usefulness as-is
09:11megari: I see.
09:13imirkin_: if you want to play with it, i have an integration branch which merges the various trees
09:13imirkin_: however note that there are known bugs on all the supported chips
09:14imirkin_: (but on the bright side, the bugs are different!)
09:17rah: nouveau E[ PFIFO][0000:01:00.0] write fault at 0x0000260000 [PTE] from GR/GPC0/PROP_0 on channel 0x007fb20000 [Xorg]
09:17rah: nouveau E[ PFIFO][0000:01:00.0] PGR engine fault on channel 2, recovering...
09:17rah: the driver lies
09:17rah: it has not recovered
09:17imirkin_: it didn't say recovered
09:18rah: indeed, it said recovering, not "attempting to recover"
09:18imirkin_: it's in the process of recovering
09:18imirkin_: that process appears to have stalled :)
09:18rah: I've had a couple of crashes playing 0 A.D. recently
09:19rah: this is Not Good
09:20rah: I'm guessing that doesnt help?
09:21imirkin_: rah: that just means "gpu is stuck" :)
09:21imirkin_: but you already knew that
09:25rah: I had an inkling
09:41yusukesuzuki: imirkin_: hi, are you around?
09:43imirkin_: how goes the trap handling?
09:47yusukesuzuki: imirkin_: except for one big issue, it looks going well
09:47imirkin_: is the big issue "it doesn't work at all"?
09:47yusukesuzuki: imirkin_: when bpt pause 0x0 is exeuted, only GPC0/UNK00 causes read page fault immediately...
09:47yusukesuzuki: [95501.485273] nouveau E[ PFIFO][0000:00:04.0] read fault at 0x0000000000 [PAGE_NOT_PRESENT] from PGRAPH/GPC0/UNK00 on channel 0x017f8dd000 [user_test[5 574]]
09:48imirkin_: do you forget to set a CODE_ADDRESS + the other thing? can i see user_test?
09:49yusukesuzuki: imirkin_: sure, wait a moment
09:51imirkin_: you're using "bpt pause" inside the trap handler, right? you can't use it outside...
09:51yusukesuzuki: imirkin_: yes. i'm using bpt pause inside the trap handler.
09:52imirkin_: and this is on fermi yes?
09:52imirkin_: (which one?)
09:53yusukesuzuki: GF100 (nvc0), Quadro 6000 card
09:54yusukesuzuki: https://github.com/CPFL/linux/compare/39a8804455fb23f09157341d3ba7db6d7ae6ee76...prototype this is nouveau side change
09:54imirkin_: one thing i'd try is to use blob ctxsw firmware rather than the nouveau one -- we could easily have missed something in that area
09:55yusukesuzuki: change is large, so i'll point the important places
09:55imirkin_: you can use my script to extract it from the blob
09:55yusukesuzuki: imirkin_: oh, that sounds nice.
09:56imirkin_: make sure to use exactly that blob version or it won't extract the graph ctxsw fw
09:58yusukesuzuki: imirkin_: this sounds nice. Since unk00 error is caused (in GPC0), I was thinking i need to investigate firmware side
09:59imirkin_: well, test out blob fw first. if it still doesn't work with blob fw, you got more work ahead of you.
09:59imirkin_: note that the recommendation is to use the fw to write some of the mmio regs
09:59imirkin_: which i'm 90% sure the nouveau fw doesn't actually support
10:02yusukesuzuki: imirkin_: leveraging scratch & firmware in document?
10:15yusukesuzuki: imirkin_: thx so much, i'll try it :D
10:17yusukesuzuki: imirkin_: ah, i have one question. SCRATCH seems SCRATCH0 in falcon's IO interface. But it seems that there's no FIRMWARE IO reg. is it renamed to something?
10:19imirkin_: probably ;)
10:19imirkin_: graph/gf100_3d.xml: <reg32 offset="0x2300" name="FIRMWARE" length="0x20"/>
10:19imirkin_: it's in reference to that, i believe
10:20imirkin_: which you do from the userspace driver
10:23imirkin_: yusukesuzuki: although that's just for setting the trap handler start PC.
10:24imirkin_: presumably whatever you're doing is working well enough for that
10:25imirkin_: yusukesuzuki: what's the thing you added to gpc.fuc?
10:26yusukesuzuki: imirkin_: i set debugging mode to mp register when ctx is loaded. https://github.com/CPFL/linux/compare/39a8804455fb23f09157341d3ba7db6d7ae6ee76...prototype#diff-2b174a3c0a82fb93b3d3cf0a8840374bR374
10:27imirkin_: yusukesuzuki: uhm... perhaps i have things wrong, but that seems like the wrong MP address
10:29yusukesuzuki: imirkin_: oh. in this code, calcuated the BPT_CONTROL addr from the current gpc id/tpc num and set debugging bit.
10:36imirkin_: yusukesuzuki: right, this just seems wrong -- +#define MP_UNIT(t, m, r) (0x504000 + (t) * 0x8000 + (m) * 0x800 + 0x600 + (r))
10:36imirkin_: but... i could just be misremembering the organization of things
10:37imirkin_: yusukesuzuki: actually i'm totally wrong. your MP_UNIT thing is right
10:39yusukesuzuki: imirkin_: ah ok. after loading this (crafted) firmware, i saw the bpt_control becomes 0x1
10:39yusukesuzuki: without setting 0x1 in user side
10:40imirkin_: shader can trap i think
10:40imirkin_: er wait, 0x1 seems reasonable
10:40imirkin_: just means debugging enabled
10:40imirkin_: i guess blob fw writes that?
10:41imirkin_: (it's context-switched, so it can do whatever it wants)
10:43imirkin_: yusukesuzuki: is your "user_test" available somewhere too?
10:43yusukesuzuki: imirkin_: ah, sorry. I've foggot to paste the url.
10:44imirkin_: yusukesuzuki: btw, does 'guc' actually work?
10:44yusukesuzuki: imirkin_: https://github.com/CPFL/guc ?
10:45imirkin_: i mean, i'm sure it works for the examples in question. but would it be usable for nouveau's fw?
10:46yusukesuzuki: imirkin_: I've checked it 2 weeks ago, run the example (https://github.com/CPFL/guc/tree/master/test/test_xfers etc.) and it seems it works.
10:46imirkin_: iirc skeggsb said that he had trouble with it
10:46imirkin_: but perhaps he tried it too long ago
10:47yusukesuzuki: imirkin_: ah, the compiler part might have a bug. it once dump the envyas' asm file so we can check the output is expected
10:54imirkin_: yusukesuzuki: anyways, you seem to generally have the hang of things. i would recommend you re-read that single-stepping document again now that you've played around with it
10:55imirkin_: it'll probably make a lot more sense now ;)
10:57yusukesuzuki: imirkin_: ok, thanks again :D
11:34imirkin_: skeggsb: https://bugs.freedesktop.org/attachment.cgi?id=116090
11:34imirkin_: does that seem like a good idea?
11:35imirkin_: i don't see any mechanism for the pushbuf to be flushed otherwise... of course it all ends up working out as long as you keep things on the gpu
11:46ouned: hey! im currently testing nouveau on ubuntu 15.04 with the (hopefully?) latest git version of mesa nouveau etc. on my gtx 870m and it just does nothing at all when using DRI_PRIME=1 (it just uses the Intel card)
11:47ouned: in the logs it says HUB_INIT timed out http://paste.debian.net/184682/
11:48imirkin_: ouned: what kernel? i've seen a lot of GK106's with this issue, but GK104 is rare
11:49ouned: Linux ounednb-testing 4.1.0-040100rc5-generic #201505250235 SMP Mon May 25 02:37:02 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
11:49ouned: i also tested an older kernel but it didnt make a difference
11:50ouned: it seems to do something with the card since it at least turns it off on booting
12:02imirkin_: ouned: yeah, but it can't seem to bring it back up =/
12:02imirkin_: ouned: what if you boot with nouveau.runpm=0 ?
12:05ouned: imirkin_: im going to test that!
12:29ouned: imirkin_: it seems to work
12:29ouned: DRI_PRIME=1 glxinfo shows nouveau and glxgears works but icant see if it actually runs on it ofc
12:30imirkin_: ouned: well, difficult to prove something like that... but you could use an application that uses a feature implemented on nvc0 and not intel
12:31imirkin_: ouned: if you're using mesa 10.6 or mesa-git, fp64 is available on nvc0 and not on i965
12:31imirkin_: (but there aren't really applications that actually use fp64... heh.)
12:32ouned: DRI_PRIME=0 glxgears means 60FPS DRI_PRIME=1 glxgears means 3100FPS ? :o
12:32ouned: oh vsync
12:32imirkin_: either that or the nvidia gpu is 50x faster
12:32imirkin_: glxgears is actually terrible for testing performance
12:32imirkin_: btw if you boot with nouveau.pstate=1 you should be able to reclock the nvidia gpu as well
12:33ouned: does that mean it will shutdown when not used?
12:34imirkin_: you need runpm for that
12:34imirkin_: the pstate thing just lets you (manually) switch between performance levels defined by your vbios
12:34ouned: cool. i thought nouveau lacks that
12:34imirkin_: as you have GDDR5 vram, note that it's most likely that the two higher levels will result in GPU hangs. but perhaps worth trying out, they do work for some people.
12:37ouned: so the runpm bug is a known one?
12:38imirkin_: ouned: not really. and i guess your issue is a little diff than other people's. i don't think runpm=0 helps them.
12:38imirkin_: ouned: unfortunately to debug it, the right person would need access to the right hardware and bang his head against it while debugging
12:38tobijk: which kernel is that?
12:38imirkin_: ouned: there's only one such person atm btw [and it's not me]
12:39ouned: tobijk: 4.1rc5 if you meant me
12:40ouned: imirkin_: how hard is it to get into nouveau development?
12:40tobijk: ouned: yeah and with that my guess is wrong
12:40imirkin_: ouned: depends on the person... and that person's goals
12:40tobijk: we had a few fixes in 3.19 but not enough for your card :/
12:40imirkin_: ouned: if that person's goals is to fix things that the most experienced devs have failed at for months or more, then very hard ;)
12:41ouned: :D :D
12:41imirkin_: but imo it's pretty accessible if you start small
12:41imirkin_: i started out by fixing a crash in xf86-video-nouveau which was *incredibly* annoying
12:42imirkin_: and moved on to adding vdpau support for a line of GPU's, which was probably more ambitious than i should have done
12:43imirkin_: if you're looking to start, decide on an area of interest, and then try to get someone to give you a reasonably-sized pre-thought-out task
12:47ouned: okey. i have zero experience with drivers though. i did a lot of stuff in userspace but never looked into those things.
12:52imirkin_: ouned: are you familiar with C?
12:52imirkin_: ouned: how about hexadecimal :)
13:03ouned: imirkin_: yes. i started with c and have 5 of years expirience. but only userspace. hex is just a number system isnt it? :p
13:04imirkin_: ouned: yeah, but being able to quickly recognize what e.g. 0x80000000 is can be helpful
13:07pmoreau: That will come anyway after playing with mmiotraces for some time :)
13:07ouned: imirkin_: i know what you mean i cant really think in hex, so no :D
13:08ouned: im also afraid of how to debug a driver since you cant just use gdb
13:09tobijk: imirkin_: are you making people run again? :D
13:09imirkin_: when have i ever?! :p
13:10tobijk: getting people scared about working with code ^^
13:11tobijk: ouned: you can as well work on mesa, that may not help with your provlem, but would help nouveau
13:24ouned: hehe I just ran a quake3 engine based game on it and it has about 55 FPS in this power state
13:25imirkin_: but at crazy-high resolution?
13:26ouned: no, 1600x900 in windowed mode
13:26imirkin_: well... you're in the lowest power level
13:26drago01: q3 would run with decent fps on a toaster ;)
13:27ouned: the intel card has about 110 FPS
13:27ouned: it's not exactly q3 though
13:27ouned: it has some additional things which eat fps
13:27imirkin_: try a higher perf level
13:28imirkin_: faster ram makes a *really* big difference ;)
13:30tobijk: mh old game, maybe the cpu is the bottelneck...
13:31ouned: im going to test pstate :>
13:33imirkin_: yeah, i mean with reverse prime, there's a bit of a limit on the fps
13:34imirkin_: with prime
13:34imirkin_: (but also with reverse prime ;) )
13:42ouned: can i somehow see where i'm in the moment?
13:43RSpliet: ouned: the line marked "AC" is the current
13:46ouned: it works :D
13:48imirkin_: does it go faster too?
13:48ouned: hmmm not much
13:48imirkin_: well, 0e/0f will probably hang your gpu
13:48ouned: i cant really say if at all
13:48imirkin_: but you could try them out
13:49ouned: no im at 0f and ingame
13:49imirkin_: oh... did the reclock succeed?
13:49imirkin_: check dmesg
13:49imirkin_: it probably failed :)
13:49tobijk: ouned: test with something different, graphics benachmark or such
13:49ouned: error setting pstate 2: -22
13:49tobijk: it i really noticable for me and i only have ddr3 :>
13:49imirkin_: yeah, so... fail :)
13:50imirkin_: start with 0a, that one's mroe likely to work
13:50tobijk: cat pstate will tell as well
13:52ouned: 100FPS with 0a
13:54ouned: there is no difference when switching the states 08 and 0a though
13:54imirkin_: are you sure the switches are working?
13:55ouned: i dont think they work at all: http://paste.debian.net/184747/
13:56imirkin_: yeah... fail =/
13:56imirkin_: i dunno what's up with the voltage stuff
13:56imirkin_: hopefully skeggsb will fix it up when he gets back to kepler reclocking
13:57ouned: the game runs with 230FPS when i switch off dynamic glow though :D
13:58tobijk: and you benefit from it? i doubt it :>
13:59ouned: nah its just has to :P
13:59ouned: but it seems to run very stable and PRIME seems to work
14:00ouned: something i have noticed with runpm=0: my system actually shutdowns correctly with it
14:01tobijk: and before it did what? failed to idle channel?
14:01ouned: with runpm=1 when i sudo restart the system instantly completely freezed and nothing happended at all
14:01ouned: but: the LED indicating that the nvidia gpu is running turns on
14:02tobijk: so we cant really talk about shutdown ;D
14:02ouned: no :D
14:03ouned: what i have noticed when using windows is that it always turn on the nvidia gpu before it finally turns off the notebook btw.
14:05imirkin_: ouned: yeah, that's a reported issue
14:05imirkin_: ouned: [the shutdown fail]
14:06imirkin_: and a semi-recent one at that
14:07ouned: i just wondered since it fails powering on the gpu with DRI_PRIME but then on shutdown it somehow turns on
14:07imirkin_: it doesn't fail to power on the gpu, it fails to start up PGRAPH
14:10RSpliet: skeggsb: speaking of mountains of work, is libdrm 2.4.61 on it's way to F21?
14:12RSpliet: I'll probably install F22 tomorrow, but on F21 I can pretty reliably hit the validate error with certain sequences of "mouse events"
14:17ouned: imirkin_: what is pgraph?
14:18imirkin_: ouned: it's the engine inside the chip which handles all the 2d/3d drawing functions
14:22ouned: NvGrUseFW (http://nouveau.freedesktop.org/wiki/KernelModuleParameters/) is this somehow related?
14:23imirkin_: nnnot really
14:32skeggsb: imirkin_: libdrm will do that for you (re: the ddx patch)
14:32skeggsb: imirkin_: see nouveau_bo_wait()
14:32imirkin_: skeggsb: PUSH_KICK? how will it know which pushbuf?
14:33imirkin_: push = cli_push_get(client, bo);
14:33imirkin_: hmmm... i wonder how that works
14:35imirkin_: oh dear.
14:35skeggsb: it returns the pushbuf (if any) a buffer is referenced in but not flushed
14:35imirkin_: this gets well into the "i have no idea how that bit of libdrm works" territory
14:35imirkin_: didn't realize nouveau_bo_wait flushed though... that's nice
14:35imirkin_: puts a bit of a dent in my genius theory though
14:47ouned: okey guys, im out. thanks a lot for the help. going to stick with the intel one meanwhile :D
14:56joi: imirkin_: varinfo_set_variant(var, "gf100") does not seem to matter for those traces..
14:57imirkin_: it should fix that one instruction
14:57imirkin_: search for suld
14:58imirkin_: there will be opcodes with ???
15:02joi: 00000070: 20011c05 dc1e1000 ??? [unknown: 20010000 dc1e1000] [unknown instruction]
15:02joi: this one?
15:04imirkin_: ok. that one's a fail :)
15:05imirkin_: but! i remember there were others that weren't
15:05joi: I can't find single suld instruction in these traces
15:06imirkin_: constructing one right now :p
15:07imirkin_: ok, imagine a hypothetical "20011c05 d4004000" instruction
15:08imirkin_: compare envydis output with and without -V gf100
15:09joi: oh, I believe you
15:10imirkin_: but when i *do* teach envydis about those ??? ops, they'll be gf100-only
15:10imirkin_: since on gk104 it's all bindless
15:11joi: I just wanted to see the real trace where it matters
15:11imirkin_: joi: http://hastebin.com/raw/pijepadalo
15:12imirkin_: anyways... surprised it's none of those traces
15:12imirkin_: i would have expected one of the image ones to trigger it
15:12imirkin_: but i haven't fully worked out what all those opcodes mean yet... calim would know though
15:13imirkin_: probably reasonably documented in PTX as well
15:41pmoreau: So, PTIMER, PGRAPH, PFIFO, PCLOCK are not affected by the PCI-reset. PFB only a few counter regs, but resetting them manually changes nothing.
15:41pmoreau: PDISPLAY has some differences, but most of them aren't touched by the blob, and those who are, when changed manually has no effect.
15:44pmoreau:scrolls through nv_mmio.xml
15:44pmoreau: Which other engine could I check for...
16:59imirkin: skeggsb: uhm.... why does it BIND_TIC(2) twice in a row? http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nv50_exa.c#n881
17:00skeggsb: umm, *shrug* ?
17:05imirkin: decoding all the programs to see wtf they do
17:05imirkin: emacs rectangle-kill is awesome btw
17:34imirkin: in case anyone is interested, i pushed a xf86-video-nouveau repo to my github account which has gm107 exa (minus blits) and a fix for xv and >2048 video sizes.