01:30 pmoreau: RSpliet: Got the EXT_TAG at least on my G84 and G86. In both cases, the blob begins by going from PCIe v1 to PVIe v2.
01:30 pmoreau: Let's see how the other chipsets behave
01:35 pmoreau: G94, G98, GT218 do it as well, though they boot directly in PCIe v2. G80 doesn't support it.
02:18 karolherbst: mhhh we have only 4 counters available on pre kepler... core, memory, video and total then? It's a bit sad for the pcie part, maybe it can be mixed with the memory one, but well :/
02:31 karolherbst: ohh no, we have only 4 on tesla, where we don't have the pcie counter, smart nvidia
02:40 karolherbst: RSpliet: any idea how to add dynamic reclocking to the kernel module? somehow the gk20a way seems a bit troublesome because of this if (!clk || !volt) check in the worker function
02:45 karolherbst: usually I want to poll the counters every x seconds and check if we need to adjust clocks. I hope the overhead doing this every 0.1 seconds is small enough so it doesn't matter, but I can think of a clean enough way to do so yet
03:10 karolherbst: mupuf: okay, voltage is too low with your pwm patches :/
03:18 karolherbst: imirkin: the traps look always the same and I am sure they are caused by low voltage
03:18 karolherbst: ROP value always 80000000 80000001
03:23 karolherbst: imirkin: also I saw some flickering in antichamber, will create an apitrace
04:51 bozhan: hi compiling darktama tree i get /home/bozhan/nouveau/drm/nouveau/nouveau_drm.c:921:3: error: ‘DRIVER_KMS_LEGACY_CONTEXT’ undeclared here (not in a function)
04:51 bozhan: what i can do?
05:05 karolherbst: bozhan: update kernel
05:06 karolherbst: bozhan: I know that 4.1 doesn't work, so it needs either 4.2 or 4.3
05:06 bozhan: karolherbst: DRIVER_KMS_LEGACY_CONTEXT’ undeclared here (not in a function
05:07 bozhan: karolherbst: sorry
05:07 bozhan: karolherbst: make[1]: Leaving directory '/usr/src/linux-headers-4.2.0-1-amd64'
05:07 karolherbst: bozhan: update your kernel to 4.3 then
05:07 bozhan: k
05:07 bozhan: debian is missing linux-kbuild-4.3 yet :))
05:08 waylander: hey, i'm using wayland with noveau. well actually it's xwayland. but how do i list and set xrandr --props options now? i want to change the dithering
05:09 pq: waylander, that is specific to the compositor you use.
05:10 waylander: i'm using fedora 23
05:11 waylander: isn't it weston?
05:11 pq: waylander, I suppose it is gnome-shell then? You'd have to ask a Gnome person if they have any controls for what you want.
05:12 pq: if it was Weston, you'd know it - Weston does not really look like any modern desktop.
05:13 waylander: ok you're right its gnome, but you sure it's gnome specific? i think dithering is a nouveau option
05:13 pq: waylander, in any case, this has nothing to do with nouveau
05:13 pq: waylander, no, the API is standard between the kernel driver and user space.
05:14 waylander: hm ok thank you
05:16 pq: waylander, in general, a thing like "nouveau wayland driver" does not exist, not for any compositor. Hardware-specific display server plugins are an X.org concept.
05:17 pq: waylander, and Xwayland does not use any such plugins at all.
05:18 pq: video DDX might be a more familiar term for what I call a plugin here, or an X.org driver
05:18 waylander: mmh so there's no way to access thos driver functions yet?
05:19 pq: waylander, yes there is: KMS kernel ABI. But it is up to your compositor to expose those knobs to you.
05:19 waylander: i think this topic is not very well documented yet in general :/
05:20 pq: just like with X those knobs are exposed to you by xrandr tool, which uses a special protocol to talk to the X server to ask the kernel KMS driver to set the thing you want.
05:21 pq: waylander, the assumption is that it doesn't need documenting. You're supposed to just click open a display settings dialog in your DE and poke things there.
05:22 pq: if your DE does not yet implement the controls you need, you'll have to make a feature request
05:23 waylander: hm okay maybe that modetest dev tool might work? i forgot where to get it but i think it can talk to the kms driver even from the command line
05:24 pq: it can, but compositors are expected to reset all setting on startup - however they might ignore to do so
05:24 waylander: ok and once they are started, it's too late to set anything with modetest?
05:25 pq: I suppose settings done by a program are not intended to survive when the program exits in general
05:25 pq: you'd fighting with the compositor - might work, might not, no guarantees
05:25 pq: oh, most likely modetest wouldn't run at all
05:26 pq: and if you switch to another VT to run modetest, when you switch back the compositor should be resetting the settings again.
05:27 waylander: if only you didn't set nouveaus dithering option to "auto" for my graphics card, i wouldn't have to go through all this trouble ^^
05:28 pq: there is always someone who doesn't like the defaults :-)
05:28 pq: so it's a game of annoying the smallest group
05:29 waylander: yeah but if it's such a hassle to change the default mmh
05:30 pq: then if you were happy, we'd have a bigger group of extremely annoyed people :-D
05:30 pq: anyway, sorry, this is the situation
05:31 waylander: yeah i see it, probably theres a reason why some cards have auto and others have only off and on
05:34 waylander: allright thanks for your time, valuable information to me.
06:03 pmoreau: RSpliet: Checked on GF100 and GT200, same behaviour as well
06:07 karolherbst: pmoreau: wait, you have other gpus than your both nvidia ones?
06:07 pmoreau: Just added a bunch of vbios from most of my cards, plus two traces
06:07 pmoreau: karolherbst: Yep! :-)
06:07 karolherbst: :D
06:07 karolherbst: I see
06:07 karolherbst: wanna test some dyn reclocking stuff?
06:07 karolherbst: currently fermi+, but well
06:07 pmoreau: Bought them on ebay, when I was planning to continue Roy's work
06:08 karolherbst: I see
06:08 pmoreau: Hum... Thing is I have to pack everything as well, since I'm moving some stuff up to Sweden tomorrow morning
06:08 pmoreau: What should be tested and on which cards?
06:08 pmoreau: brb
06:10 karolherbst: pmoreau: ohh just usualy workload, I wrote a little userspace daemon which uses my new interfaces on the cstate_interface branch. This daemon should read your gpu load out through pdaemon counters and adjust the pstate/cstate to the current load
06:10 karolherbst: just want to test how well the algo is working
06:21 karolherbst: okay, added support fot gt215+ now :)
06:27 karolherbst: hakzsam: are you on reator?
06:28 hakzsam: yes
06:30 karolherbst: k
06:35 pmoreau: Ok, I'll see if I have some time this evening/tonight.
06:36 pmoreau: karolherbst: Do you change PCIe version/speed only upon reclocking? What do you do for cards with only one perflvl that boot with PCIe v1 but support v2?
06:36 pmoreau: And is there a reg indicating the CAP version?
06:37 pmoreau: s/indicating/giving
06:38 karolherbst: pmoreau: I only reclock pcie speed like the vbios tells me
06:38 karolherbst: the speeds are usually bound to pstates, yes
06:38 pmoreau: Ok
06:38 karolherbst: 2. I always try to set the card to v2 mode
06:38 karolherbst: this is already done at init time
06:38 pmoreau: Ok, cool
06:39 pmoreau: The patch for setting to v2 was merged already or not?
06:39 karolherbst: 3. yes there is a reg, on tesla/fermi this reg seems to be at the same speed as the sta speed, on kepler+ the cap is set to max at init
06:39 karolherbst: no
06:39 karolherbst: it is on my pcie_speed branch
06:39 karolherbst: it is just one big patch
06:39 karolherbst: pmoreau: this is all of it: https://github.com/karolherbst/nouveau/commit/f46c3248c6166438007c9b964546126fe3b2e6c6
06:39 karolherbst: chipset specific patches are follow ups
06:40 karolherbst: but this is the core work
06:40 pmoreau: Ok
06:41 pmoreau: Do you have any Tesla cards? Or only Kepler?
06:43 karolherbst: fermi and kepler
06:43 karolherbst: but I don't use the fermi card myself
06:44 karolherbst: I just have like always access to it
06:52 pmoreau: Ok. So they both boot directly in PCIe v2, and iirc, they already have EXT_TAG enabled by default?
06:54 karolherbst: pmoreau: ohhh
06:54 karolherbst: I don't know if I have your patch
06:54 karolherbst: maybe yes
06:55 karolherbst: doesn't seem so
06:55 karolherbst: pmoreau: is your patch upstreamed?
06:57 karolherbst: pmoreau: but yes, on my kepler ExtTag is enabled by default, but not through nouveau
06:58 karolherbst: fermi I don't know
06:59 pmoreau: Not upstreamed yet, I need to change a few things first
06:59 pmoreau: Which chipset is your Fermi?
07:00 karolherbst: not sure, gf106 or gf108
07:01 pmoreau: If you have some time to check what the blob does on it or if EXT_TAG is enabled by default, I would be interested. :-)
07:04 RSpliet: pmoreau: very good :-) I didn't dive into it much myself
07:04 RSpliet: look forward to these PCIe enhancements
07:08 pmoreau: RSpliet: Could you please check which PCIe version is set at boot time for both cards that had a different behaviour, and see if the blob changes the PCIe version?
07:08 karolherbst: pmoreau: blob always tries to set the card to v2 mode
07:08 karolherbst: always
07:08 karolherbst: if it fails, it fails and tries again, if not it is happy
07:09 karolherbst: I think it tires for g84+ cards
07:09 RSpliet: okay, and if it keeps on failing endlessly?
07:09 pmoreau: RSpliet: Then, check if the blob succeeds in moving to v2. :D
07:09 RSpliet: (for instance, on a PCIe v1 motherboard)?
07:09 RSpliet: on my laptop I don't think it succeeds... you might want to check out my NVA8 trace
07:09 pmoreau: RSpliet: It orders a new motherboard on the internet! O.O
07:10 RSpliet: I reckon you can deduce the boot value from traces as well btw :-)
07:10 RSpliet: sorry, I'm a bit occupied with other things atm
07:10 karolherbst: RSpliet: it tries again
07:10 pmoreau: True, they are in nvidia_vbios or on mmiodumps?
07:10 RSpliet: nvidia_vbios
07:10 karolherbst: I already checked all the tesla traces
07:11 RSpliet: karolherbst: I can't imagine it getting stuck in an infinite loop on a PCIe v1 motherboard ;-)
07:11 karolherbst: no, it just retries on every reclock attempt
07:11 karolherbst: and in some few other cases
07:12 RSpliet: ah okay
07:12 RSpliet: well, that's fair enough
07:12 karolherbst: I saw traces where it retired like 20 times
07:12 karolherbst: this is especially strange, because g8x usually doesn't support v2
07:16 pmoreau: My G84 and G86 seemed to support it
07:17 pmoreau: But could be I just didn't looked far enough to see the blob fail / retry
07:19 karolherbst: mhhh
07:19 karolherbst: maybe there are some v2 cards with 2.5 speed
07:19 karolherbst: don't know
07:22 pmoreau: It seemed to be the case for those cards
07:22 karolherbst: mhhh
09:21 karolherbst: RSpliet: what do you think is a better approach: setting up a timer in the clk subdev and call pmu functions, or doing it in the pmu subdev and calling clk functions?
09:32 karolherbst: mwk: are you sure about GR_HUB | GR_GPC | GR_ROP being gf100- only?
09:32 karolherbst: I saw them on gt215, too
09:33 mwk: I'm absolutely certain
09:33 mwk: there's no such thing as a GPC before Fermi
09:33 mwk: they may be something close though
09:34 imirkin: (or HUB for that matter)
09:34 karolherbst: yeah, but I see counters on gt215+ with these bits enabled
09:35 karolherbst: I guess it is practially the same as gpu core load, but maybe just different names
09:35 imirkin: so they're counting something else
09:35 mwk: in all likelihood they're all related to graph though
09:35 karolherbst: what gpu core related does exist on gt215?
09:36 karolherbst: there is always one mem, video and one core counter
09:36 karolherbst: configured
09:36 karolherbst: pcie too, but that is fermi+
11:02 karolherbst: hakzsam: are you done with reator?
11:04 karolherbst: slowly dx 10/11 supports lands in wine, this will be a lot of fun, when all the games starting using tesseleation and stuff :D
11:17 hakzsam: karolherbst, yeah, have fun
11:18 karolherbst: sadly g86 and fermie :/
11:18 karolherbst: *fermi
11:18 karolherbst: reclocking doesn't work on fermi and pdaemon counters are gt215+
11:18 hakzsam: yeah and mupuf won't be able to plug an other card for you
11:18 karolherbst: I know
11:18 imirkin_: not just the counters :) pdaemon is gt215+
11:19 karolherbst: right
11:19 karolherbst: finding a good algo which works is messy though
11:19 karolherbst: I think I really need that information of how long the gpu core is stalling
11:21 karolherbst: but I think I have something more or less usefull
11:21 karolherbst: I just don't know to implement that in kernel space nice and clean
11:22 karolherbst: anyway I would like to test my daemon on a gt215+ tesla card :D
11:23 imirkin_: karolherbst: i have a gt215 plugged in at home, tell me what you need.
11:24 imirkin_: karolherbst: no reclocking on it though
11:24 karolherbst: :/
11:24 karolherbst: yeah well then it is kind of useless
11:24 imirkin_: ah ok
11:24 karolherbst: how can someone test a reclocking daemon on a nocn reclockable card ;)
11:24 imirkin_: you said gt215+.
11:25 karolherbst: yeah, to test my recklocking daemon
11:25 imirkin_: you said counters.
11:25 imirkin_: :p
11:25 karolherbst: allthough any kepler card is fine, too
11:25 karolherbst: and?
11:25 karolherbst: ahh okay
11:25 karolherbst: well
11:25 karolherbst: k, this part could be actually tested
11:25 karolherbst: :D
11:25 imirkin_: it's a gt215. and it has counters. you didn't mention anything about reclocking :p
11:25 karolherbst: then just my daemon (modded)
11:25 imirkin_: send me an email of what you want me to run
11:25 imirkin_: otherwise i'll forget
11:26 karolherbst: mhh, maybe I test this on my fermi card first then
11:26 karolherbst: don't know how much I will work on the daemon later
11:27 karolherbst: I will write you when I think it is ready to be used without support :p
11:28 karolherbst: well the counter part is quite the boring thingy, I am sure I figured this out already, so, that would be rather boring
11:28 karolherbst: I actually want to test the reclocking algo
11:28 imirkin_: sgtm
11:31 karolherbst: hakzsam: is possible to read out the ratio of how long the gpu core is waiting for the memory?
11:31 karolherbst: or can I use a special pdaemon counter for that
11:45 karolherbst: what is PCOPY anyway? Is it a copy engine for stuff but from where to where?
11:45 imirkin_: memory to other memory
11:45 karolherbst: mhhh
11:46 karolherbst: can I detect gpu core stalls with it?
11:46 karolherbst: I mean with the load on those engines
11:46 karolherbst: I need a rock solid way to tell when to increase memory clock but not gpu core clock
11:47 imirkin_: pcopy is a separate engine on gt215 and fermi... iirc on kepler it's part of pfifo or something
11:47 karolherbst: mhhh
11:47 karolherbst: it is enabled along with GR
11:48 karolherbst: BFB_NISO looks like something, but this is like kepler only
11:49 karolherbst: but not reliable enough sadly
11:49 karolherbst: PMFB also is only high when memory bottlenecked :/
13:56 karolherbst: I have around 32% load on the FB_PART0_REQ counter at full idle, any idea what that could be?
13:57 karolherbst: 35% at 07, 32% at 0a, 17% at 0f :/
13:58 imirkin_: requests to fb partition 0?
13:58 imirkin_: memory is split up into partitions
13:59 karolherbst: mhhh
13:59 karolherbst: it is a mobile chip and nothing does anything on it
13:59 imirkin_: ?
13:59 karolherbst: except I do some reg reads
13:59 karolherbst: I am asking me why the counter has such a high value
14:00 imirkin_: it's not as idle as you think it is?
14:01 karolherbst: but there is also this in rnndb variants="GT215-GF100"
14:01 karolherbst: so maybe it is something totally different on my chip
14:01 karolherbst: because another bit is BFB_PART0_REQ
14:01 imirkin_: mmmm... did pre-fermi have partitions?
14:01 imirkin_: iirc that's a fermi thing
14:02 karolherbst: on the BFB_PART0_REQ one I get 0
14:02 karolherbst: so
14:02 karolherbst: ohh no
14:02 karolherbst: there is actually something when I have some load
14:02 imirkin_: er wait, sorry, tesla had partitions
14:02 imirkin_: duh
14:03 karolherbst: I have no clue what so ever, I just try to find something which is very high with glxspheres at 0f, not that high at 0a and nearly 0 with pixmark_piano
14:04 karolherbst: the 8th bit sounds promising though :/
14:04 karolherbst: which is this FB_PART0_REQ bit
14:06 imirkin_: skeggsb_: should it be possible to run nouveau_vieux on a nv3x gpu?
14:07 imirkin_: skeggsb_: i know that older gpu's implemented the even older classes... did nv3x also do that?
14:10 karolherbst: bit 8 and 12 seem to be nice candidates
14:28 karolherbst: okay nice
14:28 karolherbst: one of the is the right one
14:28 karolherbst: maybe both are usefull
14:34 karolherbst: nice
14:34 karolherbst: it seems to work
15:34 imirkin_: joi: why would this stop working? pstate.fifo = gpu_object_find(0, 0xf1f0eeee); // hack
15:43 imirkin_: joi: looks like i never see anything with channel id 0...
15:43 imirkin_: joi: i do see channel 2...
15:52 imirkin_: joi: urgh. looks like this is all prime-related :(
17:19 RSpliet: imirkin_: is there anything special about VirtualBox you can imagine that stops me from using apitrace on it?
17:20 imirkin: *on* it?
17:20 imirkin: or *in* it?
17:23 RSpliet: on it
17:23 RSpliet: running a Windows 8 guest makes nouveau crash when 3D accel is enabled
17:23 RSpliet: would be nice to know what happened
17:24 RSpliet: other than "someone set up us the bomb"
17:24 imirkin: someone set up us the vbox :p
17:24 imirkin: i've been ignoring any bugs relating to vbox tbh
17:24 imirkin: it taints the kernel for a reason
17:25 imirkin: if you can make an apitrace that repros the issue, i'd be happy to look at it though
17:27 RSpliet: yeah, that was my plan
17:27 RSpliet: but right now, when I put apitrace in the middle, it just makes the crash worse to a point that it.... kind of hangs my entire machine
17:28 RSpliet: obviously kind enough to not leave any proper trace
17:28 RSpliet: or... any trace at all really
17:30 RSpliet: it's preventing me from upgrading to Windows 10 while it's free, so the Dutch in me is desparate to find out what's going on
17:32 imirkin: hehe
17:33 imirkin: llvmpipe? :)
17:33 RSpliet: and then replay on nouveau to see it burn?
17:34 imirkin: or just use it for the upgrade
17:34 RSpliet: yes, I guess that'd do
17:34 RSpliet: not as satisfying as contributing to fix a bug though
19:28 karolherbst: talos principle is annoying for reclocking :/
19:28 karolherbst: even at "only" 80% load, higher clocks increase perf :/ I guess the gpu is stalling a lot there
21:27 mrnuke: imirkin: so, I was thinking, what would it take to get maxwell to work decently (don't care about Crysis, but just not crashing or freezing, or grinding on the desktop)
22:08 imirkin: mrnuke: figuring out what's causing the problems, and fixing them
22:09 mrnuke: so, I'm obviously impotent when it comes to graphics. What can I do? Or, in other words, if I give you logs and tests...
22:10 imirkin: mrnuke: one line of thought is that's due to the fact that we don't compute sched codes properly (at all, really) for maxwell
22:10 imirkin: mrnuke: see this trello card: https://trello.com/c/zW06zeI6/116-maxwell-sched-codes
22:11 imirkin: there's no guarantee that fixing this will in any way improve the situation though
22:11 imirkin: i tried to understand wtf that doc was talking about, but couldn't. really i should reach out to the guy and have him explain a few key terms more clearly
22:12 mrnuke: is that userspace fix, or kernel fix?
22:12 imirkin: that's userspace
22:13 mrnuke: I got some interesting errors the other day
22:13 mrnuke: nv50something_something -59
22:15 imirkin: literally -59?
22:15 imirkin: nv50cal_space means the gpu has basically hung
22:15 imirkin: (and it has run out of IB entries to stick pushbufs into)
22:18 mrnuke: I might be able to reproduce it
22:18 mrnuke: hold on
22:20 imirkin: what, a gpu hang? i'm sure you can
22:20 imirkin: all you have to be doing is doing something innocent, and the gpu will hang :)
22:21 imirkin: https://www.youtube.com/watch?v=yg7Xh0m_Oco
22:22 imirkin: one of the coolest features of a macintosh, is that it's really easy to shut down. all you have to be doing is use a piece of software, and poof, it goes away. it's shut down.
22:27 imirkin: anyways, the current situation with maxwell is that i don't have one, and don't plan on looking at anything relating to it until GM20x becomes usable with nouveau.
22:27 imirkin: that obviously doesn't preclude other people from looking at it :)
22:31 mrnuke: are you in the US?
22:31 imirkin: i am
22:31 mrnuke: what's the cheapest maxwell you know of?
22:31 imirkin: i dunno... i think there are some for like $70 or so
22:31 imirkin: but if you're thinking of buying me one -- don't
22:32 mrnuke: I am
22:32 imirkin: i have a limited amount of time
22:32 mrnuke: yeah, but then I'll stop bugging you :p
22:33 imirkin: and i'm a lot better at adding features than i am at debugging completely incomprehensible issues
22:33 mrnuke: as you wish, master imirkin
22:33 imirkin: and i'm secretly hoping that gnurou will fix maxwell before i get to it
22:34 mrnuke: is he in the US?
22:34 imirkin: japan, i believe
22:34 imirkin: he works at nvidia though, so i don't think hardware's an issue for him
22:34 imirkin: he's on the team working on upstream support of the tegra K1/X1
22:34 mrnuke: ooh, well, nvidia is not really known for supporting nouveau
22:35 imirkin: well, they did fix up nouveau to work better with the Tegra K1
22:35 imirkin: although those changes were fairly minor
22:35 mrnuke: do they have a proprietary kernel driver for arm?
22:35 imirkin: my hope is that similar effort will go towards userspace support of the Tegra X1
22:35 imirkin: yes, they do
22:36 imirkin: but i think google's leaning on them to provide better upstream support
22:36 mrnuke: heh. I used to work at google
22:36 imirkin: who didn't
22:36 mrnuke: true that
22:38 mrnuke: funny story today
22:38 mrnuke: went to intel, locked my bike to a post
22:39 mrnuke: got back from work, ready to go home. Someone had built a steel fence around the post
22:39 mrnuke: couldn;t get to my bike
22:40 imirkin: moral of the story -- stay at google?
22:40 mrnuke: there is no moral. It's just hillarious
23:39 bitwise_uk: Hi all .. when I try and run some apps with DRI_PRIME=1 I get a black window, any idea how I can find out whats going on ?
23:39 bitwise_uk: (e.g. glxgears works fine, glxspheres64 is black)
23:45 airlied: bitwise_uk: does resizing the window make it work?
23:48 imirkin: bitwise_uk: you have to be running a compositor for it to work reliably with dri2
23:48 bitwise_uk: Ah, IT *does* draw when I resize !
23:49 bitwise_uk: I'm running gnome-shell, which should be a compositor I think ?
23:49 imirkin: yes, it should
23:49 bitwise_uk: though, at first it draws a few frames as I'm resizing it, then it starts animating at full speed
23:58 bitwise_uk: Any idea what going on? - Resizing fixes my own program too, but obv don't want to resize window every time it starts...