08:54mlankhorst: gnurou: can I boot unmodified upstream on nouveau?
09:00RSpliet: mlankhorst, gnurou: and which components will not work if mlankhorst does so? ;-)
09:08mlankhorst: about to find out if drm-intel boots O:-)
09:18imirkin_: mlankhorst: iirc nearly everything works... gnurou had some patches, i forget where they are in ben's tree
09:18imirkin_: looks like they're all upstream by now
09:18imirkin_: only the gm20b stuff is still unpushed
09:20mlankhorst: fortunately I only have a gk20a :-)
09:50CustosLimen: for some reason arandr is allot slower with nouveau than with nvidia
09:51imirkin_: what do you mean by 'slower'?
09:52CustosLimen: takes like 30 seconds to open
09:52specing: imirkin_: did you read my mindfactory comment from yesterday?
09:52CustosLimen: as opposed to almost instantaneus if nvidia drivers
09:52CustosLimen: but actually it might be cos I have wrong glx loaded in xorg
09:52imirkin_: CustosLimen: dunno. it probably does something dumb. what happens if you run 'xrandr'?
09:52CustosLimen: maybe let me try load right one and try again
09:53imirkin_: specing: don't think so. if i did, i forgot.
09:53CustosLimen: imirkin, xrandr is also slow, but not that slow
09:53CustosLimen: imirkin, but I dunno how much slower than before either
09:53CustosLimen: xrandr takes > 1 second
09:53imirkin_: CustosLimen: it should take a second or so to execute. how logn does it take?
09:54imirkin_: CustosLimen: what gpu are you on, and what outputs do you have?
09:54imirkin_: CustosLimen: actually just pastebin your xorg log
09:55imirkin_: 0.7s seems reasonable, esp when DP is involved.
09:55specing: imirkin: RSpliet it looks to me like mindfactory lists underlying chips
09:55CustosLimen: http://termbin.com/12w7 < xorg log
09:55imirkin_: specing: oh right, i did see that.
09:55specing: Codename: GM107-300-A2
09:56imirkin_: specing: where do you see that?
09:56imirkin_: i searched the page for GM107
09:56imirkin_: oh nm, found it
09:56specing: produktdaten tab
09:56imirkin_: under PRODUKTDATENBLATT whatever that is
09:56imirkin_: product data BLATT
09:56specing: product data sheet
09:57specing: I don't speak german either, I just buy from germany because they have a much wider selection at substantially lower prices
09:57specing: and it seems they actually know what they are selling :)
10:00mlankhorst: well fwiw drm-intel-nightly seems to boot on tegra
10:00CustosLimen: ltrace for arandr: http://filebin.net/r3yo8y5379/arandr.txt
10:00specing: imirkin_: what do you say?
10:03imirkin_: specing: about what?
10:03specing: imirkin_: well, you said that marketing doesen't map to chips
10:04imirkin_: specing: it doesn't
10:04specing: but this shop actually lists what I see as chips
10:04imirkin_: specing: one GT 630 might be one thing, another might be another
10:04specing: so basically, you could make purchasing advice
10:04imirkin_: now a particular model from a particular brand -- yes, that'll always be a single chip (almost always)
10:04CustosLimen: is there some alternative to arandr ?
10:04CustosLimen: except ofcourse xrandr
10:04specing: imirkin_: is GM107-300-A2 a chip marking?
10:04imirkin_: CustosLimen: xrandr. works great. and actually arandr is the alternative which usually doesn't work in creative ways.
10:04imirkin_: specing: yea
10:05imirkin_: specing: so i guess they actually just look on the damn thing to see what it is, which seems pretty reliable
10:05CustosLimen: imirkin, arandr is allot quicket to line up screens
10:05specing: imirkin_: so basically you could make recommendations for specific cards?
10:05imirkin_: specing: but you can't get that info looking on the outside of the box :)
10:05CustosLimen: imirkin_, I'm sure its more limited though, but for what it does its quick and easy
10:05specing: imirkin_: apparently mindfactory somehow got that info
10:05imirkin_: CustosLimen: if you say so. i find it's easier to just line the screens up in the first place by adjusting their heights :)
10:05imirkin_: specing: yeah, they probably opened the box and looked inside :)
10:06specing: imirkin_: and removed heatsinks?
10:06specing: and cleaned off the paste to see the markings?
10:06specing: doubt it
10:06imirkin_: CustosLimen: looks like arandr does stuff super-inefficiently... it does XRRGetOutputProperty over and over again
10:07CustosLimen: imirkin, hmm
10:07imirkin_: CustosLimen: i think that might cause us to reprobe things, which takes time
10:07CustosLimen: I see
10:07CustosLimen: ok thanks
10:08imirkin_: CustosLimen: just a guess, but you could speed it up by disabling VGA
10:08imirkin_: i think you can boot with video=VGA-1:d
10:08imirkin_: [assuming you have no need for VGA]
10:08CustosLimen: imirkin, thanks, will look at it a bit if I have time
10:11specing: imirkin_: would you instead be able to give recommendation based on the chip, video ram size and frequencies used?
10:14imirkin_: specing: not sure what you're looking for... all kepler chips tend to work pretty well, gddr5 vram tends not to reclock to the highest perf level, but then again i have a gk208 with ddr3 which for some reason also doesn't relock memory out of the box, i haven't looked at why.
10:15imirkin_: specing: otoh fermi chips tend to boot to higher perf levels and also generally work fairly well
10:15imirkin_: specing: however no chip works extremely well... nouveau has tons of issues
10:15imirkin_: which aren't chip specific
10:17tobijk: specing: and the manufactures may build a non-reference design, which nouveau may not like either ;-)
10:21specing: yeah, but not all linux people looking for a gpu are experts on this
10:21specing: that is why I would really like to see recommendations even if it reads "go see radeon"
10:21imirkin_: specing: "go see intel"
10:21specing: GMA4500HD ftw!
10:22specing: (everything later is hopelessly backdoored)
10:22imirkin_: i740 if you need a separate adapter
10:22specing: ((I really wish more people would know this))
10:36tobijk: specing: if you really want to do something, you could parse the nvidia cards on the side you posted and see if they match to what we have in http://nouveau.freedesktop.org/wiki/CodeNames/
12:38Hauke: Hi, I created a MMIO trace where the nvidia blob sets my monitor to 2560x1440_56 where should I upload it?
12:39imirkin_: Hauke: if you have google drive/dropbox, you could use that, if not email to email@example.com
12:39imirkin_: Hauke: make sure to xz -9 it
12:39Hauke: 60hz seams no possible over hdmi, because some limitation in the pixel clock
12:39imirkin_: 340mhz max
12:40mlankhorst: mst mst mst :D
12:40imirkin_: Hauke: hmmm... 60hz should fit
12:40imirkin_: even a non-reduced mode is 312MHz
12:40imirkin_: and reduced is 241MHz
12:40Hauke: also over hdmi? currently the driver says 225 max on my 560 ti
12:40imirkin_: well, hdmi 1.3 supports 340mhz
12:40imirkin_: and hdmi 1.2 supports 165mhz
12:41Hauke: DELL U2515H (DFP-1): 225.0 MHz maximum pixel clock
12:41imirkin_: there's no mention of "225" on the hdmi wikipedia page
12:42imirkin_: could be a hw limitation though
12:43imirkin_: hmmm... looks like a lot of older hw has a 225mhz limit
12:43imirkin_: also intel ivy bridge
12:45imirkin_: or perhaps there's a bit in the edid that limits the pixel clock
12:46imirkin_: Hauke: do you have the edid block for your monitor?
12:47imirkin_: xrandr --verbose should output... maybe
12:51Hauke: here is the mmiotrace: https://www.hauke-m.de/files/.nouveau/mmiotrace-modset-2560x1440_56.log.xz
12:52Hauke: here is the xrandr output: http://pastebin.com/BFyW1Xfr
12:53Hauke: an older nvidia driver limited this to something lower than 225 mhz and I think with the windows driver it is possible to use ever higher rates, but I haven't tested
12:55imirkin_: hm, your monitor has this in its edid: # Maximum pixel clock is 300MHz
12:55imirkin_: so... very odd that nvidia maxes out at 225. i suspect it's an hw limitation.
12:56Hauke: here is the complete xorg logfile: http://pastebin.com/iKY4CHp9
13:04imirkin_: oh crap
13:04imirkin_: this is probably all in EVO isn't it
13:04imirkin_: i mean the mmiotrace might not have what we wanted
13:05Hauke: do I have to completly startup the desktop?
13:05imirkin_: no, just instead of mmiotracing the blob, might need to get a mmt trace of the Xorg process
13:05Hauke: how do I do that?
13:07imirkin_: but... i'm not sure =/
13:11Hauke: so I have to follow this: https://wiki.freedesktop.org/nouveau/Valgrind-mmt/
13:12imirkin_: Hauke: yeah.... i think.
13:12imirkin_: unfortunately demmt isn't good at decoding the EVO channel =/
13:13imirkin_: this whole thing is just a giant pain
13:13imirkin_: and perhaps all the relevant info is already in the mmiotrace you captured
13:13imirkin_: sorry i'm being so indefinite, i'm just not really sure how it all works
13:13imirkin_: and i think ben's on vacation, or about to leave for one
13:15Hauke: I know this situation of having some hardware and not exactly knowing how it works
13:15imirkin_: well, i generally haven't focused on that stuff at all in the past
13:15imirkin_: so i only have a surface knowledge of how it works
13:16imirkin_: you write some stuff somewhere, magic happens ;)
13:17Hauke: is there some overview documentation on how these nvidia cards are working?
13:17Hauke: I have never workd on graphics only network and embedded stuff
13:18imirkin_: ssssort of
13:18imirkin_: but it's too much to take in all at once
13:19imirkin_: and you might notice that the docs can be a bit incomplete: http://envytools.readthedocs.org/en/latest/hw/display/g80/pdisplay.html
13:25imirkin_: Hauke: perhaps we were just too greedy with our last attempt
13:26imirkin_: Hauke: in nouveau_connector.c edit 165000 to 225000
13:26imirkin_: and see what happens
13:27imirkin_: i think we just set it to 340000 last time and it didn't work, but the user might have also had a fermi
14:13Hauke: imirkin_: 165000 was the max clock in the 295 driver
14:14imirkin_: that's very old
15:07Hauke: just changing that did not helped
15:07imirkin_: Hauke: did you try a higher-than-165mhz mode?
15:15imirkin_: and what happened?
15:16Hauke: imirkin_: https://www.hauke-m.de/files/.nouveau/nouveau-dmesg.log
15:18imirkin_: oh interesting, that's right on setting that weirdo 2048x1152 mode
16:04pmoreau: imirkin_: It reminds me I still need to merge the EVO doc in rnndb, and do some name changing to Nvidia's conventions
21:47gnurou: mlankhorst: RSpliet: imirkin_: so Linux 4.2-rc5 should have everything required to support GK20A
21:48gnurou: but you will also need to use Nouveau's master for it to look for the right firmware files
21:48gnurou: you will also need to use linux-firmware's master branch
21:50gnurou: as well as u-boot from git://git.denx.de/u-boot-tegra.git, branch tegra/next
21:53imirkin: bleargh, someone really needs to look at using nouveau fw
21:56gnurou: for the kernel, use tegra_defconfig and then modify the config to compile Nouveau as a module (and build Nouveau from its own master branch), and enable CONFIG_DRM_TEGRA_STAGING
21:56gnurou: just tested this configuration and it worked on my Jetson TK1. All user-space (libdrm, mesa) should work with the current master branches
21:57gnurou: of course if you want to display buffers rendered by the GPU, you will still need to alter DRM apps to support render-nodes...
21:58imirkin: gnurou: should Just Work (tm) no?
21:58gnurou: imirkin: nope. Most (well, all according to my experience) DRM apps try to use the same card device for display and render
21:59imirkin: gnurou: DRI_PRIME=1
21:59gnurou: imirkin: on Tegra these are two distinct devices, plus you need to do some Tegra-specific tiling setup in order to display buffers correctly
21:59gnurou: will DRI_PRIME=1 work with e.g. kmscube?
21:59gnurou: sorry, I meant KMS when I said DRM
22:00imirkin: gnurou: probably not :)
22:00imirkin: this is only in X
22:00gnurou: ... or should have I said GBM?
22:00gnurou: right, so KMS/GBM apps need some explicit handling for render nodes
22:01gnurou: I have the code for kmscube and glmark2 in my github, and the people at codethink are maintaining a weston patch
22:03imirkin: yeah. i just don't think that's the majority of applications out there
22:03gnurou: imirkin: as soon as you are under X or weston, things work as expected
22:04gnurou: but all DRM/GBM apps I have tried needed to be patched
22:05imirkin: didn't realize there were any :)
22:06gnurou: I am at least happy to finally see the end of the bootloader/kernel patches \o/
22:06gnurou: now there is an even bigger set of patches waiting for Maxwell :)
22:08imirkin: yeah, i'm sure
22:08imirkin: hopefully you're aware that ben's also working on a huge rewrite
22:09imirkin: he said he'd push a branch before he left for vacation, which afaik was today or yesterday, but i don't see one
22:11gnurou: yes, he was kind enough to take a lot of our stuff before that rewrite
22:11gnurou: as for the rest... well we will pay the price for not upstreaming faster
22:12imirkin: ok cool
22:12imirkin: glad you guys are talking
22:31gnurou: we're trying... we still need to get better though
22:32gnurou: ah, just noticed upstream still doesn't have IOMMU enabled for the GPU... not a big deal, but make sure to have enough CMA memory or add "iommus = <&mc TEGRA_SWGROUP_GPU>;" into the GPU's DT node
23:22pq: gnurou, congrats :-)
23:24gnurou: pq: thanks! I wish it took less than one year though :P
23:24gnurou: pq: your help has been critical in solving one of the most complex bugs we had, btw :)
23:25pq: upstreaming mmiotrace take took 1 and a half, IIRC, or something, and I bet you had a huge deal more work to do ;-)
23:26pq: gnurou, oh? Cool, though I can't recall what I might have helped with. :-)
23:26gnurou: pq: https://bugs.freedesktop.org/show_bug.cgi?id=86690 - a fun one!
23:27gnurou: pq: yeah, I want to free myself from downstream stuff as much as possible, but reality is that we need to put devices on shelves too :)
23:34pq: gnurou, oh that one. Coherency... nasty. Glad I could be of help! I had no clue of the underlying problem. :-)
23:41mlankhorst: gnurou: ah