05:08karolherbst: mupuf: hi
05:08mupuf: hey you
05:08karolherbst: mupuf: you hade like three issues in one :D
05:08karolherbst: but did you see my changes?
05:08mupuf: I built on them
05:08karolherbst: yeah I also kind of found out the fini issue
05:09mupuf: and accidently fixed the issue along the way
05:09mupuf: so, what was your analysis on this? :D
05:09karolherbst: so you don't know what was wrong?
05:09mupuf: oh, plenty of things were wrong
05:09karolherbst: 1. timeout is a process
05:09mupuf: that I got :D
05:10karolherbst: it uses signals to kill, which means fini won't be called
05:10karolherbst: neither will be functions passed to atexit
05:10mupuf: yop, I got this one
05:11karolherbst: and you overwrote your temp file in the timeout preload, but this is kind of caused by the fact that timeout is a process
05:12mupuf: yes, got this one too, when I changed w to a when opening the file
05:12mupuf: I moved it back to w though
05:13karolherbst: fun issues though :D
05:15pmoreau: Wow! One article to inform that "the work [on SPIR-V] is progressing slowly". It's true, but... one post for that?
05:16karolherbst: it is about vulkan! so it _is_ important
05:16mupuf: $ sha1sum /home/mupuf/install/lib/dri/i965_dri.so
05:16mupuf: 8c2f5cd1b45409711e46a3fcf9204f04672eaee6 /home/mupuf/install/lib/dri/i965_dri.so
05:17pmoreau: At least I would have asked about which progress were made, just to have something to say about it!
05:17mupuf: pmoreau: he almost never contacts people before writing
05:17karolherbst: pmoreau: nah, he doesn't ask anything
05:17pmoreau: mupuf: For more than 3 lines, pleas use pastebin & co. :p
05:17mupuf: I ranted about that before and told him to contact me on irc before writing
05:18mupuf: it lasted for some time and it stopped years ago
05:18karolherbst: he has an IRC account? :D
05:18mupuf: pmoreau: darn it, my threshold was at 4 :D
05:18mupuf:reajusts his threshold
05:21pmoreau: mupuf: Don't worry, next time I'll lower it to 2. ;-)
05:21mupuf: ah ah, as long as it is not under 1, we should be able to live with it :D
05:24mupuf: karolherbst: https://hastebin.com/veseqemeke.js
05:24mupuf: I should get rid of the Found line
05:24karolherbst: mupuf: should duplicated lines be cleared?
05:25mupuf: well, I could store the handle returned by dlopen
05:25mupuf: and check every time
05:25mupuf: it is not the end of the world
05:25karolherbst: I don't think this is a good idea
05:25karolherbst: handles can be reused, even if it is unlikely
05:26mupuf: well, I can track that with dlclose
05:26karolherbst: then you would also have a list of active handles :/
05:26mupuf: which is what I do for the ioctl
05:29hakzsam: imirkin, oh yeah! Good idea, I'll start to write a wiki page for those performance counters
05:31mupuf: hakzsam: don't forget the feature matrix!
05:32mupuf: You will love writing them, they are the best :D
05:32mupuf: you'll thank us later
05:35karolherbst: mupuf: I really would like to hack up this first cloack gating approach together, but for that I would like to know where I shall put it. Anyway, I couldn't think of any way to check which reg is for which engine. I mean I could just use all engines at once, turn one gate off and see which one is gone
05:35mupuf: karolherbst: did you check a mmiotrace to see when the blob disables clock gating?
05:35mupuf: that will tell yu a lot on where you need to put it :p
05:36karolherbst: okay, never did this so far
05:36mupuf: does the proposal seem acceptable? :p
05:38mupuf: karolherbst: on my side, I need to add support for the libraries that are linked at boot time
05:39mupuf: dl_iterate_phdr looks like what we need!
05:41hakzsam: imirkin, I sent you a trace as you asked me
06:06mupuf: karolherbst: TADAM https://hastebin.com/jahiditeya.avrasm
07:16imirkin: hakzsam: i meant a trace of a program that actually used both 3d and compute pipelines
07:16imirkin: hakzsam: i don't think that nvidia inits compute by default
07:19hakzsam: imirkin, ah okay! I'll do it later because I'm running piglit tests on my NVA8 currently
07:19imirkin: hakzsam: well, first you'll have to write such a program, i don't think there are any suitable ones in piglit.... maybe.
07:20hakzsam: imirkin, maybe there is such a program in the cuda samples
07:20hakzsam: which uses both 3D and compute
07:20hakzsam: I'll check
07:22pmoreau: I'm quite sure there is one
07:22imirkin: hakzsam: can you use 3d with cuda?
07:22pmoreau: You can mix OpenGL and Cuda
07:22pmoreau: And share buffers/textures between both
07:23hakzsam: yes I know
07:34Halfwit: Cairo seems fun.
07:42Halfwit: Sorry, wrong buffer ^^
08:42ravenfard: Greetings! -- question for anyone: I have a GeForce 7600 GT card, and I'm running Arch Linux --- does anyone know whether there are still problems with suspend/hibernate with the nouveau driver?
08:45karolherbst: mupuf: nice :)
08:46karolherbst: mupuf: what about deps pulled in by DYNLINKs?
08:47pmoreau: ravenfard: No idea… It will probably be easier to just try. :-)
08:47pmoreau: ravenfard: What kind of problem was it?
08:49mupuf: ah, right
08:49mupuf: I do not know how to test that
08:50karolherbst: how do you check the BOOTLINKS?
08:50ravenfard: When I can get it to actually wake up from suspend, I get crazy visual artefacts all over the place, especially the background. Most of the time, I try to wake and I get fans and power, but no visuals.
08:52ravenfard: pmoreau: sorry that last comment was to you
08:52pmoreau: Hum… When did you try for the last time? It could be that it was fixed.
08:53pmoreau: But I would say, just test and see. :-)
08:53ravenfard: it's probably been over a year
08:53pmoreau: Was there a bug report for it?
08:53ravenfard: yeah -- I suppose I should take the plunge
08:54ravenfard: not sure about bug reports -- haven't done anything with reporting bugs before; have searched through bug reports a tiny bit in the past, though
08:55ravenfard: thanks anyway for answering!
08:55pmoreau: No problem :-)
09:00mupuf: karolherbst: sorry, back
09:01mupuf: dl_iterate_phdr in init()
09:06karolherbst: maybe you can do that after dlopen new stuff and check for new entries
09:18mupuf: well, that could work, indeed
09:32imirkin: ravenfard: make sure you check with a recent kernel. if it still happens, file a bug with the particulars.
09:39imirkin: skeggsb_: any chance GEM_INFO could lie? looks like it's relying on "nvbo->bo.mem.mem_type == TTM_PL_TT" to distinguish between vram/gart -- but what if it's been moved to system (due to e.g. a suspend/resume situation)?
10:32plop: hello, I'd like to explore the possibility to run floss games with a completely floss graphic stack, and I'd like to have some information about the present and future situation of nvidia gpus on this
10:32imirkin: ask away
10:33plop: what is the situation of the firmwares in the nouveau project, and how is it comparing to the radeon cards ?
10:34plop: more precisely : is there one or several cards which don't require any nonfree firmware at all ?
10:34imirkin: please define 'firmware'
10:35mupuf: plop: anything under the newest maxwell should be good if you do not need video decoding
10:35plop: imirkin: on radeon cards, you need to install a binary package with non-free license otherwise you can't use acceleration, hd screens, and pretty much all cool features
10:35mupuf: basically, avoid maxwell unless it is the GM107 chipset
10:36plop: I don't need video decoding
10:36imirkin: plop: how do you feel about the vbios?
10:37plop: mupuf : so anything up to NVF0 here ? https://wiki.freedesktop.org/nouveau/FeatureMatrix/
10:37imirkin: plop: anyways, as mupuf said, you can use entirely free software stack with nvidia chips up to and including GM107 (although i wouldn't recommend maxwell at this point)
10:37mupuf: imirkin: the vbios does not run any code after nouveau is booted, but yes, it is proprietary shit
10:37imirkin: mupuf: it contains scripts which nouveau interprets, and it contains code that gets run by the bios at boot
10:38mupuf: yes, true, there are scripts executed by nouveau
10:38mupuf: like acpi scripts are executed by linux
10:38plop: imirkin: I'd like to avoid blobs as much as I can, so if there's a card that is more likely to have its vbios RE than an other, I'll take this one
10:38mupuf: ah ah, do not hold you breath on any one of them
10:38imirkin: plop: vbios contains a lot of board-specific info, there will never be a project to replace it
10:39imirkin: at least not for any sort of wide collection of hw
10:39mupuf: although someone has been working on adding support to coreboot for some nvidia gpus, but he works through binary analysis and decompilation
10:39mupuf: so ... not sure it will ever be allowed upstream
10:39plop: imirkin: there's been some work on the vbios of some IGP on coreboot
10:39mupuf: and yes, some scripts are too board-specific
10:39imirkin: plop: sure, for any particular board it can be made to work
10:40imirkin: plop: but there are thousands of different boards
10:40imirkin: plop: with no real way to tell them apart
10:43plop: I could try a coreboot Intel board, but I don't know if I could run everything I want on it. I could try an AMD dedicated card, but I don't know if the fw will get RE one day. So I'm thinking about nouveau-supported gpus, since the project seems to be doing much better than I expected.
10:43imirkin: nouveau is fine as long as you don't do anything too crazy
10:44imirkin: definitely pretty easy to crash it though, and there's no gpu recovery
10:45plop: imirkin: oh I know the perfs aren't there yet, but it looks like nouveau will get acceptable performance before radeon gets free firmware, so...
10:45imirkin: i'm not talking about perf
10:49plop: imirkin: when does nouveau crash currently ?
10:50imirkin: have a look at the bugtracker
10:51imirkin: the very latest example: https://bugs.freedesktop.org/show_bug.cgi?id=92504
10:51imirkin: but there's plenty more
10:54plop: ok so buying a retail nvidia card now would still be a long-term decision :D
10:55imirkin: i would def recommend going for amd or intel hw depending on your needs
10:55imirkin: i don't really see what the big deal is wrt amd cheaping out and not sticking the fw onboard but instead having the cpu upload it...
10:56imirkin: [not just about being cheap, also about being able to update it as necessary]
10:57plop: Intel is worse and worse, coreboot devs say that using amd firmwares is les critical than using Intel motherboards
10:58plop: in therms of freedom
10:58plop: and they will start to make GPUs that need a nonfree firmware
10:58imirkin: ok, i'm just talking about the gpu hw. anyways... that's the current situation :)
10:59imirkin: GM20x require signed firmware, and it's less-than-likely that nvidia will want to sign nouveau firmware
11:06lightning18: guys, is the OpenGL version a driver limitation? even when on GL3.txt, it says that nvc0 is 100% above 3.1? What am I not getting here?
11:06imirkin: lightning18: if you're seeing version 2.1, you forgot --enable-texture-float
11:07imirkin: lightning18: if you're seeing 3.0 you forgot to create a core profile, mesa only supports up to 3.0 on compat profiles
11:07lightning18: it's 3.0, is it the ceiling?
11:07imirkin: for compat profiles, yes
11:07imirkin: make a core profile and you should get GL 4.1 with mesa 11.0
11:09huelter: I`m running gentoo with mesa 11.0.3, but glxinfo is not reporting the core profile version, dunno what is missing
11:10imirkin: huelter: USE=-bindist
11:11huelter: Disable patent-encumbered ARB_texture_float, EXT_texture_shared_exponent, and EXT_packed_float extensions.
11:14lightning18: imirkin: Thanks for the answer, I'll look more into it.
11:51karolherbst: mupuf: your idea was really good with the gates
11:51karolherbst: now I also know what they are good for :D
11:51mupuf: what do you mean? the idea of checking in the mmiotrace when they are put in auto or not?
11:52mupuf: so, what are your findings?
11:52karolherbst: it is always like this: some engine stuff, gates, ptherm
11:52karolherbst: PGRAPH, 0x20200, PTHERM
11:52karolherbst: PPDEV, 0x20204, PTHERM
11:52karolherbst: and so on
11:53mupuf: oh, so you can map them like that :) sweet
11:53karolherbst: wait, I have to write it down carefully first
11:54karolherbst: mupuf: so far: https://gist.github.com/karolherbst/b4b28a0ebf5f253b5a69
11:55karolherbst: | grep "0x0202[0-5][048c] " -A5 -B5
11:55karolherbst: firs step: setting to auto
11:55karolherbst: second step: setting latencies
11:56karolherbst: the blob touches 0x10 and 0x1000 inside PTHERM after the gates
11:56karolherbst: I meant 0x020288 and 0x02028c
11:58mupuf: and after that, it never touches the clock gating, ever?
11:58karolherbst: usually not
11:58karolherbst: there are cases though, but if the card stays idle, then no
11:58mupuf: I care about the cases when it does
11:58mupuf: why does it do it?
11:59mupuf: that is what we need to understand!
11:59karolherbst: yes, but to understand what engine handles which gate is also kind of important :)
11:59karolherbst: makes the second part a bit easier
12:01karolherbst: mupuf: but on my card the blob doesn't change the gates as much as on other cards anyway
12:02mupuf: please stop saying the gates :D
12:02mupuf: a gate == NOR, NAND, AND, OR, XOR, etc...
12:02mupuf: clock gating or power gating
12:02mupuf: if you want to keep it short, CG and PG
12:03pmoreau: But CG is Computer Graphics, and PG Pacific Graphics
12:03mupuf: ah ah
12:03pmoreau: Like BB is Bounding Box
12:04mupuf: well, nvidia uses ELPG and SLCG
12:04mupuf: and another one I forgot
12:04mupuf: CG and PG will do the trick though
12:04pmoreau: Seems somewhat verbose
12:04mupuf: well, it is accurate
12:04mupuf: there is a ton of power gating happening
12:04mupuf: most of it is not manageable
12:05karolherbst: mupuf: okay, the blob doesn't seem to touch it ever again, at least in my traces
12:05pmoreau: Extremely Linear Power Gating?
12:05karolherbst: I will then create a new one. Any idea what I should do so that the blob might change them?
12:05mupuf: pmoreau: sorry, Engine-level PG
12:05pmoreau: mupuf: :-(
12:05mupuf: karolherbst: check on other mmiotraces first
12:06karolherbst: how shall I name the regs then? PTHERM.ENG_GATE_CTRL.PGRAPH .. and so on?
12:06mupuf: I think we should add new clock-gating methods for engines
12:07mupuf: RRRrrrr, please stop saying gate :D
12:07mupuf: gate means nothing in this context
12:07mupuf: especially since we need to handle both clock and power gating
12:07karolherbst: envytools calls the reg that
12:07mupuf: ah, right, nvidia's stupid name
12:08mupuf: so, I would advise creating a group
12:08mupuf: and then adding a line per register
12:09mupuf: PGRAPH_CG_CTRL, etc...
12:09mupuf: it will make much more sense than anything else
12:10karolherbst: mupuf: <array><use-group></array> then in place for the current decleration?
12:10mupuf: no array
12:12karolherbst: what else?
12:18mupuf: that's all for the regs
12:18karlmag:gives mupuf some 74HC-series gate ICs he can throw at karolherbst.... *finds popcorn and sits down*
12:18karolherbst: I meant, what should I use instead of array
12:19mupuf: you repeat the lines yourself
12:19mupuf: each of them with a different name
12:19karolherbst: mhh okay
12:19mupuf: but, to avoid repeating the same content for the regs, use a group
12:20mupuf: this way, no need to have a mapping tablei n your head between the clock domain id and the actual engine
12:21karolherbst: yeah okay, I was confused, because this group is already there (for the bits of the regs)
12:22karolherbst: how should I name the PGRAPH ones?
12:23karolherbst: or something else?
12:23karolherbst: PCOPY I meant
12:25mupuf: PCOPY for the first one
12:28karolherbst: mupuf: like this? https://gist.github.com/karolherbst/660034acbef70721f177
12:28mupuf: you kept the array for rest?
12:29karolherbst: well, I think one of them is used in some other card
12:29karolherbst: I could remove them, but they aren't really unknown as well
12:30karolherbst: mupuf: 0x020254 is set on your nve6 card
12:30karolherbst: it is only read
12:30karolherbst: after some PCI stuff
12:30karolherbst: strange :/
12:30mupuf: just add them under a different name each time based on their address
12:31mupuf: UNK254_CG_CTRL for instance
12:31karolherbst: so many lines :D
12:32karolherbst: okay done
12:32karolherbst: these are fermi only or do gt215 has these regs?
12:36karolherbst: okay, the first 8 ones are done :)
12:36karolherbst: 0x214 was pcopy1
12:36karolherbst: obviously :/
12:36karolherbst: mupuf: usually the blob only sets all the gates on boot for the card and is done with them, on kepler that is (checked 4 cards now)
12:37mupuf: why are you talking about bill?
12:38mupuf: you are technically right in saying gates, because that is all it is, but since a processor is made entirely out of gates, you are basically saying something equivalent to "thing"
12:38mupuf: the blob sets all the things on boot
12:38karolherbst: so? :p
12:39mupuf: so, it sounds great
12:39mupuf: but that's not it
12:39karolherbst: kepler is boring :/ all that stuff is so straightforward
12:39mupuf: on tesla, the engine level clock gating is done by 1588 IIRC
12:39mupuf: and there, some engines did not have support for automatic clock gating
12:40karolherbst: don't care for now :p
12:40mupuf: and, IIRC< when reclocking, we may need to disable clock gating
12:40karolherbst: I just take care of the easiest chipsets
12:40karolherbst: hack a patch together
12:40mupuf: well, you should because you are wondering how you want to architect your code
12:40karolherbst: and put this for testing out
12:40karolherbst: mhhh, yeah well
12:40karolherbst: you got me
12:40mupuf: if you want people to test it, a bash script is enough :D
12:41mupuf: no need for a patch
12:41mupuf:is a bastard, sorry
12:41karolherbst: even a script is too much
12:41pmoreau: karolherbst: O:-) please do, please do! :D
12:41karolherbst: nvapoke 0x20200 0x60 27722455
12:41mupuf: right, make an alias, even better
12:41karolherbst: if that crashses any card, please tell me
12:41karolherbst: mupuf: then its more than one line :O
12:42mupuf: now, let's focus on the architecture and then merge that in nouveau, even if kepler only is supported
12:42mupuf: but at least, we can talk to ben with a reasonable certitude about how future-proof the interface is
12:43mupuf: I would think that add methods like init() and fini() to engines would be enough
12:43karolherbst: mupuf: what could happen with a disabled PPCI engine?
12:43karolherbst: mupuf: mhhh
12:43mupuf: hehe, we actually do that you know, during reclocking
12:43karolherbst: there is some latency handling on some cards
12:44mupuf: we program HWSQ or PDAEMON to put the card off bus, do stuff and then put it back on bus
12:44karolherbst: we have to set those regs on init anyway
12:44karolherbst: because suspend and stuff
12:45karolherbst: the regs even reduced power consumption by 2W for me under non full load (like 95%)
12:46karolherbst: what I don't understand though is, why the blob sets ENG_CLK=auto but leaves ENG_PWR=RUN :/
12:46karolherbst: and ENG_PWR is never touched
12:46karolherbst: yeah, done with all nve* cards
12:49karolherbst: meh, maxwell looks equally boring
12:52karolherbst: mupuf: the blob totally trusts the default value inside the regs
12:56mupuf: what do you mean by trust?
12:56mupuf: yeah, maxwell and fermi should be the same
12:56mupuf: well, do the same as the blob
12:57mupuf: https://hastebin.com/ogegitofik.avrasm <-- btw
12:57mupuf: karolherbst: https://hastebin.com/qesofelaki.php
12:57mupuf: I got the dependencies added :)
12:59mupuf: it is funnier with kwin: http://paste.pound-python.org/show/4wRNKPLaLWL1AHLXh9uQ/
13:00karolherbst: try chromium :D
13:01karolherbst: or some video player
13:01mupuf: hmm, yeah, I want to test a multithreaded case
13:01mupuf: but multi-process... this one is not going to end well!
13:02karolherbst: it kind of has to deal with it
13:02karolherbst: try unigine heaven through the launcher
13:04mupuf: yes, I wonder if should create a new file per pid
13:04mupuf: what do you think?
13:04mupuf: that would solve the issue
13:04mupuf: and I can get the exe name from /proc/self/exe
13:04karolherbst: mupuf: it seems that the blob doesn't turn the engines back to RUN before suspend
13:04karolherbst: mupuf: yes
13:04karolherbst: makes sense
13:08karolherbst: mupuf: okay, the traces either don't help much or there isn't more to it. the blob sets ENG_CLK=auto on boot and after suspend
13:09mupuf: sounds reasonable
13:09mupuf: check on tesla now :D
13:11karolherbst: mupuf: https://github.com/karolherbst/envytools/commit/8a2814d908c17244198009bc8a470a5f8e67b30f
13:13mupuf: fine by me
13:14mupuf: did you guess PCOPY1?
13:14karolherbst: I found it in some traces
13:15karolherbst: my only guess would be UNK254_CG_CTRL = PPCI
13:15karolherbst: it was only read
13:16mupuf: well, one can always put that to the test :D
13:16karolherbst: what shall happen after I turn PPCI off?
13:17mupuf: well, you won't be able to read any reg :D
13:17karolherbst: I am able to write them
13:17karolherbst: I can turn all those engines off
13:17karolherbst: and turn them on again
13:17karolherbst: no problem
13:18mupuf: vlc is hilarious http://paste.pound-python.org/show/aHXqG2FP7Rz2XBW0cj7L/
13:18mupuf: on tesla, you will not have this lovely behaviour ;D
13:19mupuf: if you did not get power reduction, I would say that clock gating does not work
13:19karolherbst: well I get one
13:19karolherbst: usually 10-15% in full idle
13:19mupuf: hmm, vlc is insane
13:19karolherbst: who tells me, that it worked for every engine?
13:20mupuf: yeah, but then, look, I open 200 fd
13:20karolherbst: check what this library links against
13:20mupuf: out of the 1024 allowed
13:20karolherbst: and avformat
13:20karolherbst: only 1024?
13:21mupuf: imirkin: see ulimit -a
13:21mupuf: and try allocating more than 1024 fd
13:21mupuf: you are in for a treat
13:21imirkin: oh, true =/
13:21mupuf: this was the reaosn why we got GEM handles and not fd
13:22phroa: I have a... strange problem. booting the arch linux installation media on my MacBookPro5,3 and it appears something in nouveau is causing a core dump making it totally unresponsive
13:22phroa: how do I troubleshoot _this_?
13:23imirkin: phroa: this is the MCP79/G96 combo one?
13:23phroa: I don't know what those numbers mean, but I'm *fairly* sure that there's a dual GT9600M and 9400M
13:23phroa: let me check everymac.
13:23imirkin: well, you could check lspci
13:23imirkin: anyways, that sounds right. pmoreau --^
13:23phroa: indeed I could do that, one moment
13:24pmoreau: Same as mine
13:24pmoreau: phroa: Except if you're running Nouveau git, you need one additional patch to get the G96 to work properly
13:24phroa: I don't know what version this is. this is the latest arch linux image
13:25pmoreau: Then it is 4.2.3 iirc
13:25pmoreau: So, either you build your own kernel/nouveau module, or you poke some register before loading Nouveau, or you pci_reset the card before loading Nouveau
13:26pmoreau: Beware that the two last solutions won't work if you suspend/resume the G96 card, as the fix gets lost.
13:27pmoreau: phroa: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=a978bf48487cbc9828de47b724ce682e0e073cbf is the patch you need
13:28phroa: late to the party, but here's the hardware info: http://ix.io/lti
13:28phroa: thanks for that, I'll look at building my own image somehow.
13:28pmoreau: Yep, same as my laptop
13:29pmoreau: In the mean time, you can try `echo 1 > /sys/bus/pci/devices/0000:02:00.0/reset; echo 1 > /sys/bus/pci/devices/0000:02:00.0/rescan` before loading Nouveau
13:30phroa: it fails before I get a console, and sysfs doesn't exist on os x so I can't poke it there.
13:30pmoreau: Which means you need to blacklist Nouveau and load it manually
13:32pmoreau: Or if you clone and install envytools (https://github.com/envytools/envytools/), you can do `nvapoke -c0 88080 2910`, still before Nouveau is loaded
13:33pmoreau: phroa: But if you compile your own kernel, you will also get reclocking on the G96 ;-)
13:33phroa: I think that's the way I'll have to go... I really have no clue how I'd be able to do the other things you mention
13:33pmoreau: (And switch between both cards using vgaswitcheroo)
13:34pmoreau: The first one doesn't need to install anything, just running a command
13:34pmoreau: (And putting a file in /etc/modprobe.d/ containing "blacklist nouveau")
13:34phroa: the first one being 'In the mean time'? I don't have a /sys/.
13:35pmoreau: Oh! I have it mounted automatically on Arch
13:35phroa: I would have a /sys/ if I had arch installed. this happens to the installation disk.
13:35phroa: and bsd doesn't seem to use /sys
13:36pmoreau: Could be, I never used BSD.
13:36pmoreau: If you want to install Arch without troubles, just add nouveau.modeset=0 to disable Nouveau
13:37pmoreau: And then, once it is installed, you can *mess* around to get Nouveau to work
13:43pmoreau: phroa: FYI, there is still an issue on this laptop: when you try to connect to an external screen, either you get no signal, or it flickers, depending on which adapter you uses.
13:43phroa: I don't intend to, but thanks
13:44pmoreau: I should go back to that issue one day…
13:52phroa: pmoreau: adding 'modprobe.blacklist=nouveau' let me boot without any recompiling =) thanks anyways!
13:53phroa: (to the boot flags)
13:53pmoreau: Oh true, you can do that as well
13:54pmoreau: phroa: You'll probably want to compile your own kernel, or wait for 4.4, if you want to use Nouveau
13:54phroa: I'll take my chances with a blob, methinks.
13:54phroa: I'm mainly concerned about, y'know, being able to boot right now :3
13:55pmoreau: The blob can't suspend one of the card, or switch between cards.
14:22hakzsam: git-send-email is *really* broken on arch
14:26pmoreau: hakzsam: It's still broken? --"
14:27hakzsam: pmoreau, yeah, don't upgrade git to 2.6.1
14:27hakzsam: it's broken for me
14:29pmoreau: I upgraded two (maybe) three weeks ago already :D
14:29mupuf: hakzsam: haved you reported the bug yet?
14:29pmoreau: s/maybe/maybe three
14:29hakzsam: pmoreau, and it works for you?
14:29hakzsam: mupuf, nope
14:29hakzsam: maybe it's related to my config
14:30pmoreau: hakzsam: Nope, but I used the patch karolherbst gave me (from gentoo iirc)
14:30mupuf: works for me though
14:30pmoreau: With 2.6.1 ?
14:30hakzsam: mupuf, git-send-email works for you?
14:30mupuf: Version : 2.6.1-1
14:31mupuf:will do his updates and see
14:31hakzsam: have fun!
14:31mupuf: seems like I am only behind on the new kframeworks
14:31mupuf: and some new kde apps
14:32mupuf: I definitely updated my distros a few days ago
14:32hakzsam: mupuf, try to git-send-email to yourself :)
14:32mupuf: hakzsam: just did
14:32mupuf: I can send an email to you if you want
14:32hakzsam: it's okay!
14:32hakzsam: well, this is related to my config then
14:33hakzsam: probably to those fucking perl modules
14:33mupuf: I use free's smtp
14:33mupuf: and ssl
14:33pmoreau: To mine too as well then
14:33pmoreau: I also use free's smtp and ssl, but it doesn't work
14:33pmoreau: (And it used to work)
14:33mupuf: port 465?
14:33mupuf: well, then we'll see if I can reproduce after the upgrade
14:34pmoreau: Aren't you already on 2.6.1?
14:34hakzsam: mupuf, btw, did you change the cards in reator?
14:35hakzsam: imirkin, Hey, this nv50 series is the *last* which moves lot of code :)
14:35mupuf: hakzsam: did you ask me to?
14:35mupuf: pmoreau: yes, I am
14:35imirkin: famous last words
14:35pmoreau: hakzsam: Last until next time? :p
14:36pmoreau: mupuf: Then you should be experiencing the same problem already
14:36hakzsam: mupuf, nope, but it's fine by me if there a fermi and a kepler
14:37hakzsam: pmoreau, the next time I'll *add* lot of code :D
14:38mupuf: still working after the giga update
14:41hakzsam: well, time to sleep, see you!
14:42mupuf: see you!
14:57mupuf: karolherbst: I am afraid that the delayed sha1 is a bad idea
14:57mupuf: not only because it eats up fd space, but also ... because of fucking signals
14:58mupuf: and there is no way to do it reliably
14:58mupuf: so I guess I will make the code a little simpler and not handle the delayed allocation
15:00karolherbst: mupuf: k
16:41imirkin: skeggsb: did you see my questions earlier?
16:41skeggsb: imirkin: i think they got scrolled off
16:44imirkin: skeggsb: i was looking into https://bugs.freedesktop.org/show_bug.cgi?id=92504
16:44imirkin: skeggsb: looks like there's some sort of desync between mesa and the kernel re the valid domains of the buffer
16:44imirkin: it looks like suspend/resume somehow plays into it
16:45imirkin: and also i was looking at how GEM_INFO worked and wasn't convinced that it set the domain on the returned buffer correctly
16:47skeggsb: there shouldn't be a desync, that's fixed at creation time...
16:49skeggsb: that's a somewhat arbitrary restriction on most boards anyway, it's only legit for tesla (no way to keep a fixed virtual address if a buffer is valid for both large-page vram and small-page sysmem)
16:49skeggsb: fermi has dual page tables, which fixes that issue
16:54imirkin: skeggsb: well, from the sounds of it, this is only happening on tesla
16:54imirkin: skeggsb: in either case, restriction being arbitrary or not, any idea how this is happening?
16:54imirkin: i've checked mesa pretty carefully and i don't see an obvious way to be messing up the gart/vram thing
16:55skeggsb: any idea *which* buffer it's happening to?
16:55imirkin: best guess is a shared buffer being imported and getting the wrong bits set
16:55imirkin: can you give me a way to print the bo's va in that set_domain check function?
16:55imirkin: i poked around and there didn't seem to be a particularly obvious way to do that
16:56skeggsb: look it up with nouveau_bo_vma_find(), a bo can have multiple if it's referenced by more than one channel
16:57imirkin: ah, that's why i couldn't figure out how to do that :)
16:57imirkin: nouveau_bo_vma_find(struct nouveau_bo *, struct nvkm_vm *);
16:57imirkin: where do i get the nvkm_vm from?
16:58imirkin: you know my next question right? :)
16:58skeggsb: nouveau_cli is already present in basically every ioctl function :)
16:59imirkin: aha, got it
16:59mupuf: imirkin: finding this kind of information is much easier now, since the rewrite
16:59skeggsb: mupuf: well, that stuff wasn't really touched, and is still very very nasty and tangled :P
17:00skeggsb: i'll fix that with some work to better expose what vulkan's memory model needs
17:00imirkin: well, it's more that i can figure out how to get *some* address, but i need to find the *right* address
17:00mupuf:created a new subdev last week and it was suddenly super easy. It felt like a whack-a-mole game, fix until it stops crashing, but then all made sense
17:00skeggsb: mupuf: glad you think it was an improvement too :)
17:01mupuf: definitely, having the compiler telling you: stop, you idiot! is much better than running, crashing, rebooting
17:02skeggsb: yes, i definitely made some horrific choices the first time around ;)
17:02mupuf: well, that was a big undertaking :p
17:02imirkin: skeggsb: and vma->offset is what i want right?
17:02mupuf: anyway, bed time for me, gentlemen
17:03mupuf: have a good day and evening, respectively
17:05imirkin: skeggsb: does this seem reasonable? http://hastebin.com/sepefasoga.pl
17:05imirkin: skeggsb: and any other potentially useful info?
17:05imirkin: is there a way to tell if it's shared or not?
17:22skeggsb: imirkin: no easy way to know if it's shared aside from checking the list for if there's more than one vma i guess
17:22skeggsb: maybe buffer size etc could be useful to narrow down which exact buffer it is
17:22imirkin: skeggsb: ok, i'll leave that for later. ah yeah, buf size seems good
17:23karolherbst_phon: IRC clients on phones are really strange :/
17:23imirkin: skeggsb: and of course i'd get the size from....?
17:23imirkin: skeggsb: btw, the vma refcount doesn't say anything interesting does it?
17:24skeggsb: nvbo->bo.mem.num_pages << PAGE_SHIFT, probably..
17:24skeggsb: that's ttm's idea of the size anyway, should be accurate
17:25skeggsb: nah, nothing interesting really
17:26imirkin: skeggsb: any ideas off the top of your head about what could be the issue here?
17:26imirkin: skeggsb: and how suspend/resume could be playing into it?
17:27skeggsb: your guess is as good as mine, but, i think having the wrong info about an imported bo is a good first suspect
17:27imirkin: if (nvbo->bo.mem.mem_type == TTM_PL_TT)
17:27skeggsb: especially given that you've inspected mesa's own handling closely
17:28imirkin: does that not seem suspect to you re determining gart vs vram?
17:28imirkin: what if it's system for example?
17:28imirkin: shouldn't that be driven off of nvbo->valid_domains?
17:29skeggsb: INFO should perhaps return valid domains too, that was kinda tacked on when we went to fixed virtual addresses
17:30skeggsb: it does perhaps look like things could end up in SYSTEM on suspend, maybe..
17:30skeggsb: (note how anything to do with ttm is a "maybe" ;))
17:31imirkin: unfortunately it doesn't match the symptoms
17:31imirkin: since in this case it'd return vram as the valid domain
17:31imirkin: whereas in this case userspace is saying GART as the valid domain