01:21 gnurou: looging off IRC until end of next week (holidays), if there are questions please direct them to Github in the meantime! :)
01:21 gnurou: s/looging/logging
01:22 imirkin_: gnurou: have fun!
02:49 imirkin: karolherbst: asleep?
02:49 karolherbst: no yet
02:50 imirkin: i have a potential fix for the tomb raider issues
02:50 imirkin: feel like testing?
02:50 imirkin: karolherbst: http://hastebin.com/ewufesekab.coffee -- entirely untested thus far. but it compiles :)
02:50 mgoodwin: Seems to only crash now when I idle
02:51 mgoodwin: Every morning I wake up and it's frozen
02:51 karolherbst: imirkin: this is for the fog missrendering, which might also fix the other issue, right?
02:52 imirkin: karolherbst: well, it's for the glLinkProgram failures
02:52 imirkin: which are probably not good in all sorts of scenarios :)
02:52 karolherbst: :D
02:52 karolherbst: k
02:52 karolherbst: will test it then
02:53 mgoodwin: So would you say a valid purpose of stress testing a game is to elucidate other issues?
02:53 mgoodwin: You're saying that what you just potentially fixed could cause other issues elsewhere correct?
02:53 mgoodwin: (not related to a game?)
02:54 imirkin: karolherbst: oooops
02:54 imirkin: missing a very important piece. hold on
02:54 imirkin: (just tested - didn't work)
02:54 karolherbst: imirkin: yeah well
02:54 karolherbst: "16323: message: major shader compiler error 2: 0:13(1): error: syntax error, unexpected NEW_IDENTIFIER, expecting $end" :D
02:55 imirkin: whaaaa... that's in the parser. seems unrelated.
02:55 karolherbst: ahh you mean this one "16326: warning: error: Too many fragment shader default uniform block components"
02:55 imirkin: yes. i mean that one.
02:56 karolherbst: mgoodwin: ahh maybe putting the display to sleep messes it up
02:57 karolherbst: mgoodwin: well, chances are, that if something is broken in one application, there is another application triggering the same issue
02:57 mgoodwin: Well, I know it can even on Linux and Windows drivers
02:57 imirkin: karolherbst: hm. it still appears to be b0rked. debugging...
02:57 mgoodwin: But the thing is, I literally removed pin 14
02:57 mgoodwin: So It has no idea when that happens
02:57 mgoodwin: (it's hooked up HDMI to a TV)
02:57 karolherbst: well blocking pins is usually not a good idea, except you _know_ what you do
02:58 mgoodwin: I have it hooked through a receiver so when I turn the TV off it adjusts the resolution to the receiver EDID
02:59 mgoodwin: Removing the signaling pin that does that fixed the problem
02:59 karolherbst: yeah well
02:59 karolherbst: as I said: it is not a good idea, except you really really _know_ what you do
03:00 karolherbst: but pin 14 does something else
03:01 karolherbst: just saying
03:02 mgoodwin: lol just crashed after 8 hours or so
03:02 mgoodwin: I was just sitting there typing to you and it crashed
03:02 mgoodwin: BUT there's a culprit
03:02 karolherbst: at least
03:02 mgoodwin: I realized that earlier I didn't downclock after putting it in max mode
03:02 mgoodwin: and I got tired of the whirring, so i reclocked to 07 about 20 minutes ago
03:03 karolherbst: yeah and?
03:03 mgoodwin: And it probably has something to do with that low power state
03:03 mgoodwin: It hasn't been in that state since I started booting with pstate 10
03:03 karolherbst: well it might or not, but we don't know it
03:04 karolherbst: but usually the voltage requirenments are more important on lower clocks in general
03:04 karolherbst: but
03:04 mgoodwin: http://paste.fedoraproject.org/360919/14618990
03:04 karolherbst: I am like 99.9% sure that with my patches we at least volt to the right voltage
03:04 mgoodwin: I didn't remove the voltage offset
03:05 karolherbst: well I would say it is something else
03:05 mgoodwin: ah that didn't paste right
03:05 karolherbst: which might reduce the required voltage or something we just missed
03:05 mgoodwin: http://paste.fedoraproject.org/360920/89912814
03:05 karolherbst: huh
03:06 karolherbst: ZETA_STORAGE_TYPE_MISMATCH
03:06 karolherbst: I really need access to a gpu which does strange stuff
03:07 karolherbst: will be fun I guess
03:08 mgoodwin: 975000, 852447, -122553, 87.430462, 7, 0, 43
03:08 karolherbst: yeah well
03:08 karolherbst: you incresed the voltage
03:08 karolherbst: and usually this tool only helps if you run it alongside nvidia :)
03:08 mgoodwin: no you did :P
03:09 mgoodwin: Do I need to find out what voltage it runs at with nvidia?
03:09 karolherbst: I am sure it has nothing to do with reclocking though
03:09 mgoodwin: It's not like it's that hard to switch
03:09 karolherbst: mgoodwin: as I said, I am like 99.9% sure it has the right voltage set
03:10 karolherbst: well you can switch and try, but I doubt it will tell us anything
03:10 karolherbst: voltage isn't the issue here, because an absurd high voltage doesn't help
03:10 karolherbst: I think you cna remove the voltage parameter and it won't affect the stability at all
03:10 karolherbst: or maybe only a tiny bit
03:11 mgoodwin: screen still flickered when I echo'd pstate
03:11 mgoodwin: though it's otherwise unresponsive
03:11 imirkin: karolherbst: nevermind, i'm not going to solve this tonight
03:12 karolherbst: imirkin: do you add anything to uniform_ht
03:12 karolherbst: it is just something which cought my eye, that you don't
03:13 imirkin: karolherbst: no, i don't. that was the "ooops!" bit of it
03:13 karolherbst: :D
03:13 karolherbst: k
03:13 imirkin: karolherbst: but... the issue is that the ir_constant isn't as constant as i had hoped
03:13 imirkin: you can see the comment i made on the bug
03:13 karolherbst: do you hash by value?
03:13 imirkin: but basically the thing makes N instances of the thing
03:14 imirkin: yeah, hashing the actual uniform's value would work.
03:14 imirkin: or rather, the constant's actual value
03:14 karolherbst: yeah, hashing by pointer is always ugly :)
03:14 imirkin: wellll... i thought it would just refer to the same constant every time
03:14 karolherbst: you need to be smart to hash my pointer ;)
03:14 karolherbst: right
03:15 karolherbst: I had a similar thing once too
03:15 imirkin: but it's a bunch of copies of that constant
03:15 mgoodwin: So are these dmesg outputs pretty useless then?
03:15 karolherbst: mgoodwin: maybe, maybe not
03:16 karolherbst: mgoodwin: it will be something really really obvious in the end, or some stupid little reg write/read we just missed the entire time
03:16 karolherbst: or maybe some stupid firmware issue
03:16 karolherbst: I don't think it is anything big
03:17 karolherbst: and the thing is, it only happens to some
03:17 mgoodwin: I've gone through what seems like 30+ of these freezes
03:17 mgoodwin: Trying very hard to figure a correlation and I can't
03:18 mgoodwin: The one reproducer is VDPAU but I have mesa-vdpau* removed
03:18 mgoodwin: so it can't even be touched
03:18 karolherbst: yeah, it will be something really stupid in the end, or maybe it is just a sync issue...
03:19 karolherbst: and maybe I should run something on my gpu for hours
03:19 imirkin: it's pretty easy to crash nouveau unfortunately. simply running piglit in parallel tends to cause my GPU's to hang.
03:19 karolherbst: but I didn't got such random hangs for a long time now
03:19 imirkin: these are separate applications which do a tiny bit of GL stuff, in separate processes.
03:19 karolherbst: ohh still not ifxed
03:19 imirkin: yeah, allegedly it's gotten better
03:19 karolherbst: mhh
03:19 karolherbst: I could check that
03:19 imirkin: but still not perfect
03:20 karolherbst: but I doubt I can help with that
03:20 mgoodwin: what sort of program does that
03:20 karolherbst: piglit is for conformance testing mesa
03:20 mgoodwin: I know kwin uses gl
03:20 imirkin: for testing GL, actually
03:21 karolherbst: well yeah, why not running piglit again
03:21 karolherbst: but I also have those "LB_ERROR"s
03:21 mgoodwin: Well I was just sitting there with firefox a konsole window and konversation
03:21 karolherbst: but it doesn't do much on my system
03:21 mgoodwin: and im trying to think what else would have touched GL
03:22 karolherbst: mgoodwin: every GL application
03:22 mgoodwin: firefox has hardware accell / omtc etc off
03:22 karolherbst: like Qt5
03:22 karolherbst: ...
03:22 karolherbst: :D
03:22 mgoodwin: Every Qt5 application uses opengl?
03:22 karolherbst: mgoodwin: cat /sys/kernel/debug/dri/0/clients
03:22 karolherbst: mgoodwin: kind of
03:22 mgoodwin: independently of the wm?
03:22 karolherbst: mgoodwin: well all Qml ones should be
03:23 karolherbst: mgoodwin: ya
03:23 karolherbst: mgoodwin: you can disbale it somewhat though
03:23 mgoodwin: o wow
03:23 karolherbst: well gtk3 should do it too
03:24 mgoodwin: Xorg, krunner, plasmashell, abrt-applet, konversation, qtox, kwin, unknown, konsole
03:24 karolherbst: Xorg makes sense
03:24 karolherbst: abrt-applet?
03:24 karolherbst: well those others are using the GPU directly (usually OpenGL)
03:24 mgoodwin: gtk3 crash catcher
03:25 karolherbst: ahh okay
03:25 karolherbst: imirkin: or does the clients file show something else?
03:25 mgoodwin: It's Fedora's way of getting stack traces
03:25 mgoodwin: for automatic bug submission
03:25 karolherbst: imirkin: should be open fds on the nouveau driver right?
03:25 karolherbst: mgoodwin: k
03:25 mgoodwin: this is while it's still borked btw
03:25 mgoodwin: I haven't recovered it
03:26 karolherbst: doesn't matter much
03:26 karolherbst: mgoodwin: well fancy Qt5 and GTK3 are using OpenGL to accelerate their 2d rendering stuff
03:27 karolherbst: so somewhat nouveau really has to improve that doing stuff in parallel thing, because it only gets worse
03:29 mgoodwin: Well I've about had enough
03:29 mgoodwin: I'll see you around when F24 stabilizes
03:30 mgoodwin: Unless you think there's any other information I can contribute or test
03:35 karolherbst: I can't think of anything
03:35 karolherbst: but maybe it is just stable for me, because I usually have only one application using my gpu :)
03:35 karolherbst: might explain it
03:37 karolherbst: yep :D
03:38 karolherbst: 32 glxspheres64 hanged my gpu
03:38 karolherbst: imirkin: k, I get hangs now :D
03:38 karolherbst: yay
03:39 karolherbst: mgoodwin: if you want you could try it too
03:39 karolherbst: mgoodwin: just start unvsynced glxgears until it hangs :D
03:40 mgoodwin: don't you mean two?
03:41 karolherbst: nope, I mean 32
03:41 mgoodwin: export vblank_mode=0 && ( glxgears & glxgears )
03:41 karolherbst: well
03:41 karolherbst: for i in {0..16}; do vblank_mode=1 DRI_PRIME=1 glxspheres64 & echo $i ; done
03:42 karolherbst: 1 is also un vsynced but different
03:42 karolherbst: no idea what is different though
03:42 mgoodwin: lol
03:42 mgoodwin: well me either!
03:42 karolherbst: those clients are dieing slow though
03:43 mgoodwin: the question is why did you choose 1 over 0
03:43 karolherbst: no clue
03:46 karolherbst: ohh
03:46 karolherbst: I found it
03:47 karolherbst: they define a max interval
03:48 mgoodwin: well
03:48 mgoodwin: I started 16
03:48 mgoodwin: and none of them have stopped (one did the first iteration, but I killalld)
03:49 mgoodwin: so i tried to take a screenshot because it looked neat
03:49 karolherbst: :D
03:49 mgoodwin: and plasmashell stopped responding once I searched for ksnapshot and clicked on it
03:49 mgoodwin: Once I got back to konsole with the task switcher
03:49 mgoodwin: i killalld again and it responded
03:50 mgoodwin: oh, now finally ksnapshot shows up with a glorious screenshot
03:52 mgoodwin: same thing with firefox
03:52 mgoodwin: didn't appear until I killed all of the glxgears
03:52 mgoodwin: still not frozen though
03:53 mgoodwin: Here's the thing firefox doesn't show up in clients...
03:54 mgoodwin: It's as if it's kwin/plasmashell not wanting to render the window
03:54 imirkin: are you using dri2 or dri3?
03:54 mgoodwin: because as soon as I killed glxgears it appeared, no loading
03:54 mgoodwin: dri2
03:54 mgoodwin: dri3 has horrible artifacts
03:55 mgoodwin: https://i.imgur.com/gKf8CvT.png
03:55 imirkin: does plasmashell show up in clients?
03:55 mgoodwin: wee fun
03:55 mgoodwin: yes
03:55 mgoodwin: http://paste.fedoraproject.org/360923/19021291
04:06 mgoodwin: whoops
04:06 mgoodwin: 30 at a time killed it instantly
04:06 karolherbst: :)
04:06 karolherbst: yeah
04:06 karolherbst: 16 was also kind of fine for me
04:07 karolherbst: but I guess it just takes more time
04:07 mgoodwin: http://paste.fedoraproject.org/360925/14619028
04:07 mgoodwin: lulz
04:07 karolherbst: yeah
04:08 karolherbst: but I would say context switching on the gpu has somewhere a race condition
04:08 karolherbst: or maybe it is even on the host side
04:08 karolherbst: and we don't lock right
04:09 karolherbst: well I will try to take a look and maybe I find something
04:10 mgoodwin: Don't forget im using grfw
04:11 mgoodwin: which I was told earlier deals with ctxsw
04:12 mgoodwin: 20 killed it instantly with: [ 80.562043] nouveau 0000:01:00.0: fifo: read fault at 0000011000 engine 07 [HOST0] client 06 [HOST] reason 0c [UNSUPPORTED_KIND] on channel 19 [023ecc5000 glxgears[2629]]
04:12 mgoodwin: only message
04:13 mgoodwin: I love how the errors are different each time
04:13 karolherbst: right
04:13 karolherbst: well maybe it is really inside the kernel moduol
04:14 karolherbst: *module
04:14 karolherbst: or even userspace
04:14 karolherbst: well
04:14 karolherbst: it should be the kernel then
04:14 mgoodwin: going for 19...
04:14 karolherbst: well
04:14 karolherbst: does it matter?
04:14 mgoodwin: yeah perhaps the number of client will elucidate something
04:15 mgoodwin: I don't know, just trying to test, it's what I do
04:15 karolherbst: well I will go to sleep now anyway
04:15 mgoodwin: 19 does not crash
04:16 mgoodwin: 27 clients total
04:18 mgoodwin: just started 19 5 times in a row with no crash (after killing them)
04:18 mgoodwin: 20 instant crash again
05:59 imirkin: pmoreau: i don't see an updated image...
06:00 imirkin: am i looking in the wrong place?
08:56 pmoreau: imirkin: You are looking at the correct place, it’s just that it failed to compile the lib part of Ben’s repo due to drm.h missing. I didn’t know it was compiling that part, even if we do not use it in the final image…
08:56 pmoreau: imirkin: I restarted a new build and removed that part. I checked that the module did compile correctly.
10:58 karolherbst: okay, I can confirm that many clients on the GPU hang the GPU real fast
11:50 pmoreau: imirkin: The image is live now
12:05 mupuf: pmoreau: what image are you talking about?
12:07 pmoreau: mupuf: https://nouveau.pmoreau.org/
13:21 mgoodwin: karolherbst: im not sure how significant but my testing of that last night seemed to prove there is a clear delineation between 'ok' and 'omfg crash'
13:22 mgoodwin: Seemed to be 27 -> 28 clients, which corresponded to 19 -> 20 glxgears running simultaneously
13:22 mgoodwin: 20 would crash immediately, 19 would run no problem. Clock speed didn't matter, oddly.
13:25 mupuf: pmoreau: oh, I had forgotten about this
13:30 karolherbst: mupuf: did you got my message about the LED?
13:30 mupuf: karolherbst: oh, sorry, no
13:30 karolherbst: mupuf: there is an option to turn on the lights of the logo in nvidia-settings :)
13:31 mupuf: ok, saw them
13:31 mupuf: wonderful
13:31 mupuf: can't check it out tonight
13:31 karolherbst: yeah, it seems to be just an on off switch, but I think this will help us already :)
13:31 mupuf: maybe this weekend, but this is an insane weekend of partying throughout Finland
13:31 karolherbst: "Attribute 'GPULogoBrightness' (reator:0[gpu:0]): 100."
13:31 karolherbst: :D
13:32 mupuf: pq: any plans for vappu? :D
13:32 mupuf: or is it more a Helsinki thing?
13:32 karolherbst: mgoodwin: mhhh
13:33 karolherbst: mgoodwin: yeah maybe the current code can't handle that much and this is a totally different issue then
13:33 karolherbst: at least this is an issue I can trigger on my GPU
13:33 karolherbst: mgoodwin: so you say 27 clients are fine and 28 is instant hang?
13:33 mgoodwin: correct I tested it 5 times each
13:33 karolherbst: let me chck
13:34 mgoodwin: But more specifically I'm saying 19 glxgears vs 20
13:34 mgoodwin: because I can't say how much the other 6 clients made
13:34 mgoodwin: difference*
13:34 karolherbst: yeah, but on my system nouveau doesn't have any clients usually
13:34 karolherbst: 27 was fine here
13:35 karolherbst: with 28 I get really heavy prime tearing
13:35 mgoodwin: Oh being on nvidia now I checked the voltage and it's currently the lowest before we adjusted it and still stable
13:35 karolherbst: and 29 is too much
13:35 karolherbst: mgoodwin: right
13:36 karolherbst: mgoodwin: with my patches nouveau doesn't volt below nvidia anymore (with really high confidence)
13:36 pq: mupuf, not personally, but in Lappeenranta university, vappu has lasted for 2 weeks already :-)
13:36 karolherbst: okay, 29 clients are too much mhhh
13:36 mupuf: pq: ok, so it is more insane than Helsinki then. They probably only started on monday
13:37 karolherbst: CHSW_ERROR, that's new
13:37 mgoodwin: Strongly considering Ilia's advice, maybe just going to burn an old gift card toward an amd card
13:39 mupuf: pq: hey, I am having a look at how to start weston from an ssh connection. I have sudo rights, but this is not enough to start weston on a specific vt. Is there any recommended way? I saw the thread on phabricator to come up with a systemd unit, is that the only way?
13:39 mupuf: https://phabricator.freedesktop.org/T63
13:40 pq: mupuf, starting via remote is something I've never done. You probably need to be root, and pass the VT as an argument.
13:41 pq: I don't know how that works if you use logind
13:41 mupuf: well, it the answer is, it does not :p
13:41 mupuf: but ok, I will just keep on having a look
13:42 mupuf:started writing python code to talk to logind directly
13:42 mupuf: I am supposedly not supposed to talk to create sessions myself as it is PAM's job, but I don't see why I would have to go through PAM to get a new session
13:43 mupuf: I guess this is something I would need to discuss with david hermann
13:51 pq: mupuf, yeah. Also having a local login with the same user might help. Or not. *shrug* You also have the choice to use or not use weston-launch, and the user and tty options of it.
13:52 mupuf: yeah, I tried that too but it did not work
13:52 mupuf: I may have another go at it though
13:52 pq: mupuf, do you actually need weston to touch the DRM display devices, or are you only interested in rendering that could as well be done headless?
13:53 mupuf: no, I cannot run it headless
13:53 mupuf: it is for benchmarking performance
13:53 pq: yes, you cannot, but would it help?
13:54 mupuf: not really no, why do you ask?
13:54 pq: hmm, what are you benchmarking, considering that weston is always throttled to the vblank?
13:54 mupuf: hmm, not if you run benchmarks with vblank_mode=0
13:54 pq: becuase I have this plan to allow running weston/wayland under weston/headless, to be able to test the GL-renderer of it.
13:54 mupuf: sounds fun :)
13:54 pq: mupuf, ok, so what do you need the display for?
13:55 mupuf: because the display is also consuming memory bandwidth
13:55 pq: aaah.
13:55 mupuf: and I would like to be as close as possible as to what the user is seeing in practice
13:55 pq: okay, cool
13:55 mupuf: but headless can be another mode though
13:56 mupuf: I already have a way to tell X to use the intel or modesetting ddx, then which compositor should be ran
13:56 mupuf: this allows for testing the performance on multiple compositors and comparing then
13:56 mupuf: them*
13:56 mupuf: wayland compositors are next :p
13:56 pq: nice
13:57 mupuf: and I was planning to use weston for benchmarking nouveau on the jetson tk1
13:57 mupuf: (since X does not run on X)
13:58 mupuf: oh, right, xwayland is also something I want to benchmark, because this is the future, right? :)
14:00 pq: sure
15:07 imirkin: pmoreau: excellent, thanks
15:30 mupuf: karolherbst: steam -applaunch 730 +cl_showfps 1 +timedemoquit pts5 -novid +con_logfile /tmp/csgo_log -fullscreen --> you get the average fps in the logs
15:31 mupuf: this is csgo
15:31 mupuf: so, ezbench support soon I gues
15:32 mupuf: but ... one problem is that the games may be 32 or 64 bits
15:32 mupuf: so, no idea which version of mesa I need to compile
15:33 karolherbst: mhh
15:34 karolherbst: mupuf: will it be 64bit on 64bit platforms?
15:34 mupuf: not always
15:34 mupuf: some games are 32 bits
15:35 Tom^: ive yet to see an actual 64bit game on steam
15:35 Tom^: so if you ask me its 9 times out of 10 32bit
15:36 imirkin_: Tom^: dota2 relaunch thing was 64-bit
15:36 mupuf: yep
15:36 mupuf: that\s the only one I am aware of
15:38 Tom^: imirkin_: but does it have a 32bit client?
15:38 imirkin_: don't think so
15:38 Tom^: :/ that sucks, otherwise it would be easier to simply stick to 32bit
15:39 Tom^: but oh well if things werent hard sometimes you wont appriciate the times when its easy.
15:39 mgoodwin: Is it in my mind that nouveau+mesa is faster at 2D desktop operations
15:39 mgoodwin: Every time I go back to nvidia the desktop feels slower
15:39 Tom^: nvidia has had its past of being slower yes
15:40 Tom^: with various tweaks to improve it
15:42 Tom^: mgoodwin: from a very old logfile i have this improved things like uh 8 years ago nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1
15:42 Tom^: i dont recall why or how but
15:49 mgoodwin: https://techbase.kde.org/User:Lemma/KDE4-NVIDIA
15:50 imirkin_: mgoodwin: i've heard that in the past too, although i don't remember noticing it myself
15:50 imirkin_: mgoodwin: what i *have* noticed is that fonts look inexplicably different
15:51 imirkin_: [and i happen to prefer to nouveau look, but that's pretty subjective]
15:51 imirkin_: i think they must do some extra antialiasing on them... or something
15:51 mgoodwin: Yeah I haven't been ably to quantify, but despite the contradictory obviousness of nouveau having less performance capabilities, the desktop feels 'snappier'
15:51 mgoodwin: Im aware of how vague that is
15:52 imirkin_: it was definitely true in the olden days
15:52 imirkin_: but nvidia has since then cleaned up their act considerably
16:04 karolherbst: Tom^: I have some games which have 32bit and 64bit binaries
16:04 Tom^: karolherbst: but does steam let you choose 64bit?
16:04 karolherbst: Tom^: no
16:05 Tom^: :p
16:05 karolherbst: Tom^: launcher shell scripts check for 64bit
16:08 mupuf: well, well, I guess one way to address the issue would be for me to compile both the 32 bits and the 64 bit version :s
16:12 karolherbst: mupuf: or mark it in the benchmarks (needs_32bit_onf_64bit)
16:12 mupuf: karolherbst: well, I guess I could do this yeah
16:13 mupuf: and, when compiling, I would check which benchmarks are going to be run
16:13 mupuf: well, I guess the deployment function will also need to be adjusted
16:13 mupuf: sounds like fun!
16:13 karolherbst: mupuf: ohh I have a hacky hack :D you check withing env_dump and you preload both 32bit and 64bit (one will fail) and within env_dump you block, trigger the compile and adjust LD_LIBRARY_PATHat runtime :) :D
16:14 karolherbst: though I really doubt that will work
16:14 mupuf: eww, sounds like a lot of work :D
16:24 Tom^: meh compiling mesa goes kinda fast if you strip out the unnecessery bits
16:25 Tom^: or well the bits that doesnt apply for your card :P
17:00 RSpliet: hakzsam: do some NVIDIA GPUs have i-cache miss counters?
17:07 hakzsam: RSpliet, I have never seen such counters, but if you want you can have a look here https://github.com/hakzsam/re-pcounter-tools/tree/master/docs/hw/pcounter
17:07 hakzsam: there is a list of perf counters
17:08 RSpliet: hakzsam: thanks. To be fair I'm not even entirely sure whether these GPUs have separate I- and D-L1's
17:08 hakzsam: maybe you will find something useful for you :)
17:09 hakzsam: yeah, I don't think too
17:11 karolherbst: hakzsam: how well do you know the context switching stuff in nouveau?
17:11 karolherbst: ohh wait
17:11 karolherbst: I thought you were mwk...
17:11 RSpliet: karolherbst: what do you want to know?
17:12 karolherbst: RSpliet: well. any reasons why 28 clients are okay but with 29 I get an immediaty GPU hang?
17:12 karolherbst: *immediatly
17:13 RSpliet: heh, well, all I know is that it's unlikely to be related to the firmware :-P
17:15 karolherbst: right
17:15 karolherbst: I tried to look into the engine/gr code, but well :/
17:16 RSpliet: yeah, it's not very simple code :-P
17:16 pmoreau: karolherbst: Last time I tried multiple glxgears in parallel, the laptop locked up on the 17th one IIRC.
17:17 karolherbst: pmoreau: yeah, but your desktop run on the same gpu, right?
17:17 pmoreau: Right
17:17 pmoreau: I haven’t tried with DRI_PRIME
17:17 karolherbst: so I think it was 29 for me, let me check
17:17 karolherbst: no
17:17 karolherbst: it was 27
17:18 karolherbst: no.. it was 29 :D
17:18 hakzsam: karolherbst, hey no, I'm not mwk :)
17:18 karolherbst: well I think fixing this might fix also some random hangs, most likely not, but it is a good diea to fix it
17:19 karolherbst: hakzsam: yeah, I wasn't thinking :) but I guess you don't know much about the gr stuff?
17:19 RSpliet: karolherbst: I have a theory about random hangs in the fw that I intended to investigate further
17:19 hakzsam: karolherbst, and I don't really know the context switching, some basic understanding though
17:19 karolherbst: RSpliet: right, seems like plasma5 triggers those real fast
17:19 hakzsam: anyway, time to leave, see you later guys
17:19 karolherbst: :)
17:20 RSpliet: where, if an interrupt arrives at the HUB while processing a context switch, it might go to sleep despite there being a command in the fifo
17:20 karolherbst: :D
17:20 karolherbst: let me show you something
17:20 RSpliet: but: I have yet to find out whether interrupts can actually occur during a ctx switch
17:21 karolherbst: RSpliet: did you notice this little fix on the PMU?https://github.com/karolherbst/nouveau/commit/b2274a3a71513836ad31405ef954cda3438c61d7#diff-2848d00b3f83a34d965195fafbb5461f
17:21 RSpliet: no
17:21 karolherbst: it triggered only like in 0.01% of allinterrupts from the host, but it triggered
17:22 karolherbst: and the PMU was ackinghosts interrupts
17:22 karolherbst: before they got handled
17:22 karolherbst: and then the PMU wasn't processing those interrupts anymore :)
17:26 RSpliet: karolherbst: https://github.com/RSpliet/kernel-nouveau-nv50-pm/blob/master/drivers/gpu/drm/nouveau/nvkm/engine/gr/fuc/hub.fuc#L223
17:26 RSpliet: notice how that bset does not take into account the status of the queue
17:26 karolherbst: :)
17:26 karolherbst: yeah
17:26 karolherbst: looks dangerous
17:27 RSpliet: skeggsb was convinced it's fine, but couldn't recall his motivation
17:27 karolherbst: https://github.com/RSpliet/kernel-nouveau-nv50-pm/blob/master/drivers/gpu/drm/nouveau/nvkm/engine/gr/fuc/hub.fuc#L382
17:27 karolherbst: this is most likely not right
17:28 karolherbst: but I don't know much about the falcon internals
17:28 karolherbst: so I amnot sure
17:28 karolherbst: but at first this doesn't look right
17:28 RSpliet: no that's fine
17:28 karolherbst: why?
17:29 RSpliet: because the flags are stored during entry as well?
17:29 RSpliet: brb
17:30 karolherbst: well I don't see why the flags needs to be saved and restored to the same value later
17:30 karolherbst: and I don't know if $flags can changed while inside ir
17:55 karolherbst: mhh, running 27 instances of glxspheres at once seems kind of stable :/
18:18 karolherbst: RSpliet: maybe it is in the end some stupid Xorg, Mesa and Display related interaction thing :/ I really doesn't seem to be able to hang my GPU by normal means
18:18 karolherbst: or at least not so fast
19:15 dcomp: lllll
19:40 RSpliet: karolherbst: you don't want flags to change between a test and a conditional branch, hence the interrupt handler must save/restore flags
19:40 karolherbst: ahh okay
19:40 karolherbst: right
19:44 karolherbst: RSpliet: at least the hang with 29 clients also happens with the nvidia firmware
19:55 RSpliet: karolherbst: glad you determined that definitely, although it wouldn't've been my first place to search
19:55 karolherbst: yeah
19:55 karolherbst: well one thing bothered me the entire time. There are two things different by a significant amount in nvatiming
19:55 karolherbst: but it shouldn't matter in this situation anyway
19:56 karolherbst: or maybe it does, who knows
19:56 karolherbst: GPC clocks on nouveau: 108MHz, nvidia: 221MHz any idea what that might be related to?
19:57 karolherbst: though I am not even sure if that's the right thing anyway
19:57 karolherbst: because the PART entries show me the "real" GPC clock
19:57 karolherbst: anyway: PGRAPH.CTXCTL 540MHz, nvidia: 102MHz
19:57 karolherbst: this is something I would like to change and see what affects this
19:58 karolherbst: (PGRAPH.TP[0].CTXCTL is 45MHz/33MHz too)