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