00:01karolherbst: allthough I could simply wait a little :/
00:01karolherbst: still messy
00:05karolherbst: okay, fermi, done
00:14karolherbst: uff, can anybody check if the blob on tesla reduces the lnk cap speed after reducing the lnkSta speed?
00:50karolherbst: tesla done :)
00:50karolherbst: who wants to test some pcie speed changes?
00:50karolherbst: (tesla is completly untested by me though)
04:33darlac: fermi lspci --vv nouveau http://pastebin.com/K2S9eAG0, nvidia http://pastebin.com/1hYqFVPV
04:49karolherbst: darlac: nvidia is on lowest perf mode, right?
04:49karolherbst: darlac: you could test my pcie_speed branch here: https://github.com/karolherbst/nouveau/tree/pcie_speed
04:50karolherbst: though it will only enable pcie v2 for fermi yet, because recklocking is completly disabled for fermi
04:51karolherbst: it should work for tesla, kepler und maxwell though
04:56darlac: karolherbst: probably lowest perf mode. I have to check again
05:04darlac: karolherbst: it was lowest perf
05:21darlac: karolherbst: Do you need some test on tesla blob?
05:26karolherbst: don't think so, I pretty much figured everything out already
08:29karolherbst: how should I handle differences in the pcie setup when the gpu was powered off and anything changes?
08:45imirkin: karolherbst: don't do anything in ctor. only do stuff in init.
08:52karolherbst: imirkin: I know
08:52karolherbst: but what should I do if the card stays in 0f pstate, but pcie speed dropped to 2.5 between suspend or whatever
08:52imirkin: handle it in init
08:53imirkin: where on init it will clock to the proper value
08:53imirkin: where proper value is 2.5 or whatever the last thing was
08:54imirkin: or leave it alone if it hasn't been set, or set it to the thing it was set to last
10:14imirkin_: joi: i have an updated version of that patch for witcher2 which should hopefully avoid the issues it had earlier... my master tree, if you get a chance to test it out
10:14imirkin_: er, master branch of my mesa tree
10:25joi: imirkin_: great, I'll test it in 30mins
10:29imirkin_: cool, let me know how it goes
10:52karolherbst: imirkin_: I see, I still have to check what the cards are doing on suspend/dynoff
10:53imirkin_: karolherbst: not really... just set it to the thing you want in init and you're good to go.
10:53imirkin_: init gets called on resume
10:54karolherbst: yeah but usually I want to have the speed of the current set pstate
10:54karolherbst: or at least this would kind of makes sense
10:54imirkin_: in the pci subdev
10:54imirkin_: save off any requested pci speed settings
10:54imirkin_: and then if they're set to something when init is called
10:55imirkin_: then just perform the setting there
10:55karolherbst: does every subdev behave that way?
10:55karolherbst: or should they behave that way
10:55imirkin_: afaik yes
10:55imirkin_: obviously anything ben says overrides my comments since he actually knows how it works
10:55karolherbst: so I would add a priv field to the nvkm_pci struct like "last_speed" and I would check if this is set in init
10:55imirkin_: whereas i just remember how i thought it worked last time i looked at it, which was quite a while ago
10:56karolherbst: makes sense
10:59karolherbst: funny though nouveau parses 8.0 pcie speed for my fermi here at 0f
11:01karolherbst: imirkin_: how do I add private fields in "kernel C"? pointer to struct _priv field in nvkm_pci?
11:02imirkin_: look at hwo all the toher subdevs do it
11:02karolherbst: seems like they just use public fields (at least pci does)
11:02imirkin_: i believe this has been changed in recent times
11:02imirkin_: that's why i said look at *other* subdevs :p
11:02karolherbst: okay, seems to be all public now though
11:03joi: imirkin_: last patch or both?
11:03imirkin_: joi: both
11:04imirkin_: the two patches fix unrelated classes of fail
11:04imirkin_: or rather, related classes, but totally separate causes
11:04karolherbst: C doesn*t know default values, right?
11:04karolherbst: for struct fields
11:05karolherbst: ohh should do that in new_
11:09karolherbst: okay done, who wants to try the patches out? :D
11:20karolherbst: if somebody want to leave some comments: https://github.com/karolherbst/nouveau/commits/pcie_speed I am still thinking about some design decisions I made, so it may be totally different in the end :)
11:22joi: imirkin_: what kind of issues the last patch fixes?
11:22imirkin_: joi: deleting a buffer while there are outstanding commands in the pushbuf that use it
11:22imirkin_: joi: or a texture
11:22joi: so, still page faults
11:23imirkin_: and/or unknown buffer on list
11:23joi: what about this one: "multiple instances of buffer 4 on validation list" ?
11:23imirkin_: that can't happen ;)
11:23imirkin_: however it could perhaps happen in such a scenario
11:23imirkin_: you throw some stuff on the pushbuf (i.e. hit pushbuf_validate)
11:23imirkin_: then delete the buffer
11:23imirkin_: then create a new one
11:23imirkin_: that gets the same handle
11:24imirkin_: and then validate again
11:24joi: I got it in 2nd try
11:24imirkin_: with my patches?
11:24imirkin_: well phooey
11:24imirkin_: lalalalalalala this is not happening
11:29joi: ugh, 6th try: fifo: PBDMA0: 00040000 [PBENTRY] ch 5 [007f856000 witcher2] subc 0 mthd 0000 data 00000000
11:29imirkin_: that... looks like a fun one.
11:29imirkin_: something pushed out a really bad pb entry?
11:29imirkin_: dunno how that can happen
11:32imirkin_: urgh, found another instance of this happening
11:32imirkin_: how did this code ever work??
11:33imirkin_: will have an updated patch soonish
11:36joi: 2 crashes in 10 tries, I'll wait for the patch
11:44Yoshimo: karolherbst: if one compiles your branch, what should one do to test?
11:49karolherbst: pstate changes
11:49karolherbst: and check if lspci -vv changes pcie speed for your card
11:49karolherbst: according to your vbios
11:50karolherbst: there are pcie speed entries for each pstate
11:50karolherbst: the lowest usually has 2.5
11:50karolherbst: and the highest 5.0 or 8.0
12:19imirkin_: joi: check my branch again, there's another patch
12:36joi: wtf, witcher2 seems to be loading faster
12:38joi: don't be so happy, it's because of Ilia's patches :P
12:38imirkin_: joi: hm, that's unexpected. i'm guessing unrelated.
12:38imirkin_: joi: perhaps due to change in phase of the moon :)
12:39RSpliet: it was quite red last night...
12:39imirkin_: the phase?
12:39RSpliet: the moon
12:39karolherbst: joi: I also own witcher 2, so why shouldn't I be happy :)
12:40karolherbst: I checked the moon like evry 30 minutes while doint the pcie stuff
12:40karolherbst: was quite nice
12:41karolherbst: RSpliet: did you have a tesla card booting in v1 mode and 5.0 supported board? would you like to test my pcie speed patches?
12:41karolherbst: I only tested them on kepler and fermi (latter with modified nouveau)
12:44joi: imirkin_: 10 tries, 0 errors!
12:46imirkin_: joi: fantastic... can i put your Tested-by on those patches?
12:47mupuf: RSpliet: it was so cloudy in helsinki that I just saw the red behind the clouds :s
12:47karolherbst: ohh nice
12:47karolherbst: I want to test the patch too then
12:47karolherbst: imirkin_: which one?
12:47joi: imirkin_: yes
12:48karolherbst: mupuf: :(
12:48karolherbst: mupuf: by the way, nouveau parses 8.0 pcie speed on my fermi for 0f pstate :/
12:48karolherbst: I am sure I just copied your switch state for the vbios though
12:49karolherbst: mupuf: https://github.com/karolherbst/nouveau/commit/21bb7672208a495f5000e97d7cd40f91abc8a449
12:50imirkin_: karolherbst: https://github.com/imirkin/mesa/commits/ -- the top 3 commits there
12:50karolherbst: imirkin_: thanks
12:54RSpliet: karolherbst: sorry, I have too much hay on my fork to pick that up too right now
12:54karolherbst: no problem
12:54RSpliet: I really want to get that one problem out of the way (GPIO) and push those patches to the ML asap
12:54RSpliet: as term is about to start
12:55karolherbst: mupuf: I got the info from here: https://github.com/karolherbst/envytools/blob/master/nvbios/nvbios.c#L1530-L1540
12:55karolherbst: I don't know, but I don't think fermi cards should advertise 8.0 speeds, should they?
12:56mupuf: karolherbst: how should I know? :D
12:56karolherbst: fermi cards don't have v3 support
12:56karolherbst: this was added to kepler
13:01karolherbst: will add vbios file to repo
13:02karolherbst: mupuf: you will have more fun with this vbios :D
13:02karolherbst: ohhhh all this fun
13:03karolherbst: empty voltage table + "-- Mode GPIO, Base voltage 837500 µV, voltage step -25000 µV, acceptable range [837500, 1087500] µV --"
13:03karolherbst: or is it commong for fermi that this table is messed up?
13:04RSpliet: karolherbst: use envytools for your convenience, don't assume they are correct
13:04karolherbst: uhhh other fermi vbios files also look kind of scary
13:04karolherbst: RSpliet: what do you mean by that?
13:04karolherbst: ohh you mean envytools to fetch the vbios
13:05RSpliet: or nvbios to display the data inside
13:05karolherbst: I use nvbios
13:05karolherbst: and vbios was read through debugfs
13:05RSpliet: yes, well, nvbios is not the holy grail or golden standard for VBIOS
13:05RSpliet: in fact, I know it's incorrect at generating timing values
13:06RSpliet: (which... requires peeking several values to do it correctly; I might as well remove the current support for it as it'll never be correct)
13:06RSpliet: it's a thing created to aid in reverse engineering, not a perfect decoder ;-)
13:06mupuf: RSpliet: yes, that could indeed be a bad idea
13:07RSpliet: mupuf: the generation of timing values serves no purpose right now, it can't be used to validate whatever nouveau and/or the blob generates
13:08RSpliet: the kernel code is already better at generating timings
13:08RSpliet: so not a very good reference either
13:08mupuf: RSpliet: sorry, meant it was not a bad idea
13:08RSpliet: ah ok
13:08imirkin_: common typo :)
13:08mupuf: imirkin_: I know, right? :D
13:08joi: imirkin_: I measured performance and the difference is not measurable
13:09RSpliet: if only "not" was a single keystroke
13:09mupuf: it was one brainfart away!
13:09imirkin_: joi: ok, that's expected. it seemed unlikely that my patches would alter any sort of performance behaviour
13:09RSpliet: like ¬
13:09imirkin_: but crazier things have happened of course
13:09RSpliet: anyway, coming back to the subject
13:10imirkin_: joi: but in all the runs, no more witcher2 errors?
13:10RSpliet: karolherbst: use -v as an option to nvbios to see the "raw data" in hex values
13:10RSpliet: and see if common sense delivers better parsing :-P
13:10karolherbst: the pstate table shows them anyway
13:11joi: imirkin_: yes, to test performance without your patches I had to reboot 3 times...
13:11karolherbst: okay, lets start witcher2
13:11imirkin_: alright. i'm goign to do a piglit run in case i missed some corner case and push + cc stable
13:11joi: because those read faults completely hang my system
13:11imirkin_: joi: btw, the duplicate buffer thing has gone away too?
13:12imirkin_: hopefully that fixes similar issues for people with chrome
13:12joi: indeed, awesome job
13:13karolherbst: joi: did the error occur for you at save loading time?
13:13imirkin_: i don't fully grasp why this wasn't totally broken all the time, but... meh. not going to waste brainpower on that.
13:13joi: karolherbst: yes
13:14karolherbst: imirkin_: by the way, with the current gog version of witcher 2 I don't get the artifacts
13:14imirkin_: karolherbst: cool
13:14karolherbst: lets check how nouveau performs while having my "blob" graphic settings
13:15karolherbst: it is playable
13:15karolherbst: could be better though
13:16karolherbst: joi: I use high spec without ssao and motion blur
13:16karolherbst: was kind of playable
13:16karolherbst: what did you use?
13:17karolherbst: or didn't you care beause of the hang :)
13:17karolherbst: imirkin_: 12-16 fps on this settings
13:17joi: lowest settings, 800x600, 5 fps in that save
13:18joi: that's on boot clocks
13:18karolherbst: but my mobile chip is a monster, so
13:18karolherbst: still, 5 fps is a bit low :)
13:18imirkin_: esp for 800x600
13:18RSpliet: joi: is that a Fermi? what card do you have again?
13:18imirkin_: you were doing 1920x1080 i assume?
13:19karolherbst: on 0f though
13:19karolherbst: ohh no, it crashed :O
13:19karolherbst: segfault in libdrm_nouveau
13:19joi: on 0f pstate it's 13 fps
13:19imirkin_: joi: you have a gk107 though?
13:20joi: RSpliet: gk107m, GeForce GT 650M
13:20karolherbst: joi: ohh that's eomthing
13:20RSpliet: joi: ah right, okay, never mind then :-D
13:20imirkin_: joi: gk107 is a lot weaker than gk106, which is what karolherbst has
13:20karolherbst: mine has also gddr5
13:20joi: that's with karol's patches, btw
13:21karolherbst: wait, the game doesn't care much about mem speed :O
13:21karolherbst: 10-13 fps at 0a
13:21imirkin_: well, from the sounds of it, it may be doing some slightly multithreaded stuff
13:22imirkin_: i don't think nouveau takes advantage of that very well
13:22imirkin_: i'm guessing cpu utilization is fairly high?
13:22karolherbst: it is eon
13:22karolherbst: what do you expect :D
13:23joi: in tutorial it's 13 fps on 07 and 34 fps on 0f
13:23karolherbst: joi: on low?
13:23joi: yes, but let me check that
13:23karolherbst: imirkin_: actually
13:23karolherbst: no high cpu load
13:23karolherbst: around 50%
13:24karolherbst: I think it is gpu core bottlenecked
13:24karolherbst: okay, after 5 starts only on crash inside libdrm, but nothing fatal
13:24joi: yes, on lowest settings
13:24karolherbst: will do one try, then you can add also a tested-by from me imirkin_
13:24karolherbst: if you want
13:25karolherbst: joi: do you have a 0a pstate?
13:25joi: karolherbst: yes
13:25karolherbst: if the core clock doesn't change do you want to test if that changes perf?
13:25karolherbst: imirkin_: awesome work, seems ot work splendid :9
13:26joi: do *I* want?
13:28karolherbst: joi: don't know, I ask you
13:28karolherbst: I just got the feeling that witcher 2 is gpu bottlenecked
13:28karolherbst: would be nice to have this verified
13:28karolherbst: cpu load was at 50% for me
13:28karolherbst: and 0f only brought like 20% perf
13:29joi: 0a gives me 27 fps in tutorial
13:29karolherbst: so no real change
13:29karolherbst: let's say no big change
13:30karolherbst: I usually get like 50% speedups with 0f
13:30karolherbst: compared to 0a
13:30karolherbst: joi: https://gist.github.com/karolherbst/7b4e565970fa34b23e8c
13:30karolherbst: 0f+ is with pcie speed change
13:31karolherbst: yeah, adding witcher 2 maxed out :D fun
13:31joi: nice numbers
13:32karolherbst: the bioshock one is pretty impressive
13:32karolherbst: not that 17 fps is _that_ much, but at maxed out settings @ fullhd?
13:33karolherbst: actually nouveau refused to load witcher 2 at high and above entirely
13:35joi: at 1600x900 and lowest settings: 07/0a/0f - 5/10/13 fps
13:35karolherbst: the game needs a lot of time to load at ultra
13:36karolherbst: 1 fps at 07 :D
13:38pmoreau: What about Witcher 3? O:-)
13:38karolherbst: added witcher 2 data: https://gist.github.com/karolherbst/7b4e565970fa34b23e8c
13:38joi: bleh, at ultra settings I got oops around reservation stuff
13:40karolherbst: witcher 2 isn't the best optimized game anyway
13:40karolherbst: some say it is better to play it with wine
13:42karolherbst: okay, never try witcher 2 at somethig higher than medium
13:42karolherbst: this is just awefull
13:42joi: heh, 1600x900+ultra+0f gives me 3 fps
13:43imirkin_: joi: does your core clock get increased at 0f? for some people it doesn't due to voltage change fail
13:43imirkin_: joi: look at the 'AC' line
13:43joi: looks like it is increased
13:44imirkin_: moral of the story: don't use 'ultra' mode
13:44imirkin_: yea that looks fine
13:44karolherbst: something is just odd with that game
13:44karolherbst: 17 fps at 0f on low
13:44karolherbst: 14 fps at high
13:45karolherbst: joi: this is like mine
13:45karolherbst: joi: https://gist.github.com/karolherbst/7b0bc3e9b34d3f4a642c
13:45karolherbst: close enough
13:45imirkin_: karolherbst: you just have like 4x the TPC/MP/whatever
13:46karolherbst: not only x4
13:46imirkin_: 3x the TPC's
13:46imirkin_: 3x the GPC's
13:47karolherbst: ohh actually
13:47karolherbst: he as 2 SMX, I have 5
13:47karolherbst: but my card is somehow a bit "stock" overcklocked
13:47karolherbst: don't know why
13:48karolherbst: either way, the game sucks at perf
13:48imirkin_: or nouveau sucks at perf :)
13:48karolherbst: the game sucks
13:48karolherbst: even at blob I get problems
13:48imirkin_: s/at perf//
13:48karolherbst: this game is just poorly "ported"
13:49karolherbst: my laptop could also fit the 780M card ... was htinking of trying to get one
13:50imirkin_: i saw some talk about a 980 laptop editing
13:51karolherbst: ohh I think a 880M is also possible though
13:51karolherbst: but the 880M seems like a 780M with higher clocks
13:52karolherbst: this 980 laptop
13:53karolherbst: my laptop can still be used outside of home, but the other ones....
13:54karolherbst: joi: please test this if you want to get more perf: https://github.com/karolherbst/nouveau/commits/pcie_speed
13:55karolherbst: joi: DRI_PRIME benefits pretty much from this
13:55karolherbst: usually +10% for nearly everything
13:57joi: karolherbst: something changed in those patches recently?
13:57karolherbst: a lot
13:57karolherbst: like it is done for tesla+
13:58karolherbst: kepler is also more clean now
13:58joi: the patches I have applied are from 30 Aug
13:58karolherbst: they are old
13:58karolherbst: I improved error handling, messages and like everything
13:58karolherbst: found some new nice regs
13:58joi: ok, I'll test it, but not today
13:58karolherbst: no problem
13:59karolherbst: if you already use pcie patches and get max pcie speed, that nothing should change
13:59karolherbst: the new patches just add support for tesla, fermi and improved error handling/messages/Warnings, stuff
13:59joi: yup, pcie speed changes with pstates
14:00karolherbst: imirkin_: did you saw the 0x88088 reg once?
14:00karolherbst: this is a really nice one
14:00karolherbst: 0x30000 of the reg shows the actual hardware state of the pcie link
14:00joi: I wish someone would look into why DRI_PRIME is so broken...
14:01karolherbst: even if the config/requested speed is already set to 5.0 without being commited
14:01karolherbst: 0x88088 will still show the current speed
14:01karolherbst: joi: what do you mean by "broken"?
14:01karolherbst: nothing broken here
14:02joi: black window until I changes window size/switch current window million times/etc
14:02karolherbst: did you try to enable vsync on both sides?
14:02karolherbst: in games, window manager and intel ddx?
14:02karolherbst: allthough the window manager should take care of intel ddx
14:03karolherbst: enabling vsync in games and for the deskop let wonders happen
14:03karolherbst: I never set this
14:03karolherbst: on kwin I use either full scene repaints or reuse screen content for tearing prevention
14:04karolherbst: but I also use DRI3 offloading
14:06joi: heh, fifo: PBDMA0: 00040000 [PBENTRY] ch 5 [007f856000 witcher2] subc 0 mthd 1228 data 00000320
14:06joi: and: gr: DATA_ERROR 0000000c [INVALID_BITFIELD] ch 5 [007f856000 witcher2] subc 0 class a097 mthd 1230 data 20050004
14:08karolherbst: joi: what did you do :O
14:09joi: but it didn't do anything useful
14:14joi: heh, the variable name is vblank_mode, but it still does not work
14:17imirkin_: 1228 = ZETA_HORIZ
14:17imirkin_: 1230 = ZETA_ARRAY_MODE
14:17imirkin_: that ZETA_ARRAY_MDOE seems totally bogus
14:18imirkin_: and is more likely some sort of cross-context sync problem
14:18imirkin_: either that or they managed to create a depth array texture with 2G elements
14:18imirkin_: the former seems more likely ;)
14:19imirkin_: 0x320 = 800
14:19imirkin_: which seems perfectly legit for ZETA_HORIZ
14:19imirkin_: probably the PBDMA thing desync'd the fifo
14:19imirkin_: and then the later stuff was just mega-fail
14:20imirkin_: no idea what it means though... skeggsb_ -- ideas on what that PBENTRY error means?
14:21karolherbst: joi: you need to use vblank_mode=2
14:22joi: karolherbst: still 2,5k fps in glxgears
14:22karolherbst: I get only 60 with 2
14:23karolherbst: maybe your vsync setup is totally messed up
14:23karolherbst: joi: something in xorg.conf?
14:23karolherbst: joi: and what window manager do you use?
14:24karolherbst: I don't know how well vsync works under DRI2, but from what I heard, it shall be much better under DRI3?
14:24karolherbst: there should be some vsync stuff for it
14:24karolherbst: running glxgears without any vblank_mode should give you only 60
14:24karolherbst: if not
14:24karolherbst: something is messed up
14:26karolherbst: joi: your xorg log please
14:26joi: I have 60 fps with intel
14:27joi: it's nouveau that's not behaving
14:27karolherbst: DRI_PRIME=1 glxgears gives me 60 as well
14:27karolherbst: but as I said: I use dri3 already
14:27karolherbst: you most likely not
14:28imirkin_: joi: afaik with dri2 there's no vsync with prime
14:28karolherbst: because distributions disable it because _some_ cards didn't play well with it
14:28imirkin_: joi: with dri3 there is
14:28imirkin_: not 100% sure
14:28imirkin_: prime is definitely a weak point for me
14:28karolherbst: imirkin_: dri3 has present
14:28karolherbst: this makes _the_ difference
14:28karolherbst: joi: yeah, no dri3
14:29joi: I heard dri3 is broken in different ways, and it was disabled in intel ddx
14:29imirkin_: it is :)
14:29imirkin_: good times right?
14:29karolherbst: dri3 is broken?
14:29karolherbst: not for me
14:29imirkin_: basically nothing works
14:29karolherbst: and not for people I told to enable dri3
14:29imirkin_: but everything semi-works
14:29joi: (for quite some time dri3 crashed my xserver)
14:29karolherbst: imirkin_: what is broken in dri3?
14:29imirkin_: karolherbst: the code.
14:30karolherbst: and despite that?
14:30imirkin_: joi: i've been using dri3 on both of my desktops of late, and maybe Xorg 1.17 has fixed a lot of issues
14:30imirkin_: makes testing on secondary gpu's a LOT easier :)
14:30karolherbst: DRI3 is the way to go if you want usefull PRIME offloading anyway
14:30imirkin_: and i don't do any of the crazy thinsg that tend to cause issues
14:31imirkin_: (like, say, KDE)
14:32joi: so how do I enable dri3?
14:32joi: i'm using xserver 1.17.1
14:32imirkin_: joi: --enable-dri3 in the ddx
14:32imirkin_: joi: (the intel ddx)
14:33karolherbst: imirkin_: wut, never had problems with plasma5 and dri3
14:33joi: so it's still disabled?
14:33karolherbst: you can enable it in xorg.conf though
14:33karolherbst: this is the config I usually give to others for the _less_pain_feeling_ https://gist.github.com/karolherbst/f6918733d3456133d433
14:37karolherbst: imirkin_: I really don't understand the problems with DRI3, DRI2 was most of the time worse than DRI3 for me
14:37karolherbst: I mean ofcourse early integration was messy, but now it should be mostly fine?
14:39imirkin_: karolherbst: well, right now it's very easy to get stale stuff
14:39karolherbst: this might explains my kwin problems I had
14:40karolherbst: sometimes it just stopped to update window content
14:43joi: now, that's better
14:44joi: but... witcher2 reproduced new errors
14:44karolherbst: joi: so you managed to enable dri3?
14:44imirkin_: which errors are the new errors?
14:45joi: karolherbst: yes
14:45joi: imirkin_: http://paste.ubuntu.com/12605769/
14:45karolherbst: joi: nice :)
14:45karolherbst: welcome to the unloadable nouveau driver now :)
14:45imirkin_: joi: my guess is that the PBENTRY errors desync the command stream
14:45karolherbst: joi: sometimes the X server claims the added device though :/
14:46karolherbst: airlied: any update on https://bugs.freedesktop.org/show_bug.cgi?id=91388 ? your patch seems to work quite nicely
14:46karolherbst: I also notice the X server crash on another machine, where I loaded nouveau after starting X
14:47imirkin_: joi: i'm afraid that'll need skeggsb_'s input, as i haven't the faintest idea what it means
14:49mupuf: yes, the state of dri2 and dri3 is appauling
14:50imirkin_: they both kinda-sorta work, and everyone really hates touching them
14:51imirkin_: mwk: http://shaky.github.bushong.net/
14:52karolherbst: mupuf: do you want to put some v1 booting tesla cards into reator?
14:52mupuf: karolherbst: Tell me what you want and I shall do it
14:53mupuf: imirkin_: right. I have been stupid-enough to volunteer on this front.
14:53imirkin_: yes, that *is* quite silly
14:53imirkin_: but basically the fact that anything shows up on the screen is purely coincidental
14:54mupuf: that is X in a nutshell :D
14:54imirkin_: nah, all the X stuff works
14:54imirkin_: and DRI2 basically works (as designed)
14:54imirkin_: but DRI3 is purely coincidental
14:54mupuf: it is full of race conditions
14:54imirkin_: it has no cross-sync capabilities that i'm aware of
14:54mupuf: Cross device?
14:54mupuf: if so, then I understand what you mean
14:55imirkin_: or rather, cross-surface-user
14:55imirkin_: since you can end up using it as a pixmap
14:55imirkin_: and the X server might draw to it as well
14:55imirkin_: which at least for nouveau it does by queuing commands
14:55imirkin_: but the remote process, when reading that surface, has no way to tell those commands to flush out
14:56imirkin_: when it's all in-process, you know that there are pending commands
14:56imirkin_: but not when it's a dma-buf away
14:56karolherbst: mupuf: you should have a nv86 gpu which boots at v1,
14:56mupuf: hakzsam: tell me when you are done with reator
14:56imirkin_: karolherbst: afaik v2 is nv92+
14:56hakzsam: mupuf, sure
14:57karolherbst: imirkin_: g84+
14:57karolherbst: everything except nv50 basically, which isn't integrated
14:58karolherbst: but there are v1 g86 and v2 g86
14:58mupuf: imirkin_: apparently, one can share futexes
14:58mupuf: but it may never have been implemented
14:58karolherbst: and even if I get a v1 only card
14:58karolherbst: my code should not mess up those :)
15:00mupuf: i see, it seems to never have landed
15:00mupuf: oh dear
15:00imirkin_: mupuf: you mean in general on linux?
15:00mupuf: imirkin_: no, I meant in the original proposal for dri3
15:01imirkin_: well i'm not aware of that happening in any way
15:01imirkin_: i think ajax mentioned there's some sort of GLXDrawable->sync callback that isn't implemented
15:01imirkin_: (but could be)
15:03mupuf: well, I guess fun will be had
15:03mupuf: still working on ezbench for the coming weeks
15:04imirkin_: but you should obviously ask him for specifics... my understanding of all this is basically nonexistent
15:04imirkin_: i was just looking for reasons why drawing could be stale
15:04imirkin_: didn't actually diagnose the issue
15:05imirkin_: but it seemed like a potential source of fail
15:05imirkin_: perhaps the answer is "don't do that"
15:06mupuf: there is also the problem of the extra frame of latency
15:06mupuf: which is a major bummer
15:06imirkin_: i have no idea how any of these APIs are used in the first place
15:06imirkin_: so perhaps it's a purely theoretical class of issue
15:07mupuf: In Mesa, the DRI3 implementation uses a chunk of shared memory to hold a fence object that lets Mesa know when buffers are idle without using the X connection. That shared memory segment is allocated by creating a temporary file using the O_TMPFILE flag:
15:07mupuf: fd = open("/dev/shm", O_TMPFILE|O_RDWR|O_CLOEXEC|O_EXCL, 0666);
15:08imirkin_: mupuf: where's this code in X?
15:09mupuf: no idea, I was just readingeverything keith has on http://keithp.com/blog/
15:09imirkin_: heh ok
15:09mupuf: the relevant blog post: http://keithp.com/blogs/chromium-dri3/
15:09imirkin_: i was reading actual code :)
15:10airlied: libxshmfence does that stuff I think
15:11mupuf: airlied: thanks, I was wondering how mesa could know when to release the buffer (or re-use it for a later frame)
15:11imirkin_: airlied: i meant the bit about making sure that things were sync'd up
15:12mupuf: imirkin_: as in, flushed?
15:12imirkin_: basically let's say you have a pixmap
15:12imirkin_: and create a texture from pixmap
15:12imirkin_: and read the texture
15:12imirkin_: how do you know that X has flushed all its work drawing to the pixmap
15:13mupuf: aren't you supposed to render to a buffer, wait for completion, send the buffer via dma-buf to X which will create an x pixmap?
15:13mupuf: oh, right, for cases involving the ddx
15:14airlied: probably should send a mail to xorg-devel and get keithp and ajax to discuss :)
15:14airlied: I think most of the bugs in dri3 are in present
15:14imirkin_: for all i know that case is well-handled
15:14imirkin_: but i couldn't see how when i was reading the code
15:14imirkin_: and ajax seemed to agree that it was broken
15:14imirkin_: but he was using lots of words that i didn't know
15:17hakzsam: mupuf, I'm done for now, but I need to understand what is going on with that GF114 and those MP counters!
15:17hakzsam: but please, keep that GF114 for tomorrow :)
15:17mupuf: ok, I will keep the GF114
15:19mupuf: karolherbst: have fun
15:33karolherbst: mupuf: thanks but for today I am sadly to tired, will check the card tomorrow then. Thanks
16:48RSpliet: reasoning about NV50 GPIO...
16:49imirkin_: is unreasonable
16:49imirkin_: remember that nv94 (or nv92?) gained some gpio differences
16:49imirkin_: i think nv94, coz nv92 is the one that'd make sense
16:49imirkin_: [and i remember it didn't make sense]
16:51RSpliet: The VBIOS states that the value of MEM_FBVDDQ should be negated. If the bit for FBVDDQ is high in the timing table, it should be in "low voltage mode" meaning the GPIO value, corresponding with a high GPIO signal, as returned by _sense() must be low
16:51RSpliet: I... have a headache just trying to construct that sentence
16:52imirkin_: gotta love not gates!
16:53RSpliet: I can't even properly work out whether I should request my hwsq GPIO routine to request the value corresponding with the VBIOS bit or the inversion of it
16:53RSpliet: based on a trace observation of the GPIO reg
16:55imirkin_: skeggsb_: ping
16:56skeggsb_: imirkin_: hey
16:56imirkin_: skeggsb_: two questions...
16:56imirkin_: skeggsb_: first, not sure if you saw my comments re bo's getting deleted "too early"
16:57imirkin_: skeggsb_: but what do you think about a debug-only check in libdrm to make sure that a bo getting deleted for real isn't on any pushbuf buffer list?
16:57skeggsb_: sounds reasonable
16:58imirkin_: skeggsb_: separately, any idea about those PBENTRY errors joi was seeing?
16:58imirkin_: i.e. what do they mean, what might cause them?
16:58imirkin_: <joi> heh, fifo: PBDMA0: 00040000 [PBENTRY] ch 5 [007f856000 witcher2] subc 0 mthd 1228 data 00000320
16:59skeggsb_: hrm, no. the gk20a nvgpu driver might perhaps have more details if you're lucky though
16:59imirkin_: what is the *class* of issues though? i have no idea bout any of this pbdma stuff...
17:00imirkin_: like i don't even know what pbdma is :)
17:00imirkin_: something pushbuf related based on the name
17:00skeggsb_: yeah, the dma pushbuf fetcher logic i believe
17:00skeggsb_: on fermi it got split out of PFIFO proper, so they could have more than one of them
17:00imirkin_: and presumably this is an error grabbing the next pushbuf in the ib list?
17:01imirkin_: or something along those lines?
17:01skeggsb_: you'd get a GPENTRY for that i'd expect
17:01imirkin_: oh, what was that subfifo stuff
17:01skeggsb_: this would (maybe? i'm really only guessing here) be something wrong in the packet header in the pushbuf
17:01imirkin_: or spoon/whatever
17:01skeggsb_: that's a PBDMA
17:01imirkin_: hm ok
17:01imirkin_: it *is* odd that the subchan is 0
17:02imirkin_: i thought 3d was on some other subchan
17:02imirkin_: oh wait, probably not on kepler
17:02imirkin_: #define SUBC_3D(m) 0, (m)
17:02imirkin_: not anywhere
17:02imirkin_: the method is fine, the data is reasonable...
17:03skeggsb_: there's perhaps other bits getting set somewhere that we don't decode into the log ? i dunno
17:03skeggsb_: gnurou: any more info on what a PBENTRY error is? ;)
17:03imirkin_: skeggsb_: ok fair enough. so for now it's pretty much a "i have no clue what triggers this" situation?
17:04imirkin_: and the name just came from nvgpu or whatever
17:04skeggsb_: basically, yeah, like most of the errors we decode :/
17:04imirkin_: but it could just as well be a PBGOAWAY error
17:04imirkin_: ok =/
17:05RSpliet: pmoreau: if you're still awake, I just pushed NV50 GPIO changes that should now (finally) correctly touch the voltage bits
17:06gnurou: PBENTRY sounds like an issue with a GPFIFO entry... but I would need to check further
17:07gnurou: ... or a pushbuffer's content maybe? we would probably use GPENTRY if it was the former...
17:07paneidos: hi, can anyone help me with a nouveau issue on a NV11M (GeForce 2 Go) card?
17:07imirkin_: paneidos: what sort of issue?
17:08imirkin_: paneidos: transparency fail with icon/text in new-fangled gui's?
17:08paneidos: imirkin_: I wish, can't even get a proper framebuffer
17:08paneidos: error is "Pointer to LVDS manufacturer table invalid"
17:08imirkin_: well, i fixed those a while ago
17:08imirkin_: that error is fine
17:09imirkin_: paneidos: did it ever work?
17:09imirkin_: i.e. is this a regression
17:09paneidos: imirkin_: nope, fresh install
17:09imirkin_: what kernel?
17:10imirkin_: and what distro?
17:10imirkin_: what login manager is being used?
17:10paneidos: imirkin_: 4.0.5, gentoo, no login manager yet, this is before init even
17:11imirkin_: ok cool
17:11paneidos: imirkin_: dmesg: http://dpaste.com/0DDEBXB
17:11imirkin_: [drm] Cannot find any crtc or sizes - going 1024x768
17:11imirkin_: that's unfortunate
17:11imirkin_: well, to get things going, you can boot with nouveau.modeset=0
17:12imirkin_: that should disable nouveau entirely
17:12skeggsb_: hrm, that's unfortunate.. being an NV11M this'd be a laptop, with LVDS.. and we're ignoring the DCB table because it's of an (allegedly) useless version
17:12skeggsb_: so.. we won't detect your panel
17:13paneidos: skeggsb_: it is indeed a laptop, Dell inspiron 8100
17:13skeggsb_: the "no useful data" for that version of dcb was inherited from way back before we ever had kms, which was written by someone else, i'm not sure what the reasoning for choosing to ignore dcb there was either
17:14imirkin_: paneidos: if you can log into the laptop while nouveau is loaded
17:14imirkin_: paneidos: please grab /sys/kernel/debug/dri/0/vbios.rom
17:14imirkin_: and put it up somewhere
17:14imirkin_: paneidos: on the bright side you should be able to use your tv out ;)
17:14paneidos: imirkin_: I thought you might need that
17:15skeggsb_: imirkin_: hah!
17:15skeggsb_: that's not a very bright side, more of a "slightly less dim" side
17:15imirkin_: if you can find a composite/s-video cable and screen to plug it into
17:15paneidos: imirkin_: https://dl.dropboxusercontent.com/u/20229385/vbios.rom
17:16imirkin_: skeggsb_: decoded http://hastebin.com/vebulopiko.vala
17:16skeggsb_: i'm looking at it already :P
17:16imirkin_: DCB 0: type 0 [ANALOG] I2C 0 heads 0 conntag 0 LOCAL OR 0 maxfreq 350000kHz
17:16imirkin_: is that expected for a lvds screen?
17:16imirkin_: (or might it actually be *gasp* lvds?)
17:16skeggsb_: right, so, matches the comment in nouveau about why it's useless
17:17skeggsb_: * v1.4 (some NV15/16, NV11+) seems the same as v1.5, but
17:17skeggsb_: * always has the same single (crt) entry, even when tv-out
17:17skeggsb_: * present, so the conclusion is this version cannot really
17:17skeggsb_: * be used.
17:17skeggsb_: conclusion: we need to scare up some other way of detecting the panel
17:17imirkin_: as promised :)
17:18skeggsb_: hrm, nvbios doesn't decode BMP :(
17:19imirkin_: apparently not :)
17:19imirkin_: BIT or die!
17:19skeggsb_: in fairness, that's probably reasonable
18:27imirkin: skeggsb_: also did you have a moment to look into that G200 regression?
18:27imirkin: (with the fan)
18:28imirkin: on resume
18:28skeggsb_: it's on my list, i have to look at an issue on a customer's laptop first though
18:28imirkin: as long as it's on the list, all good ;)
18:45skeggsb_: i can probably multi-task that one actually.. working from an external drive involves lots of waiting :P
18:46imirkin: look into ssd's. i hear they're fast.
18:46skeggsb_: that'd require it becoming a problem often enough for me to care that much :P
18:47skeggsb_:plugs in that god-awful board
18:47imirkin: if i read news of a blackout across australia, i'll know why
18:54RSpliet: skeggsb_: you make it sound simple
18:54RSpliet: if I want to plug in my G200, I first have to remove my hard drive bay
18:54skeggsb_: i deliberately got a case with plenty of room when i built this test box
18:55RSpliet: just for the G200, clever
18:55imirkin: and the GTX 780
18:55skeggsb_: i have a few monster boards
18:55imirkin: and a Titan?
18:55RSpliet: NV50 is another one of those
18:55imirkin: and i can't imagine that GM204 being too small
18:55skeggsb_: the GM204 i have is in the same shell as a Titan
18:56imirkin: and doesn't work right? :)
18:56skeggsb_: it's got bad vram, so, aside from very trivial stuff, it's pretty useless
18:56skeggsb_: i use the GM206 for GM2xx stuff usually instead
18:57imirkin: didn't it work at one point or another?
18:57skeggsb_: nah, it's always been dodgy since i got it, artifacts even on the bios screen
18:57RSpliet: a GM204 with bad RAM... isn't that still in warranty? or is it bad as in "I brought a soldering iron close to it and now it smells like chicken" bad?
18:57imirkin: but on the bright side, there's a *lot* of it ;)
18:57skeggsb_: it's gotten worse though, or the binary driver changed enough to make it touch bad ram at an inopportune time
18:58skeggsb_: but, it used to load on it, and now doesn't
18:58skeggsb_: RSpliet: no warranty, nvidia shipped it to me ages back
18:59skeggsb_: imirkin: well, good news is, i can confirm the regression at least :P
19:00imirkin: skeggsb_: cool. the reporter bisected it to a monster change sadly
19:00imirkin: which was well beyond my ability to just read through
19:00skeggsb_: that was unavoidable unfortunately
19:01imirkin: perhaps. just explaining why i couldn't make any further sense of it :)
19:01imirkin: normally i'm pretty good at reading random code, but... this would have taken me the better part of a day, if not longer, to grok
19:10skeggsb_: imirkin: do you remember what bug number that was?
19:11skeggsb_: ah, got it
19:12skeggsb_: fix pushed
20:18skeggsb_: paneidos: can you file a bug report for your issue so it doesn't get completely lost?
21:54imirkin: skeggsb_: wow, that was fast
22:49skeggsb_: imirkin: there were limited things it could've been
22:49skeggsb_: resume indicated devinit opcodes, and i went from there
22:50imirkin: even if you told me the function that was wrong, it'd still take me forever to figure out wtf was going on there :)
22:52skeggsb_: well, i'd have the same problem inside mesa :P
22:52skeggsb_: i deal with the kernel code all the time, makes it somewhat easier
22:52imirkin: yeah, and having rewritten it all very recently couldn't have hurt either
22:53imirkin: btw, i'm fairly sure that bo early deletion issue was the cause of the multiple instances of handle on buffer list problems
22:53imirkin: it makes sense -- create a bo, validate, delete bo, create bo, get same handle but diff bo, validate again
22:55imirkin: i pushed some mesa changes that hopefully plugs those holes
22:55skeggsb_: i'm hoping that those fixes you did solve the chrome issues i've been seeing lately
22:56imirkin: oh, other people reported chrome issues too
22:56imirkin: i could never repro
22:56skeggsb_: kernel rejecting with -22?
22:56imirkin: i'm sure it has something to do with using gnome-shell or something in conjunction with chrome
22:56imirkin: to help trigger the issues
22:56imirkin: (when in doubt, i blame gnome-shell)
22:56skeggsb_: did you ever look at making mesa do the right thing there btw?
22:56imirkin: yeah, i never get those errors
22:57imirkin: right thing wrt what?
22:57imirkin: i changed it to delay deleting until the fence was reached
22:57imirkin: and/or the pushbuf had been emitted (in which case the kernel's keeping a ref i assume)
22:57skeggsb_: wrt resubmitting state when the kernel rejects a pushbuf
22:57imirkin: oh. no.
22:57skeggsb_: that'll help stability a lot in such cases
22:58imirkin: yeah... i should hack up the pushbuf submit to fail with like 0.01% probability
22:58imirkin: run unigine and watch the fireworks :)
22:58skeggsb_: page faults galore i bet
22:58skeggsb_: i/nvidia need to push that kernel side of that work through too, to solve the hanging on fences issue
22:59imirkin: there's a big place i can whack, but the problem is that there are 50 other spots that need fixing too
23:00imirkin: i.e. nvc0_state_validate() is the big place
23:00skeggsb_: we will (in theory) be a lot more robust after those few changes
23:00skeggsb_: hmm, most other places are single-shot (ie. submit all relevant state already) aren't they?
23:00imirkin: mmmmm probably
23:00skeggsb_: i'm a bit out of date on mesa these days
23:00imirkin: you may be right
23:01imirkin: and even if not, it's probably 99% of the problem
23:01imirkin: i'll crank it up to 1% when the 0.01% starts working :)
23:01skeggsb_: will you try 99.9? ;)
23:01imirkin: this is when a separate dev box comes in *really* useful
23:01imirkin: dunno about 99.9
23:01imirkin: since each time it's a dropped draw
23:02imirkin: but maybe 50%?
23:02skeggsb_: oh, right
23:02imirkin: or 10%?
23:02imirkin: i guess it could retry
23:04imirkin: anyways, i'm going to stick a couple cards in trello about this since i keep forgetting
23:04imirkin: and working on more fun feature stuff
23:04imirkin: (until you spend hours on it and it does everything you think it should yet it still doesn't work)
23:05skeggsb_: i should probably review/merge the patches on the list before i be lazy for the evening ...
23:05skeggsb_: haha, yes, that's always annoying
23:05skeggsb_: until it finally works :)
23:05imirkin: probably something dumb going on
23:05imirkin: [as usual]
23:11imirkin: once i get ssbo hooked up in gallium, that should hopefully make debugging easier