09:22pecisk: just for info - testested GTX 850M, Xonotic runs well, but misses quite a lot of textures there and here
10:00cedra: hello. just went from nvidia-libgl to nouveau, and now all forms of video are broken
10:01cedra: Computer lags a bit, i.e cursor movement slows down for maybe a second, and then the video is either black or just a picture of the first frame
10:01cedra: I can still hear the video which is why I'm pretty sure it's the nouveau driver
10:03cedra: I have a Nvidia GeForce GTX 660
10:53mupuf: cedra: hey
10:53mupuf: can we see the kernel logs please?
10:53mupuf: and xorg logs
10:54mupuf: pretty sure nouveau is not running :(
10:58cedra: I've tested some stuff and apparently webms and mp4s do load, as well as other video formats
10:58cedra: just not in my browser, apparently. which is incredibly weird.
11:00mupuf: cedra: ok, but let's first make sure you are running nouveau
11:00cedra: which kernel log do you mean
11:01mupuf: output of dmesg
11:01mupuf: put that on pastebin
11:01mupuf: then, the content of /var/log/Xorg.0
11:02cedra: here's my kernel log http://pastebin.com/adHyeNEb
11:03cedra: http://pastebin.com/mNfZ4Gq0 xorg
11:05cedra: it does look like it's running from what I can see
11:05mupuf: so, xorg says it uses the nvidia driver
11:05mupuf: but nouveau is the loaded driver in the kernel
11:06cedra: oh so it was the xorg.
11:06mupuf: so ... either now the blob can run on nouveau drm ... or you are not showing me the right xorg log
11:06cedra: That's the output of dmesg and /var/log/Xorg.0.log
11:07cedra: I do have a Xorg.1.log and Xorg.2.log
11:07cedra: don't know if those are related
11:07mupuf: echo $DISPLAY in your terminal
11:07cedra: that's :0
11:08cedra: so it's just xorg having the wrong settings?
11:09mupuf: well, how about you first get rid of all references to nvidia?
11:09mupuf: follow your distro's documentation though
11:11cedra: hm. alright
12:01cedra: mupuf: it was the wrong log file, I'm starting X with startx so it's the other path
12:01cedra: which I checked, and everything loads just fine, nouveau loads and there are no traces of nvidia
12:03cedra: feels like it comes down to my graphics card + the nouveau driver combo is not wanting to load HTML5 stuff
12:17fishxz: hey, what is the difference between this two
12:17fishxz: 0e: core 405-1267 MHz memory 6008 MHz
12:17fishxz: 0f: core 405-1267 MHz memory 6008 MHz
13:42Yoshimo: any clue what Error: couldn't find RGB GLX visual or fbconfig is about?
13:46karolherbst: mupuf: okay, so my mmiotrace fix will most likely be also applied for 4.5 and 4.4 kernels :) Makes it easier for user
13:47karolherbst: Yoshimo: depends
13:47karolherbst: Yoshimo: where you get that?
13:47Yoshimo: wine says my card is not directx9 compatible instead
13:47mupuf: karolherbst: yeepee!
13:47karolherbst: LIBGL_DEBUG=verbose glxinfo
13:48mupuf: karolherbst: are you using systemd or not?
13:48karolherbst: mupuf: yeah I also asked for 4.1, but then Ingo asked me if anything else is needed and I wasn't feeling well enough anymore to also apply it to 4.1 :D
13:48karolherbst: mupuf: yeah I do
13:48mupuf:is trying to use logind
13:48karolherbst: ahh I see
13:48mupuf: that would allow me to run wayland compositors
13:48karolherbst: logind is the replacement for consolekit kind of
13:48mupuf: and drop the root requirement for X
13:48karolherbst: mupuf: nope
13:49karolherbst: ohh mhh
13:49karolherbst: well you should be able to run X as non root even without it
13:49karolherbst: mupuf: only kwin requires logind, but only for logins
13:49karolherbst: mupuf: session management is what logind does
13:49mupuf: try connecting to a machine through ssh
13:49mupuf: and start an X server ;)
13:49karolherbst: yeah I know
13:49mupuf: on a vt
13:49karolherbst: yeah but it isn't that hard
13:50karolherbst: you can just give user permissions to the tty files
13:50karolherbst: then it works too
13:50mupuf: really? have you tried?
13:50mupuf: you just need to add your user to the tty group?
13:50karolherbst: even without systemd
13:50karolherbst: I can check on my other machine again
13:51karolherbst: but I am sure it worked thre
13:51karolherbst: let me try again
13:51karolherbst: and my other machine runs openrc and not systemd
13:51karolherbst: yep, works
13:52mupuf: well, even run as root,I never managed to start weston from ssh
13:52karolherbst: well the X server started...
13:52karolherbst: mupuf: well it could be that you also have to add you to the input group or anyhting
13:53karolherbst: for rootless X
13:53mupuf: as I said, even as root, I can't
13:53karolherbst: mupuf: well the reason you need logind for rootless X is, that the login manager usually is the bigger problem
13:53karolherbst: and security
13:53karolherbst: okay, now the weston problem
13:54mupuf: that does not seem like a bad idea for me
13:54karolherbst: mhh I think this is expected
13:54mupuf: not running X or any wayland compositor as root
13:54mupuf: yes, it is expected
13:54karolherbst: gsoc project: "The Wayland project's sole accepted project is the ability to allow Weston to start without any outputs present and also to still run when all outputs are disconnected. "
13:54mupuf: yeah, saw that
13:54karolherbst: I never tried to run it via ssh
13:55mupuf: and got emails from google yesterday telling that we got the two students we asked for
13:55karolherbst: let me install the stuff
13:55mupuf: ok, going to have my sauna
13:55karolherbst: ahh I see
13:55mupuf: see you in a bit!
13:55karolherbst: mhh I see a headless USE flag on weston
13:58mupuf: I need to start weston on the jetson tk1 to be able to run glxinfo :D
13:58mupuf: or I would need to write a gbminfo program :p
13:58mupuf: but in the end, I want to be able to run wayland compositors
13:58mupuf: and do so without root access, so, using logind does not sound too crazy
13:58karolherbst: yeah I will play around with that a bit. there are some interessting USE flags
13:59karolherbst: rdg ... screen-sharing .. headless :D
13:59mupuf: and I can keep using glxinfo, since it works also on proprietary drivers
13:59mupuf: ok, see you in an hour
14:14karolherbst: mupuf: holy ... with furmark: 77.12W :O
14:15yoshimo: karolherbst: LIBGL_DEBUG=verbose glxinfo doesn't change the output
14:15karolherbst: yoshimo: check your X log then
14:15karolherbst: mupuf: 78.98W even ...
14:16yoshimo: what should i check for?
14:18yoshimo: glamor init failed and swrast can't be loaded, but swrast is a known thing
14:18karolherbst: yeah, without glamor no opengl
14:21cedra: anyone else experiencing screen flimmering sometimes
14:21karolherbst: cedra: what kind of flimmering?
14:22cedra: sort of like. turqoise flimmering, gets faster when typing in IRC and stuff
14:22karolherbst: cedra: vsync enabled?
14:22yoshimo: https://pastee.org/fyzr5 , why could glamor fail to load?
14:23cedra: don't think I have vsync on, I do have Compton though
14:23karolherbst: yoshimo: no idea, it doesn't tell us
14:23karolherbst: cedra: maybe it is better with vsync enabled, but it shouldn't flimmer though :/
14:23yoshimo: so how would i solve that ?
14:24cedra: yeah it's a bit weird. it's not like screen tearing, it's like full on applications disappearing and being replaced by a light blue color and then back again in the span of like 0.5 seconds
14:32karolherbst: yoshimo: can't think of anything :/
14:38yoshimo: searching the net with the error wasn't helpful so far
14:43karolherbst: yoshimo: well the only thing I can thing is to try out weston, because it uses mesa and makes it a bit easier to debug
14:43karolherbst: yoshimo: but maybe you can make glamor more verbose or something
14:48pecisk: karolherbst: just for info - testested GTX 850M, Xonotic runs well, but misses quite a lot of textures there and here
14:49karolherbst: pecisk: maybe you need a more recent mesa for this then
15:00pecisk: karolherbst: Fedora 24, Mesa 11.2
15:00pecisk: but yeah, most likely
15:00pecisk: just wanted to say that it works :)
15:00pecisk: it didn't in Fedora 23
15:04karolherbst: maxwell support wasn't the best up until recent mesa versions
15:04karolherbst: with mesa-12 it should be better in the end
15:10pecisk: nice :)
15:11pecisk: good work, thanks
16:06karolherbst: mupuf: you are right, running those stuff on a seperated X server makes sense :) but it would be nice to be able to support a setup with multiple GPUs, so that you can test on one, but still have an active X session on the other one
16:07mupuf: ah ah, well, it is already supported :D
16:07karolherbst: ahh good
16:07mupuf: you are free to specify a xorg.conf
16:07karolherbst: anyway, I was fed up using DRI_PRIME
16:07karolherbst: because I hit space a lot
16:07karolherbst: and that disables the main thing in those gputest benchmarks
16:07karolherbst: and well the fps is then garbage
16:08mupuf: oh, but I wonder if I plugged it to ./ezbench
16:08mupuf: ./core.sh takes -c arguments
16:09karolherbst: DISPLAY=:1 always works :D
16:10mupuf: ah, right ;D
16:10mupuf: But you really want to let ezbench ddeploy your environment
16:10mupuf: so as, when you test the kernel, it can take care of everything
16:11karolherbst: I know
16:12karolherbst: those gputest things also load opencl...
16:13eclipticon: HI, I am using nouveau on Ubuntu Gnome 16.04 on a 3440x1440 screen - generally, 2D performance is not so great and the mouse cursor is leaving traces all over the screen. Anything I can do about that?
16:13karolherbst: mupuf: but furmark is really insane :/ above 78W and 92°C
16:14karolherbst: mupuf: and I am sure my power budgets are at 80W
16:14mupuf: karolherbst: check out confs.d/x11_ddx/modesetting
16:16mupuf: so, what you want to do is this: set the PCIID of your nvidia gpu
16:16mupuf: so as it will use this gpu to run
16:16mupuf: not sure how it will like being headless though :s
16:16karolherbst: yeah I know
16:16karolherbst: it needs -sharevts and stuff :/
16:16karolherbst: and no input devices
16:17karolherbst: there could be a headless mode for this maybe
16:17mupuf: so far, no success with logind, but there is still hope
16:17mupuf: nope, just creating the session already fails
16:17karolherbst: ahh right, from ssh
16:17mupuf: see you in a bit
16:17mupuf: well, I run it from another session
16:17mupuf: maybe it would work better on the jetson
16:18mupuf: anyway, groceries time
16:18mupuf: see you
16:22karolherbst: holy crap, 101°C
16:24karolherbst: and that is with boost 1
16:27Yoshimo: what was the critical one?
16:27karolherbst: or do you mean really critical?
16:27karolherbst: that is like 104 or 105
16:28karolherbst: and fans are at maximum already...
16:28karolherbst: I thought my fans would at least be able to cool down 70W
16:28Yoshimo: i meant the really really critical one yes
16:29karolherbst: something around 105
16:29karolherbst: but the gpu kind of shuts down automtically
16:52karolherbst: mupuf: currently collectin temperature and power consumption via ksysguard :)
17:00mupuf: oh, right, I need to finish my patches for ezbench
17:01karolherbst: not even boost 1 is safe on my gpu and gputest :/
17:02karolherbst: mupuf: I asked the ksysguard author for a custom nouveu Tab :)
17:03karolherbst: mupuf: but the power readout is frigin stable :O
17:06karolherbst: time between each pixel: 0.5seconds
17:08karolherbst: tess_x16 is insane
17:08mooch3: hey, i was wondering what hardware features nv40 lacks that keep it from supporting opengl 3.0?
17:08mooch3: i mean, geometry shaders aren't necessary for gl3
17:09karolherbst: mooch3: right, geometry is 3.2
17:09mooch3: yeah, that's why i'm confused
17:10karolherbst: mooch3: https://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt
17:10karolherbst: you could check what is missing on your from the 3.0 stuff
17:11karolherbst: mooch3: but in the end you can always force a 3.0 context and hope the application doesn't need anything yourc ard doesn't support
17:11mooch3: ARB_color_buffer_float is missing
17:11mooch3: or i could use llvmpipe :p
17:11karolherbst: the performance should be erally crappy
17:11mooch3: tho that would be rather slow on a k8
17:11karolherbst: MESA_GL_VERSION_OVERRIDE=3.0 MESA_GLSL_VERSION_OVERRIDE=130
17:11karolherbst: that's what you could try
17:12karolherbst: and if it crashes you could try to find out what it needs
17:12karolherbst: maybe it can be implemented but nobody bothered to do that yet
17:12karolherbst: mupuf: https://gist.github.com/karolherbst/ce86d42b6055fa4966fc00798d8ec802
17:13karolherbst: "nv50/ir: add pass to move unary instructions to reduce gpr usage" +5% in pixmark_piano :)
17:13karolherbst: ohh wait
17:13karolherbst: the commits in between might be missing
17:13mooch3: weird, the hardware supports floating point texture formats, but mesa doesn't
17:14karolherbst: mooch3: rebuild mesa
17:14karolherbst: mooch3: --enable-texture-float
17:14karolherbst: it is some patent crap and some distributions disable it
17:14karolherbst: or it is even disabled by default
17:15karolherbst: who knows
17:15mooch3: karolherbst, what about color_buffer_float?
17:15karolherbst: no idea
17:16karolherbst: as I said, try it out with overriding the version
17:16karolherbst: and if that works, it works
17:16karolherbst: if not, try to find out what is missing
17:16mooch3: karolherbst, how is nv40 texture float stuff patented tho? o.o
17:16karolherbst: well it is
17:17karolherbst: mooch3: http://www.google.com/patents/about?id=mIIOAAAAEBAJ&dq=6650327
17:17karolherbst: "IP Status"
17:17mooch3: oh my fucking god
17:18mooch3: if it's required for gl3, why is it patented?
17:18karolherbst: it was patented before I uess :D
17:18karolherbst: but it is required for gl3.0 right
17:18karolherbst: but nobody cares really
17:18karolherbst: most distributions just enable it
17:19karolherbst: same with the s3tc stuff
17:20mooch3: does arch linux enable it?
17:21karolherbst: no idea
17:21karolherbst: but it seems like they do
17:22mooch3: oh, it looks like nv40 doesn't fully support all the formats in that extension
17:23karolherbst: well everybody is free to add support for missing stuff
17:26eclipticon: HI, I am using nouveau on Ubuntu Gnome 16.04 on a 3440x1440 screen - generally, 2D performance is not so great and the mouse cursor is leaving traces all over the screen. Anything I can do about that?
17:28karolherbst: eclipticon: what gpu?
17:28eclipticon: Quadro K1100M
17:28karolherbst: ahh kepler
17:28karolherbst: yeah well, then you could reclock
17:29karolherbst: nouveau currently doesn't reclock automatically, even when the display needs a higher clock
17:29eclipticon: How do I do that?
17:29karolherbst: eclipticon: what kernel are you running on?
17:30karolherbst: okay, at least the gddr5 patch landed there
17:31karolherbst: eclipticon: well the issue is though, that it can hang your machine, but I have patches to deal with those, they just aren't landed yet.
17:31karolherbst: eclipticon: to enable reclocking, you have to boot with nouveau.pstate=1
17:31karolherbst: eclipticon: and if setting a higher clock helps, then this is already good to know
17:32mooch3: karolherbst, nv40 seems to not support the majority of gl3 features, unfortunately
17:32karolherbst: mooch3: right, that's why I said you should just force a 3.0 context and see if anything which needs it, might work or not and only deal with stuff you need
17:33mooch3: well, i wanna try to use dolphin on this machine, just to see if it'll work
17:33eclipticon: How to set the higher clock then?
17:33mooch3: i do have machines suitable for it, but i'm just curious. :p
17:37karolherbst: eclipticon: there is a file called pstate in sysfs
17:37karolherbst: eclipticon: /sys/class/drm/cardN/device/pstate
17:37karolherbst: where N is most likely 0
17:38karolherbst: eclipticon: you can cat the file and echo values in it to choose the clock state
17:38karolherbst: eclipticon: but currently nouveau highly undervolts, so it might crash immediatly
17:38karolherbst: eclipticon: but you could compile yourself a custom nouveau module and use the newest stuff to deal with that
17:39eclipticon: Ok, I'll give that a try and hopefully shall return
17:48mooch3: karolherbst, how do i dump my mcp51's bios?
17:48karolherbst: mooch3: why do you need the vbios?
17:48mooch3: when i try to cat it, it says invalid argument
17:49mooch3: karolherbst, emulation
17:49karolherbst: what kind of emulation
17:49mooch3: basically, i have a project to emulate nvidia cards in pc emulators
17:49karolherbst: ohh, k
17:49mooch3: i can't even figure out nv4's pfifo, lol
17:49karolherbst: and the nvidia vbios helps?
17:49mooch3: not really
17:50karolherbst: as I thought
17:50mooch3: i just figured i should have a backup of mcp51's bios
17:50karolherbst: the vbios is more like a description for the driver
17:50mooch3: in case i ever want to emulate it. :p
17:50karolherbst: it is in /sys/kernel/debug/dri/0/vbios.rom though
17:50karolherbst: there is nothing to emulate really
17:50karolherbst: afaik the gpu doesn't react to anything in the vbios anyway
17:51mooch3: i know, but it's an lle emulator
17:51karolherbst: it is soley for the driver I think
17:51mooch3: so i need the bios to run in the emulator
17:51mooch3: that's weird...
17:52mooch3: it's not a power of two size...
17:52mooch3: how is that possible? all rom chips are power of two size
17:52karolherbst: well but not everything is usefull
17:53mooch3: so i should just pad it out to a power of two size?
17:53imirkin: mooch3: dolphin requires native integer support. nv40 does not have integers.
17:54mooch3: imirkin, ah, okay
17:54mooch3: crap, i didn't think of that
17:54imirkin: that's just one very obvious feature, probably of *many*, not supported by nv40
17:55imirkin: another one is no UBO support on nv40
17:55mooch3: seriously? wow
17:57karolherbst: well don't those nv4x card support dx 9.0c?
17:57imirkin: UBO's are a DX10 thing
17:57karolherbst: ahh oaky
17:58mooch3: i wonder why the blob doesn't support ARB_bindless_texture on Fermi tho
17:58mooch3: i mean, afaict, it should just be a driver feature
17:58mooch3: meaning it would be more work to only not support it on fermi than to just support it
17:59mooch3: that means i can't run xenia on my fermi card... :(
18:07imirkin: mooch3: it's a hardware feature
18:07imirkin: fermi is bind-ful, kepler+ are bind-less
18:10eclipticon: Karolherbst - reclocking helped with speeding up things, but the mouse cursor is still leaving traces
18:10karolherbst: eclipticon: mhh
18:10imirkin: eclipticon: that's unrelated
18:10imirkin: eclipticon: i assume you're using reverse prime?
18:10karolherbst: eclipticon: but 2d performance is more close to display sync speed?
18:10imirkin: eclipticon: and the primary driver is intel?
18:10karolherbst: ohh right, I forgot about that :)
18:10imirkin: karolherbst: "mouse traces get left behind" == swcursor
18:10karolherbst: eclipticon: you need ti enable vsync on both ends: compositor + application
18:11imirkin: not a lot of things that force sw cursor
18:11eclipticon: At least the display appears more responsive
18:11karolherbst: eclipticon: did you clock to 0f?
18:11eclipticon: Can you point me to a brief description about vsync?
18:11karolherbst: it may suddenly crash :)
18:12eclipticon: I know, then there is still 0A
18:12karolherbst: eclipticon: usually there should be an option in the applications, otherwise you can always launch with vblank_sync=2 ?
18:12karolherbst: or 3?
18:12karolherbst: I never now what the right numbers are
18:12eclipticon: Sorry, in what applications?
18:13karolherbst: wait.. what kind of setup are you using?
18:13eclipticon: Ubuntu Gnome 16.04
18:13karolherbst: external dispaly via reverse prime?
18:13karolherbst: or is tehre only the nvidia gpu
18:14eclipticon: Mobile workstation with one GPU on docking station, connected to ext display with display port
18:14karolherbst: eclipticon: lspci | grep VGA
18:14eclipticon: 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
18:14eclipticon: 01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1100M] (rev a1)
18:15imirkin: eclipticon: pastebin xorg log
18:17eclipticon: imirkin: http://pastebin.com/TREzL2Pc
18:18imirkin: eclipticon: you appear to be using the nvidia blob?
18:18karolherbst: nvidia prime setup
18:18eclipticon: Having a closer look, I am confused about that as well ...
18:18imirkin: wrong log perhaps?
18:19imirkin: [ 4.440] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 23 13:12:06 2016
18:19imirkin: are you on central time?
18:19eclipticon: no ...
18:20imirkin: then that's probably the wrong log, since it's at least an hour old if you're on eastern time, and much older if you're in europe
18:20eclipticon: I'll purge my Xorg.?.log and reboot and be back ...
18:22karolherbst: imirkin: any idea how the reverse prime situation will look like in the future? With dri3 lacking support for that, and no support in wayland yet :/ I just hope that it won't be something painfull in the future
18:22imirkin: dri3 doesn't preclude dri2 from being used
18:22imirkin: either way, it's something i let airlied worry about - (a) he knows a ton more about it and (b) it's part of his job
18:23karolherbst: I forgot about that
18:23imirkin: and (c) i don't really care myself since i don't need it
18:23karolherbst: I also don't need it on my machine
18:23karolherbst: it is just, it seems like there are many issues regarding it
18:23imirkin: the issue is always with the intel ddx
18:24karolherbst: ohh :/
18:24imirkin: basically the answer is always "update xf86-video-intel and make sure you're using SNA"
18:24imirkin: nouveau just renders the image given to it
18:24imirkin: if the iamge has tracks on it, it's because that's what intel fed in
18:24karolherbst: I just hope the whole display situation is less painfull with wayland in the end, because it should really be not that painfull
18:25karolherbst: nvidia seems to care a lot about this though
18:25imirkin: well, ultimately wayland isn't something i plan on having to care about in the next... 5 years or so
18:25karolherbst: well it kind of works already
18:25imirkin: i'm sure it does
18:26karolherbst: I can start my entire desktop on wayland (though kwin still uses xwayland)
18:26imirkin: but there's no upside to using it, and plenty of downside
18:26imirkin: i don't use gnome-*/kde-*
18:26karolherbst: well security should be one upside
18:26imirkin: i use plenty of X applications
18:27rardiol: is the overhead of running xwayland significant?
18:28karolherbst: I think it is in the range of 5-10% or something
18:28karolherbst: maybe even less
18:31karolherbst: mupuf: commit range f08d9d0:8ff1a1e(5) changed the performance of gputest:pixmark_piano:window from 11.60 to 12.20 (+5.17%) with confidence p=1.00 :)
18:31eclipticon: Interesting, no new Xorg.?.log has been created
18:32mupuf: karolherbst: hehe, nice
18:33karolherbst: mupuf: in total 7%
18:33mupuf: and your issue was because you are running too few instances
18:33karolherbst: mupuf: but first I search all commits with no harm on other tests and improve that one
18:33mupuf: you need more than one run to get values
18:34karolherbst: mupuf: most likely yes
18:34mupuf: well, just run all benchamrks before and after
18:34mupuf: and let ezbench bisect
18:34mupuf: you try to do manually what the tool does for you
18:35karolherbst: mupuf: not really, because I want the changeof every commit anyway
18:36mupuf: well, then force it and let it work overnight
19:48karolherbst: mupuf: any idea how we want to handle those magic fuse writes?
19:49karolherbst: mupuf: depending on the value written into those regs, the returned value from the fuse regs also changes
19:57karolherbst: mupuf: I think the data out of ezbench is already usefull, I seem to have a an error of around 0.1% in each run, but the commits have a much bigger impact
19:58mupuf: sounds good, but how many times did you run it?
19:58mupuf: on the same commit
19:58mupuf: ~10 is a bare mimimu, :D
19:58karolherbst: for gputest it is okay
19:58karolherbst: some tests have +-0.0% between runs
19:59karolherbst: some 0.46% and this is already really high for those
19:59karolherbst: yeah it is usually around +-0.10% with 3 runs
20:00karolherbst: and some commits have a 4% difference in performance
20:00karolherbst: and I only care about those obvious ones
20:00karolherbst: and test them with more runs later
20:09karolherbst: mupuf: https://e90fe705f0c29af893ff1ce0de8e2f0aafba18e1-www.googledrive.com/host/0B78S7GSrzebIallIcG9sNHJFMDA :)
20:09karolherbst: still in process though
20:12karolherbst: but you clearly see that I wrote most of the commits while running pixmark_piano :D
20:17mupuf: karolherbst: DUDE! Throttling events!
20:17karolherbst: I know
20:17mupuf: how can yhou have such a low variance :o
20:17karolherbst: because those tests doesn't use much cpu
20:18mupuf: oh, if you install packagekit, you will also get the versions of all libraries
20:18karolherbst: I installed it once
20:18karolherbst: it has a cron daemon
20:18karolherbst: which eats up CPU a lot
20:18karolherbst: but the runs are fine
20:19karolherbst: I already know which two commits I throw out
20:19karolherbst: "WIP: pass to move tex instructions up"
20:19karolherbst: this was just a test and it seems like to hurt
20:19karolherbst: " add pass to move unary instructions to reduce gpr usage" yep, it reduces gpr usage, but also perf :)
20:20karolherbst: mupuf: with pixmark_piano you usually have like 3% cpu load :D
20:20mupuf: ok, this is weird that you would get throttling events then :o
20:21mupuf:never had some ... but added it just in case
20:21karolherbst: my firmware is messed up I think
20:21karolherbst: or my EC
20:21mupuf: I had to unplug the fan to test it :D
20:21karolherbst: I have those like always
20:21karolherbst: yeah, well
20:21karolherbst: I usually don'T reach max boosting with my cpu
20:21karolherbst: I even undervolted my CPU by a bit so that it isn't that bad
20:22karolherbst: mupuf: ohhh
20:22karolherbst: mupuf: there is an issue for collectin those throttle events
20:22karolherbst: mupuf: you don't save the difference between start and end of benchmark
20:23mupuf: I do
20:23mupuf: I print the before and after :D
20:23karolherbst: THROTTLING.0. before and THROTTLING.1 is after?
20:24mupuf: it just sees throttling twice
20:24karolherbst: it might be good to dispaly the difference
20:24mupuf: so it starts giving indices
20:24karolherbst: otherwise it confuses more then it helps
20:24mupuf: like if you open multiple windows
20:24mupuf: yes, agreed
20:25karolherbst: I also get throttling messages in dmesg, so :/
20:25mupuf: just need to tell the tool that throttling needs to be diffed
20:25karolherbst: "CPU5: Package temperature above threshold, cpu clock throttled (total events = 1386568)" :D
20:25karolherbst: the mesa compile triggeres those
20:25karolherbst: usually my CPU temp is like aroun 98°C on full load
20:26karolherbst: and as it seems with nouveau my GPU can even reach 102°C °
20:26karolherbst: I should make more tea
20:26karolherbst: boost 0 is fine though
20:27karolherbst: mhh maybe nouveau should also export number of throttling events or stuff like that
20:30karolherbst: mupuf: but it still doesn't generate the report between commits :/
20:33mupuf: that is weird
20:39karolherbst: mupuf: what should we do when the gpu is exceeding the budget?
20:42karolherbst: my idea would be to like when we are 5% over the budget we clock down 5% + some safety margin, but I expect that there is some smarter approach than this
20:43mupuf: we will have to RE what NVIDIA does ;p
20:44karolherbst: I know that they have some sort of scale at least
20:47karolherbst: okay, so next thing: RE those stupid power budget table :D
22:04karolherbst: mupuf: it generates the reports though whenever I pause the execution
22:05mupuf: where are you left at now?
22:05karolherbst: after the first benchmark after commit change
22:06karolherbst: it isn't that bad though
22:06karolherbst: because you should usually stop when generating those reports anyway
22:11mupuf: oh!! I know why it does not do it. You gave a ton of work for it to do
22:11mupuf: and it is only when you are done with all the work that it will generate a report and schedule enhancements
22:18karolherbst: ahh okay
22:21mupuf: when you pause it, then it asks core.sh to stop, and the smart runner also stops
22:21mupuf: and then it generates the report
22:21mupuf: but when you pause, it finishes what it was doing before
22:21mupuf: so you never re-do work
22:21mupuf: anyway, bed time!
22:53karolherbst: imirkin: can you think of any reasons why pixmark_julia_f64 might be hurt when I run passes multiple times?
22:59imirkin: yeah, coz we don't have an instruction scheduler
22:59imirkin: and that stuff randomly rearranges (sorta) instructions
23:01karolherbst: I yeah I know it can have an impact, but I run like all gputest tests
23:01karolherbst: and this is the only one with a -0.7% hit
23:01karolherbst: all other are either the same or much better
23:02karolherbst: one test got even a +3.5% improvement
23:02karolherbst: but yeah, maybe it is just the missing scheduler
23:02karolherbst: I was more thinking about maybe some f64 isn't handled good enough in some case though
23:03imirkin: it's random.
23:03karolherbst: so as long as it is better in avarage, it is fine for now