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