00:06airlied: agd5f: drm/radeon: fix dp link rate selection (v2) I think it broke some stuff other than nutmge
00:06airlied: why does the code no longer test for is_dp12_connector?
00:07airlied: I'm narrowing down a bisect to that area, will investigate a bit further tomorrow
00:07airlied: or Friday actually
00:23airlied: agd5f: yeah it picks 2/540000 now instead of 4/540000 which breaks MST
00:24airlied: though it could be I'm feeding it the wrong thing, I should probably just have MST always pick max lanes/spped
01:38mupuf: karolherbst: nope, that is also where I got stuck
01:38mupuf: changing little things here and there got me up to more than 3 millions reclocks
01:38mupuf: but to be honest, 700k reclocks is stable enough for now!~
01:39karolherbst: especially if you do them within a few minutes
01:39karolherbst: RSpliet did some PLL locking for fermi+ which isn't in master yet
01:39karolherbst: maybe with it it gets a bit more stable
01:41karolherbst: mupuf: in fact I was also doing my cat current_load while reclocking, I wanted to stresstest PMU communication not reclocking ...
01:41karolherbst: so in fact it was like 350k downclocks, 350k upclocks + 700k PMU requests with reply
01:42karolherbst: mhh 700k * 7: PMU requests in total then?
01:42karolherbst: each reclock sends 4 requests I think?
01:42karolherbst: doesn't matter that much
01:43karolherbst: mupuf: wanna review those both patches for the PMU so we can get that upstreamed? https://github.com/karolherbst/nouveau/commits/pmu_fixes2
01:43karolherbst: I doubt they are _important_ now, but they will be if we use the PMU more
01:44mupuf: will do tonight
01:45karolherbst: but do you have any clue why reclocking + pmu + glxspheres64 might let the gpu disconnect from the bus?
01:54karolherbst: mupuf: by the way, we have now a gm108 vbios and trace :)
01:55karolherbst: ciupicri: intel gpus
01:56karolherbst: ciupicri: if not, the 210 might be not a good choice
01:57karolherbst: ciupicri: depends actually how much you want to spend, but I would go for a low end kepler/maxwell1
01:57karolherbst: ciupicri: otherwise if you want to do 4k video decoding or something in that area the older gpus might be too slow
02:09mupuf: karolherbst: it does not disconnect from the bus
02:10mupuf: the "fell from the bus" means that it stops answering PCIe requests
02:10karolherbst: ahh okay
02:10mupuf: or actually, maybe it is just PFIFO being busted
02:10karolherbst: therm: GPIO 16 unknown PWM: ffffffff
02:11mupuf: cool for the gm108!
02:11karolherbst: yep :)
02:11karolherbst: though I also got therm: GPIO 16 unknown PWM: 0007b07f
02:12karolherbst: mupuf: and if you find some time after the PMU stuff, could you check if that is fine with you? https://github.com/karolherbst/envytools/commit/e4586c7011f88cdb7541abe45379c3cafc3480b8
02:12karolherbst: I decoupled the generated voltage entries from the entries in the voltage table basically except when we parse the entries
02:16mupuf: karolherbst: please send your patches to the ML
02:16karolherbst: this is for envytools and the pmu one was already sent by me
02:17mupuf: ok! great!
02:17mupuf: so, tonight is review night
02:17mupuf: I also need to review changes for arduide
02:18karolherbst: well I think I resend the pmu ones because the last time was in november :D
02:18karolherbst: ohh I open a PR for the envytools one
02:19karolherbst: I already did this month..: https://lists.freedesktop.org/archives/nouveau/2016-March/024217.html
02:35karolherbst: hakzsam: how long will you need reator today?
02:38hakzsam: karolherbst, I will need to run piglit
02:39hakzsam: karolherbst, if you don't need it too long, please do now
02:39karolherbst: I have to do stuff before
06:56karolherbst: RSpliet: it works as I expected :)
06:56RSpliet: karolherbst: could you elaborate your definition of "it" please? :-)
06:57karolherbst: RSpliet: I took the vbios or mupufs kepler
06:57karolherbst: filled the entries with the generated voltages, because there were the useless garbage
06:57karolherbst: removed the 02 bit from the header and nvidia volted the card the same
06:57karolherbst: which means I am able to fill the entries and get nvidia to volt what I want
06:57karolherbst: gpios were parsed according to original vbios
06:58karolherbst: I could modify the GPIOs pins of an entry
06:58karolherbst: which nvidia took and volted the gpu differently for the same VID
06:58RSpliet: excellent news! :-)
06:58karolherbst: which means nvidia parsed the entry for 1.175V, but I put in the GPIO combination of 1.15V => got 1.15V
06:58karolherbst: I added the 02 bit in the header
06:58karolherbst: and then I got 1.175V again
06:58karolherbst: which means, nvidia generated the VID entries
06:59karolherbst: allthough I left the modded 1.175V entry in the table
07:02RSpliet: I'm about to give your updated tree a proper run
07:02karolherbst: nice thanks :)
07:03RSpliet: up to you whether you might want to send a few voltage-related fixes to the ML or rather wait for the whole boost work to be done first and do it in one go
07:04karolherbst: I want to do it in pieces actually
07:04karolherbst: but this can go as a small series
07:04karolherbst: because it actually fixes setting the expected voltage
07:04karolherbst: and currently nouveau sets a different voltage on those cards
07:05karolherbst: which is clearly a bug and not boost related ;)
07:05RSpliet: yep, if it passes the test you'll have my blessing
07:05karolherbst: but please check if the GPIOs are set accordingly
07:05karolherbst: there might be still an offset of 1 or 2
07:06RSpliet: oh yes, unfortunate that your gist paste disappeared, I don't recall the exact registers to double-check
07:06karolherbst: ohh yeah I tidied those up...
07:06RSpliet: I'll reproduce it from my VBIOS, no worries
07:07RSpliet: or you do it, excellent :-P
07:07karolherbst: I hacked the stuff into nvbios already
07:07karolherbst: nvidia volted to 1.087500V right?
07:07RSpliet: yeah, I need the GPIO mapping table too :-D
07:48karolherbst: ohh I could have looked into the 31st bit too...
07:53karolherbst: RSpliet: okay, that one is no enable bit
08:39karolherbst: yeah nice, nvidia segfaults when using GL_ARB_shading_language_include in a conformant way...
08:40RSpliet: everyone knows nouveau is more stable, amirite? :-P
08:40karolherbst: well mesa doesn't support it yet :p
08:40karolherbst: but it is a really painfull extension ...
08:41karolherbst: currently writing piglit tests for it
08:55mupuf: karolherbst: didn't know you were also interested in adding gl features
08:55karolherbst: mupuf: well I game I have an I really like needs this ...
08:55karolherbst: I already got it working, just need to do it the right way...
08:56mupuf: wow, that was an impressively good english you used :D
08:56karolherbst: what :D
08:56mupuf: well, this is exactly how calim wrote most of the gallium driver
08:56karolherbst: now I see
08:57mupuf: a fellow german speaker ... from austria
08:57RSpliet: ahhh, yes. Haven't heard of him for a while, how's he doing?
08:58karolherbst: mupuf: by the way, I checked the voltage table stuff and everything seems okay :)
08:58karolherbst: there is indeed a bit flag to see if we should parse the entries or generate from the header
08:59mupuf: ah, cool!
08:59karolherbst: I found one gpu which would work either way
09:00karolherbst: but each way would generate different voltages
09:00karolherbst: and nouveau does the wrong thing currently on it
09:00arizo: karolherbst: painkiller freezes in 5 mins if galium is enabled
09:00arizo: otherwise in longer time but still freezes
09:01karolherbst: arizo: context?
09:01karolherbst: ahh, oss and wine? or is this nouveau related?
09:02arizo: yes i have nouveau and gt730 shit card
09:03karolherbst: ahh the fermi one...
09:04karolherbst: does your entire destkop freezes?
09:04karolherbst: or just the games?
09:04arizo: almost entire X
09:04arizo: i press alt -tab but game picture remains
09:05arizo: then i press F1 to arouse terminal dropd-down and then i can ctrl + c to shut the game
09:05karolherbst: okay, but the display still gets updated
09:05arizo: if i just press alt-tab and select other apps game picture just remains
09:06karolherbst: arizo: then you shoudl check the application output and dmesg
09:06arizo: i can paste from the terminal
09:07karolherbst: yeah, just use a pasting site for this
09:09arizo: karolherbst: https://bpaste.net/show/f9243feeae73
09:10karolherbst: arizo: I guess it happens randomly?
09:10karolherbst: ohh yeah, the game just crashes
09:10karolherbst: well yeah, I find it painful to debug wine applications, you should check on winehq
09:11arizo: karolherbst: yes randomely
09:11arizo: especially after heavy battles
09:11mupuf: karolherbst: well, ... congrats for finding the bit :)
09:12karolherbst: though I think RSpliet actually pointed to that one
09:12karolherbst: but more in a "they could mean something" way :)
09:12arizo: bit for fermi?
09:12RSpliet: mupuf: I've been chasing karolherbst with a bunsenburner for two days, but he did the work :-P
09:12mupuf: we are getting close for voltage management
09:13mupuf: RSpliet: sounds fun! Smells like roasted chicken now?
09:13RSpliet: beats salmon
09:16karolherbst: by the way, what is tegra 124 and what is 210?
09:17karolherbst: ohh 210 is the maxwell one and the kepler one, good
09:18karolherbst: *124 the kepler one
09:18RSpliet: karolherbst: https://en.wikipedia.org/wiki/Tegra
09:23karolherbst: 0x130 reg
09:23karolherbst: but I doubt this means anything for nouveau
09:23karolherbst: but it maybe in the FUSE range indeed
09:26RSpliet: karolherbst: nouveau seems to have selected 1.1V now
09:26RSpliet: one step above NVIDIA
09:26RSpliet: but at least it's nice and functional
09:26karolherbst: very good
09:27karolherbst: and sensors also says 1.1V?
09:27RSpliet: yes sir
09:27karolherbst: good :)
09:28RSpliet: oh, and my little pll lock patch doesn't cause unexpected behaviour, so I'll send that out tonight too
09:28karolherbst: RSpliet: I will retest reclokcing with it then, maybe it is more stable
09:29RSpliet: well, it's not expected to be, but it'll warn you when the PLL value is unstable
09:29RSpliet: sounds like valuable debugging info
09:29karolherbst: I thought the pll can take some time until it produces the value we want
09:29mupuf: RSpliet: does nvidia poweroff the locking detection circuit after reclocking?
09:29mupuf: karolherbst: it does
09:29RSpliet: mupuf: yep
09:30mupuf: you need to wait for it to be locked before moving on
09:30karolherbst: then I would expect that this patch indeed increases reclocking stability
09:30mupuf: but RSpliet probably meant that after a few ms, it would continue anyway
09:30mupuf: but yeah, it should help
09:30RSpliet: nouveau did wait for the test to pass, but didn't take the effort to enable the test prior to waiting
09:30arizo: karolherbst: let's try to find bit for fermi?
09:31karolherbst: well when I reclock nearly thousend times a second, a few ms matter :)
09:31mupuf: RSpliet: so it just timed out?
09:31mupuf: or by chance, it was already at the right value?
09:31RSpliet: mupuf: in practice it was always enabled by default? idk, seems like it, but doesn't sound like you'd want to take the risk
09:31karolherbst: I got timeouts while messing with the PLL
09:31mupuf: I was only worried about the power usage
09:32RSpliet: it's probably not the most power-hungry piece of logic, but any picojoule counts right?
09:32karolherbst: arizo: that already affects fermi as well
09:32karolherbst: arizo: or, well a few fermis
09:32karolherbst: but it isn't that important
09:32arizo: what effects?
09:32mupuf: RSpliet: yop!
09:32arizo: tell me how to overclock it
09:32karolherbst: nouveau already does actually
09:33karolherbst: but more by accident
09:33mupuf: but i would expect it to be more power hungry
09:33RSpliet: arizo: currently changing the clock speeds of fermi GPUs is not supported
09:33mupuf: well, no idea how it is implemented
09:33arizo: that;s why i propose to find that bit to reclock
09:33karolherbst: mupuf: funny though, the same has to be done for 0x40 voltage tables ...
09:33karolherbst: but this is fermi, so I care less
09:33RSpliet: arizo: it's not "a bit", it's a mountain of work and I'm up to my elbows in it
09:33karolherbst: but most likely the same
09:34karolherbst: just maybe different bits
09:34karolherbst: but if we are good, we could get kepler/maxwell reclocking stable this year and maybe even fermi :)
09:35mupuf: karolherbst: that would be an amazing feat, yes!
09:36karolherbst: well jayhost` is testing reclocking on maxwell for a few days now
09:36karolherbst: and it looks really good
09:36karolherbst: he said he had his card on max clock for a few days without issues
09:36mupuf: oh, right, forgot to test on the GM750
09:37mupuf: what the heck
09:37mupuf: GTX 750
09:37karolherbst: somebody just need to find some time to figure out any differences
09:37mupuf: well, it will start with checking the clock tree :p
09:37mupuf: did you figure out the clocking issue RSpliet had?
09:37mupuf: or still has
09:38karolherbst: which clocking issues?
09:38karolherbst: it was the voltage to begin with
09:38karolherbst: you know nouveau parsed the VIDs wrong
09:38karolherbst: so low voltages were actually high and high ones actually low...
09:38karolherbst: or do you mean the wrong clock reading?
09:39mupuf: the HUB6 clock was wrong IIRC
09:40karolherbst: yeah that was my mistake
09:40karolherbst: the NvBoost config option messed the cstate creation up
09:40mupuf: when you do all the work, it is always your mistake :p
09:40karolherbst: he has no boost clock
09:40karolherbst: so base_clock = 0MHz
09:40karolherbst: and cstate with freq > base_clock => fail
09:41karolherbst: then he ended up with the pstate.base as his clocks and the domains aren't adjusted in that case
09:41karolherbst: or maybe even adjusted in a wrong way
09:41karolherbst: but somehow I really like the gpuboost of nvidia
09:42RSpliet: it grows on you, doesn't it?
09:42karolherbst: usually if you hear something like enabled pm by default and dynamic reclocking you expect more perf
09:42karolherbst: but on nvidia hardware with nouveau you won't get more perf
09:42ciupicri: karolherbst: regarding the Geforce 210: I don't care about 4K videos. As long as LibreOffice, web browsing and 1080p work fine, I'm all good. Though I'm a bit worried about future support i.e. if in 3 or 4 years the card won't be supported anymore.
09:42karolherbst: ciupicri: that's why I said you should rather get a kepler or maxwell1
09:43karolherbst: ohh wait
09:43karolherbst: video decoding ...
09:43karolherbst: we have VP5 right?
09:43RSpliet: karolherbst: kepler video decoding should be as good as gt21x?
09:43mupuf: for 4K, video decoding actually matters
09:43ciupicri: yes, not decoding. Heck, we don't even have 1080p monitors yet, just 1024x768 or something like that.
09:44karolherbst: RSpliet: nope, kepler has better one
09:44RSpliet: karolherbst: in terms of nouveau support I mean, silly
09:44karolherbst: yeah, still better :p
09:44mupuf: karolherbst: I added video tests to ezbench, to test the performance of the windowing system and compare the output modules
09:45karolherbst: mupuf: nice :)
09:45mupuf: and saying there are differences is an understatement
09:45karolherbst: did you check with 4kx4k videos?
09:46mupuf: nope, the biggest ones I have are 4k vids
09:46karolherbst: ohh by the way
09:46karolherbst: there is VP7
09:47karolherbst: with dedicated HEVC decoding
09:48karolherbst: VP6 needs a shader to decode HEVC
09:49karolherbst: ciupicri: well you are best off with a VP5 gpu with nouveau I would say
09:50ciupicri: what does that mean? From G610 on?
09:50karolherbst: late fermis and all keplers
09:50karolherbst: GF117 and GF119
09:50karolherbst: and all GKs
09:51ciupicri: ok, thank you
09:51karolherbst: but the only difference to VP4 is really 4k support, but having a more modern gpu is usually the better choice and kepler is in a good shape with nouveau
09:51karolherbst: so I would choose a kepler one
10:36karolherbst: RSpliet: most likely you won't be able to test just the VID fixes because everything else isn't in place, but maybe it still works: https://github.com/karolherbst/nouveau/commits/vid
10:36karolherbst: ohh I will send those out anyway now
11:01karolherbst: uhh I did something wrong
11:16rmu: hi there. I have a somewhat curious issue with a recently purchased ViewSonic 4k display connected via display port to a Thinkpad 410 with nvidia gt218m (nvs 3100m)
11:16rmu: every time the mouse pointer touches the left edge of the screen, the display becomes a block of solid color
11:17rmu: sleeping/resuming the laptop reactivates the screen
11:17rmu: option "HWcursor" "false" leads to black screen, not usable even without external display
11:17rmu: no messages in dmesg or x-log
11:18rmu: any ideas how to debug this?
11:18karolherbst: RSpliet: by the way, the 0x40 entries are looking more funny
11:18karolherbst: and the same on all cards
11:19karolherbst: 1 byte, 8 entries: 0x00, 0x11, 0x22, 0x33, 0x44, 0x58, 0x68, 0x78
11:21rmu: versions: X server 1.17.2, linux kernel 4.5.0, nouveau 1.0.12
11:22mupuf: rmu: wow, that's annoying
11:23mupuf: not sure if any nouveau dev has access to a 4K screen
11:23mupuf: red hat has, though!
11:23mupuf: airlied, skeggsb: have you tried nouveau with a 4K monitor?
11:40rmu: dual screens active, does not matter if external screen is on the left or on the right
12:22karolherbst: dammit nvidia. Only one implementing an extension on the deskopt and then they do it wrong...
12:23mupuf: karolherbst: or do they?
12:23mupuf: I pestered at nvidia a few times when writing tests
12:24mupuf: and a carreful reading + angry email from nvidia convinced me otherwise :D
12:24karolherbst: "An INVALID_VALUE error will be generated under any of the following conditions: Either <name> or <string> is NULL."
12:24karolherbst: this sounds pretty clear, doesn't it?
12:24mupuf: yep :D
12:24karolherbst: glNamedStringARB(SHADER_INCLUDE_ARB, strlen(name), name, 0, NULL); no INVALID_VALUE in glGetError()
12:24mupuf: nvidia is not really good at this game
12:25karolherbst: the last param is string
12:27karolherbst: but they check name == NULL
12:27karolherbst: and return INVALID_VALUE
12:27karolherbst: but if the lenght is != 0, it segfaults....
12:28hakzsam: fun :)
12:29karolherbst: so I should just bother them with this and get some angry response
12:38karolherbst: is the git stuff from freedesktop down?
12:40karolherbst: annonymous git is down
12:51karolherbst: mupuf: by the way I still can't access the wiki repository/edit page
12:52karolherbst: maybe I do something wrong though
12:52karolherbst: should I be able to use git or the edit page?
12:53mupuf: the edit page
12:54karolherbst: maybe I just typed in the wrong password
12:54karolherbst: how can I validate the htaccess hash locally?
12:56karolherbst: htpasswd -c
12:56karolherbst: "Password for user karolherbst correct."
13:01karolherbst: mupuf: what algorithm does fdo use?
13:02karolherbst: ohh md5
13:02karolherbst: then I have no idea
13:13mupuf: karolherbst: send an email to request an account
13:55karolherbst: mupuf: k thanks
13:55karolherbst: ohhh newest rumors :D
13:55karolherbst: nvidia working on own distribution for games, ...
13:56karolherbst: oh man, I should also just fake such screenshots :p
14:00Digit: + copy layer, darken about 50%, blur, set to dodge. :3
14:01karolherbst: I actually feel guilty for talking about this
14:05maxpas: " Late last year Microsoft published a specification on VP9 DXVA2 hardware acceleration. Shortly after, both Intel and NVIDIA started to support this in their hardware. This version of LAV Video enables using the hardware acceleration in the latest NVIDIA GPUs (GTX950/960), and recent Intel GPUs (Braswell and Skylake)"
14:05maxpas: GM206 can do full hardware decoding of VP9 video streams also
14:06karolherbst: maxpas: and?
14:07maxpas: waiting for Nvidia to enable HEVC Main10 10bit and VP9 hardware decoding on UNIX based OS
14:08maxpas: "Today, the driver doesn't support MAIN 10, although the hardware does (hence why MAIN 10 works on windows). It will require major vdpau changes to fully support as vdpau assumes 8bit surfaces throughout its pipeline and that will need to change."
14:08karolherbst: ohh so you want to RE that and hack it together for nouveau?
14:09maxpas: no, just wanted to pass on the info, GM206 decoder is awesome and Pascal will probably get an even better hardware decoder that will be faster than VP7
14:10maxpas: http://www.gputechconf.com/ Tues, April 5 09:00 AM PT Nvidia's big keynote for GTC, probably will get to see Pascal in action finally
14:10karolherbst: yeah well
14:10karolherbst: we still have to RE VP6 and VP7
14:11karolherbst: so there is no hardware decoding on maxwell in any case
14:12maxpas: VP6 doesn't support HEVC & VP9, not very interesting
14:13karolherbst: well, we can't just skip it
14:16karolherbst: anyway, because there are only a handful gpus out there with VP7, nobody will look at that before VP6 is done (most likely)
14:17maxpas: VP6 only has H.264 hardware decoding, very different from VP5 design?
14:18karolherbst: no idea
14:18karolherbst: but seems more different
14:18karolherbst: because there is actually HEVC support on VP6
14:18karolherbst: but shader based
14:19karolherbst: and some VP6 cards should even have hardware HEVC support
14:20maxpas: VP6 HEVC partial hardware decoding has been tested on Windows, it sucks compared to VP7
14:20maxpas: VP7 does 4K 10bit videos at 120FPS easily, even at very high bitrates
14:20karolherbst: mupuf: which product do I have to choose?
14:21maxpas: the hybrid/partial decoder can't handle 10bit and barely can handle 24FPS decoding
14:30mupuf: karolherbst: you are doing it wrong
14:30karolherbst: mupuf: huh?
14:30maxpas: also I wonder why VP6 wasn't figured out already, since GTX 750 Ti/750 GM107 doesn't have Falcon like GM20x does
14:31karolherbst: maxpas: falcons are always there
14:31karolherbst: and if wonder, why don't you give it a shoot ;)
14:32karolherbst: mupuf: I thought we did this htpasswd stuff already?
14:32karolherbst: now I get it
15:11mupuf: karolherbst: review done on envytools
15:11mupuf: for the voltage table
15:12mupuf: pretty good stuff!
15:12mupuf: it is just nitpicking
15:16karolherbst: mupuf: one thing, the read out entries are only there for the entry based parsing and are removed from the other ones. there will be still prints for the lines, because there is something in the entries, but it is all unknown
15:16karolherbst: this is regarding the unrelated fix comment
15:17karolherbst: mupuf: now it looks like this: https://gist.github.com/karolherbst/cfee3501d4f6ff383876 (header based)
15:18mupuf: ack :)
15:19mupuf: Now, for whatever you feel like changing after my comments, fix, and then push :)
15:48karolherbst: mupuf: thanks for the review
15:51mupuf: you're welcome
15:51mupuf: still some more to make!