07:00martm: \o/ gotta a scheduler idea in place with all the gpu branch stack lifo implementation, interrupts and finally cache controller for the possible firmware replication, but just as i was getting another breakthrough, another fargment of my tooth broke, getting weak but tomorrow i schedule the dentist appointment
07:07martm: i have not really delt with things where there are possible experts here, vbios and pmu all that is dark land to me, ideas are ready but it's gonna take some months like half a year to get drivers tested on fully programmable hw
07:44karolherbst: RSpliet: uhh, I configured the pll with N82, M10, P4 and I got 860 MHz, but only 44 fps in glxspheres....
07:44karolherbst: usually I get like 1300
07:44karolherbst: and also this while recklocking: timeout at /home/karol/Dokumente/repos/nouveau/drm/nouveau/nvkm/subdev/clk/gk104.c:400/gk104_clk_prog_2()
07:53RSpliet: then probably something went wrong and it resorted to a clock you weren't expecting ;-)
07:54RSpliet: the timeout is probably "PLL didn't lock
07:54karolherbst: well it kind of worked with P = 2
07:54karolherbst: same perf
07:55karolherbst: but still a timeout
07:55karolherbst: but not that long
07:55karolherbst: well have to reboot, pmu locked up
07:55RSpliet: both sound put of range really
08:02karolherbst: yeah, somehow P>2 is pretty unstable
08:04RSpliet: karolherbst: ftr: https://github.com/kfractal/nouveau/blob/hwref/drm/nouveau/include/nvkm/hwref/gk104/trim.h#L39
08:06karolherbst: yeah, that's P
08:06karolherbst: and nvidia uses mostly 1 and rarely 2
08:08karolherbst: RSpliet: yep, the gpu is pretty much useless with everything above 2
08:11karolherbst: RSpliet: k, even P=31 and M=1 doesn't work
08:11karolherbst: soo my conclusion is: P=1, always
08:12karolherbst: gpu crash at P=31, M=1 too
08:12karolherbst: it rendered like 10 lines
08:13karolherbst: RSpliet: I really want to know now, how the pll is configuired on the 750 ti card in nouveau :)
08:35heiko: can anyone help me with apitrace ? I have no outputfile
08:36karolherbst: heiko: how do you run it?
08:37heiko: wine apitrace trace -a d3d9 -v risen.exe
08:37karolherbst: I assume it is the windows version of apitrace?
08:37karolherbst: and wait, I also had an issue with risen and it went away after doing something
08:37karolherbst: ahhh right
08:38karolherbst: those moving grass thingies are causing issues
08:38karolherbst: there is an option for it
08:38heiko: linux apitrace works and make a output file but i can not replay it
08:38karolherbst: never used the windows apitrace inside wine
08:38heiko: I have intsall apitrace 64 and 32
08:41heiko: karolherbst do you know the moving gras problem ?
08:41karolherbst: yeah I had it too
08:41karolherbst: ohhh right
08:42karolherbst: it is d3d8
08:43heiko: have you fixed it in mesa ?
08:43karolherbst: the thing is, risen is d3d8
08:48heiko: do you think this will not be fixed ?
08:48karolherbst: well I have no idea if it's an issue in wine or in nouveau or somewhere else, so
08:49heiko: do you think it's a wine problem ?
08:49heiko: the same problem is with intel graphics
08:50karolherbst: well the chances are high that it is a wine problem
08:50karolherbst: because it usually is
08:51heiko: ok than I make a bug report on the wine website
08:54heiko: wish a nice rest weekend
11:26karolherbst: prg: ping
11:26karolherbst: mhh did you get those lockups on my branch on highest pstate?
11:26karolherbst: I might found a possible issue
11:27prg: got those lockups without touching pstate
11:28karolherbst: Yoshimo: and you didn't had any issues so far?
11:40Yoshimo: karolherbst: just too much output on the terminal: https://pastee.org/zg5rh
11:40Yoshimo: but people told me that comes from my games
11:41Yoshimo: these mesa messages are a bit annoying
11:41karolherbst: as long as gthe gpu does not crash at highest clocks
11:41karolherbst: its good
11:42Yoshimo: and of course fps sucks on occasion, which is so far working as "intended"
11:43karolherbst: even at max clocks?
11:43karolherbst: well if it sucks like 50% nvidia, it's somehow "fine", below 30% is bad
11:43karolherbst: but you should be able to reach 70% sometimes
11:44Yoshimo: ah second, i didn't manually change stuff with the magic echo yet
11:47Yoshimo: where is the switch in 4.4?
11:48karolherbst: when you are on my branch
11:49prg: find /sys -name pstate when in doubt
12:05Yoshimo: so there are 3 pstate files in my /sys/kernel/debug/dri folder in the folders 0,64 and 128, but they are all 0 bytes and empty
12:05karolherbst: cat them
12:07Yoshimo: no suitable device found
12:07karolherbst: ohhhh odd
12:07karolherbst: ohh wait
12:08karolherbst: you were the one with maxwell2 right?
12:08Yoshimo: indeed, still am
12:08karolherbst: I should take notes
12:08Yoshimo: you knew it a couple of hours ago :)
12:10Yoshimo: can we do something usefull before nvidia gets their firmware issue sorted?
12:11karolherbst: jayhost`: !
12:11karolherbst: Yoshimo: for the pmu?, not really
12:11Yoshimo: for nouveau with maxwell2
12:11karolherbst: well you could install htose graph firmware files and all the others and get acceleration
12:12karolherbst: but no memory reclocking yet
12:12Yoshimo: and i begin to doubt that the text errors are from the games, there are too many games causing this spam
12:13karolherbst: well it comes from mesa
12:13karolherbst: but more because they do some not so valid stuff
12:13karolherbst: this happens
12:14Yoshimo: maybe wine messes up the conversion?
12:14karolherbst: it could
12:15Yoshimo: so nothing to test , nothing to check without pmu? oh well i feel useless
12:16karolherbst: so you get nouveau in glxinfo?
12:19martm: MichaelLong: as mentioned, the scheduler is only a little complex due to that the board has caching protocols for variety of things which go through vram to that controller, so
12:20martm: you imagine fetch stage , when you wanna mask memory instructions all, it's not entirely straightforward, cause some of the addresses may be cached
12:20Yoshimo: no idea what that huge table at the bottom is about
12:21martm: so we'd need to know what addresses are in cache, cause when they are in regs, they can utilise the whole warp
12:29martm: so when one wants to do the scheduler nearly perfectly, the cache needs to be accounted with too, othwerwise it could be turned off completly and the scheduler would be by some margin easier to hide the latency, but with corresondence with cache, it's gonna take some additional effort to get it trimmed perfect
12:33martm: for instance a fetch stage plays with instruction cache..where some of the information of the shaders instructions could be in cache to start with
12:41martm: however this is perfectly doable too with cache, no promises there i can see how this could be done though
12:49martm: i was said, i should not give so many promises, but it should not be something one should be highly worried about to skip doing what one likes--- as the method primitive and it is definitely when you can think you can see it has to work
12:50mupuf: karolherbst: hey, does the wiki work now?
12:50mupuf: RSpliet: same question for you!
12:54karolherbst: the nouveau one?
12:57karolherbst: mupuf: can you explain to me, why the P parameter of the gpc pll can cause issues?
12:57karolherbst: the gpu behaves really unstable when P is higher than 2
12:58martm: anyways got to run...i don't really give a fuck of this synchronized dance around me, how you ignore me and and how i was diagnosed real people will understand how is who, and filter all the abortion leftovers out anyways, when the pressure arrives all the aces will do things anyways
13:00mupuf: karolherbst: yeah, not the first time I hear this story :s
13:00karolherbst: P=3 was especially odd
13:00mupuf: well, I cannot make any sense with the p divider would make the PLL unstable
13:01karolherbst: output clock: 850MHz, 40 fps glxspheres :O
13:01mupuf: maybe what it means is that the rest of the PLL would need to be clocked at a frequency too high
13:01karolherbst: yeah maybe
13:01karolherbst: but I tried something out
13:01karolherbst: set M to 1 and P to the usually high number
13:01karolherbst: like 31
13:01karolherbst: nouveau draw 10 lines...
13:01karolherbst: then it crashed the gpu
13:03karolherbst: mupuf: so you would say something like that might make sense to do in the end then: https://github.com/karolherbst/nouveau/commit/8c13215cdec9f366cc60bcd896660131f6343700
13:04karolherbst: I set M to 31, because the blob does it
13:04karolherbst: and it only adjust N
13:04karolherbst: sometimes (like 5% of all times) it sets P=2, M=31
13:04karolherbst: and then we got the usual cstep step size :)
13:05karolherbst: and explains why the clocks are on spot with M=31 usually
13:05mupuf: karolherbst: hmm, well, it does not sound too crazy
13:05mupuf: we should really copy what it does
13:06karolherbst: I am just curious why we can't rely on the PLL values in the vbios then
13:06mupuf: karolherbst: yeah... as I said, not the first time...
13:12karolherbst: now I just have to test if nouveau really set something odd for the PLL on some cards, but maybe I could try to check that myself here
13:41jayhost`: karolherbst did you call
13:42karolherbst: ya, did you run your gpu at highest clock for some time?
13:44jayhost`: Yeah yesterday. I wasn't running anything gpu intensive
13:44karolherbst: mhh okay
13:45karolherbst: okay, so normal usage is stable enough then
13:46jayhost`: Yeah I had done those glmark tests and such before. Only time crash is on Screensaver which I don't think is related
13:46karolherbst: RSpliet: will you find some time checking on the ti gpu agian for me tomorrow? I really want to verify this PLL theory
13:46karolherbst: jayhost`: mhh what was the error?
13:49jayhost`: I didn't get to log it. It was an issue I had without reclocking but very infrequently
13:49karolherbst: ahh okay
14:02RSpliet: karolherbst: checking what? is there something that's not obvious from the trace?
14:02karolherbst: was it a nvidia or nouveau trace?
14:02RSpliet: nouveau you can derive from the code
14:02RSpliet: so tracing that is a bit silly ;-)
14:03karolherbst: not really
14:03karolherbst: well I could try, but it is a bit akward
14:03karolherbst: k, nvidia sets the PLLs exactly as I would expect it
14:36karolherbst: RSpliet: that's odd. nouveau should configure the pll in a good way already (it does already by accident), so something else should be funky
15:01RSpliet: how do the coefficients correspond?
15:01RSpliet: oh hmm, I'll boot it a bit later and try to fetch you those coefficients
15:10karolherbst: RSpliet: well, the clocks in the vbios usually fit in this: clock = 810MHz * N / 31
15:10karolherbst: that*s why nouveau chooses M=31, P=1 most of the time
15:11karolherbst: RSpliet: if my application is right, nouveau should choose N=81, fN=61440, M=31, P=1
15:12karolherbst: no idea where fN is saved though
15:45karolherbst: mupuf: plasma5 on wayland works greate with 5.5.95 :)
16:04jayhost`: karolherbst had you wanted me to leave gpu intensive app open for hours?
16:06karolherbst: not really
16:10karolherbst: just normal usage
16:21airlied: skeggsb: dude -next :P