10:14tomeaton17: I am getting bad mouse flicker when I change the dpi of my external monitor and using panning with xrandr. What could be causing this and how do I fix it?
10:32psyk: karolherbst, i got the mmiotrace for gtx770
10:32psyk: it's 258megs. where do you want me to upload it?
10:33RSpliet: psyk: first compress it using xz, that'll save about 90%
10:33psyk: tar or gzip
10:33RSpliet: it's a single file, even just xz is fine
10:35psyk: ok 35 megs with czvf :)
10:36psyk: what is x for?
10:36RSpliet: the tool is called xz
10:37RSpliet: xz compresses a bytestream, tar sticks multiple files together in a single bytestream. Since it's a single file, there's no need for tar, just xz is fine
10:38psyk: does mmiotrace record keystrokes?
10:39psyk: wow xz took it down to 12M
10:39mwk: not exactly
10:39RSpliet: if you somehow manage to trace your keyboard USB commands. Normally mmiotrace only intercepts access of devices for which the driver is loaded after enabling mmiotrace
10:40mwk: unless you happen to somehow include USB driver in the trace
10:40psyk: after enabling all i did was modprobe nvidia
10:40psyk: ok where do i send this guys?
10:41RSpliet: see https://nouveau.freedesktop.org/wiki/MmioTrace/
10:42psyk: hmmm i was kind of working with karolherbst he knows about this issue and was looking into it
10:42psyk: shold i maybe just wait for him to be awake?
10:42RSpliet: karolherbst has access to the mailbox mentioned there
10:42psyk: ok .. just didn't want to sow confusion.
10:43psyk: or share my email...
10:54psyk: ok sent
10:54psyk: pleaes let me know if i missed something.. think i got it all
10:54psyk: oh shit
10:54psyk: the file itself.
10:54RSpliet: classic. No worries, just send again :-)
10:57psyk: lol serious face palm there. was worried about all that other nfo and forgot the actual hakuna
10:57psyk: ok i replied to same thread and attached, should have it now
10:58psyk: how do you view or interpret this file?
10:59psyk: all i did was start sddm and run glxgears .. twice because for some reason vsync disable didn't stick
11:00psyk: crap should have mentioned that in email too.
11:03RSpliet: psyk: there's tools in envytools to parse the trace and make marginally more sense of it
11:04RSpliet: the workloads you used are generally not particularly relevant for the things you debug with mmiotrace files, don't worry.
11:04RSpliet: and otherwise, karolherbst knows where to find you
11:06psyk: i am set to use either nvidia-drivers or nouveau now so if you all need another something from this card's driver - i'll be more than happy to help.
11:07psyk: just took a bit of messing around and i had a busy day as well. who knew mmiotracing thing was some kernel option?! i didn't >:P
11:08psyk: btw... and this is sad.. glxgears with nvidia tops at around 4400 fps. with nvidia-drivers - 28000 or so. :(
11:09psyk: with nouveau* i mean.
11:13pq: psyk, so you are very concerned about the swapbuffers overhead, and not at all about actual rendering performance ;-)
11:13psyk: pq, what do you mean?
11:14pq: because that's what glxgears measures when it has been broken to not sync to vblank
11:14psyk: pq, while in nouveau mode, i have set vblacnk=0 so it's oranges to oranges
11:15pq: yes, but it's still meaningless unless you are actually optimizing the swapbuffers overhead
11:15pq: which has almost nothing to do with actual graphics performance in, say, games
11:15psyk: pq, what and how are swapbuffers overhead optimized?
11:16psyk: all i see atm is fps from glxgears in nouveau and nvidia-drivers modes.
11:16pq: psyk, what I am trying to say is that the fps of glxgears is not relevant.
11:16psyk:blinks twice, then blinks again.
11:16pq: not when it's above the monitor refresh rate
11:17psyk: this monitor is 60
11:17psyk: ok how so?
11:17pq: glxgears does so little drawing that it is practically nothing, so what you actually measure with fps there is *not* how fast the GPU can crunch stuff.
11:17psyk: what is optimization of the swapbuffers overhead
11:18psyk: should i have ran something else insead?
11:18pq: if you are interested in GPU performance, yes, almost anything else is more valid than glxgears - any game benchmark for example
11:19psyk: ok what's easy to get for linux and try?
11:19psyk: now granted, my box is temp patched to be below what this card can do via nouveau because i had problems enabling 0f
11:19pq: I wouldn't know, something Phoronix uses for their benchmarks I guess
11:21psyk: so what about the swapbuffers? FINISH THE FUCKEN STORY :P
11:21pq: it is the overhead from telling the window system "I have this new image coming here, please show it on screen"
11:22pq: it is unrelated to how long it takes to draw that image
11:26psyk: ack this thing needs php why
11:45psyk: wow. warsow is getting removed fairly soon unless a maintainer shows up.. it's masked now. what the hell! major unresolved bugs? seems it was a few days ago i played it...
12:19karolherbst: psyk: I already asked for your vbios, right?
12:30psyk: karolherbst, yea i sent it
12:30psyk: brb tho
12:31psyk: need to afk
17:01martsteiner1: mwk, FYI nvidia's random employees do not know all how things work, and you should always account with that
17:02martsteiner1: mwk: they are not gods, they are random chipsies
17:06karolherbst: yeah, I still know that pw
17:06karolherbst: uhh wow, nice stuff we got there
17:08martsteiner1: and mwk: you in charge of all the code, should not fall into some random indians stupidity trap, instead you should trust your own feeling and senses
17:13martsteiner1: mwk; just rely on your own instincts and do not bother about others misunderstandings, actually the code could work however you design, they were never that much smarter then you
17:20rhyskidd_: karolherbst: in the mmiotrace's gmail box?
17:22martsteiner1: i am just saying when you want to be among the best, there is a lot of crap pulled from different company employees, people have come from huge density nations universities , driving every day intense miles, and probably lack any real clue how actually code structure is, some tools used and that is it
17:26karolherbst: I don't get why pm_runtime_resume has to return -EACCES if runpm is "disabled" for that device :( *sigh*
17:33martsteiner1: the truth is actually when you want something to happen, you put effort in that which can be interrupted with high terror only, until there is no terror, you will always acheive what you want, code is especially flexible, if someone writes it in one way that does not yet mean much
17:33martsteiner1: you can replicate that , but noone says you have to
17:40martsteiner1: i even speak for my experience , i usually even have noted, that i trust random freelancer or open source developer more then random contracted employee
17:41martsteiner1: there is no thumb rule, but the stats are this way
17:48martsteiner1: anyways until you understand that if nvidia worker/employee said something does not mean much, we're totally ok, and i can leave or explain..whatever that does not even matter to me
17:52karolherbst: uhm... now we return -22 uW if the GPU is off, oh well
17:58martsteiner1: ok karolherbst i have one technical question to you, maybe you know that stuff, when the unit goes idle due to bank conflict, well lets ignore the NVIDIA lie, that we can not migrate it away, on different chips what this idling means to power usage though?
17:59martsteiner1: do the threads and some alu units turn into some power save mode for some families while others would sort of draw current still?
18:02martsteiner1: i could right the code for any gpu in the worlds, but i actually do not know what to expect for power usage, performance skyrockets that i know, but what happens to heat and power usaga could vary, its dependant of the chips circuit maybe, but however i dunno either
18:02martsteiner1: transistor level i have not been able to understand that
18:07Tom^: i find it amazingly scary how he never gives up
18:07Tom^: years after years. :o
18:10karolherbst: well, usually there is only one answer to something like that
18:11Tom^: he also just gave himself up he has another nick in here
18:11Tom^: just pmed me. :P
18:12karolherbst: my laptop drains 16W in full idle, sounds like a lot
18:16karolherbst: mhh okay, seems like my GPU doesn't fully power off
18:16karolherbst: Lekensteyn: you deal with issues like this, right?
18:18karolherbst: Lekensteyn: seems like there are still 3-4W left
18:51karolherbst: skeggsb: it seems like your suggestion indeed did the trick
18:51karolherbst: will let it run for a couple of days and see how stable it is
18:57tobijk: karolherbst: sounds nice :)
18:58tobijk: do you have a plan how to prove the defs patch right, btw?
19:00karolherbst: tobijk: "defs patch"?
19:01tobijk: for the "defs", sorry
19:04tobijk: oh imirkin yo actually pushed my patch to eliminate extra movs when using calls, thanks :)
19:04imirkin_: and karol's fix for CS things
19:04tobijk: yep :)
19:04imirkin_: small patches that make sense -- i tend to be pretty good about pushing those.
19:04imirkin_: although i can forget too
19:05imirkin_: invasive things that could destroy the universe ... i tend to be a little more concerned about.
19:05tobijk: yeah, the question is how to satisfy you about these changes then :D
19:09Tom^: karolherbst: still havent been able to get hold of a radeon card, they simply never comes into stores. silly miners so yeah havent been able to send my card :<
20:10karolherbst: mupuf: find the mistake: https://gist.github.com/karolherbst/f1a85d931cc8f4c8b4ffb2cacc46818e
20:45mwk: ... did we ban all of Estonia again?
20:45mwk: oh well
20:53tobijk: does nto sound fair to me, maybe lift that ban :O
21:56karolherbst: the heck.. I found full schematics for my laptop :O the entire MXM bus is described
21:58tobijk: karolherbst: so an older thinkpad?!
21:58karolherbst: tobijk: nope
21:58karolherbst: it's a 2013 laptop
21:59karolherbst: or 2014?
21:59karolherbst: not quite sure
21:59tobijk: does count as older :D
21:59karolherbst: I could just trigger therm alerts
22:00karolherbst: there is a VGA disable bit
22:00tobijk: ? meaning dsiable the discrete card?
22:01karolherbst: this is for the ports
22:01karolherbst: I think
22:01karolherbst: some LVDS stuff as well
22:01tobijk: so just to disable _the_ vga connector?
22:02karolherbst: it's dead on my
22:02karolherbst: SMB_CLK and SMB_DAT, I guess I could have a lot of fun with those
22:03karolherbst: actually I simply wanted to know what kind of smart battery I have and how I could access it, because my kernel doesn't want to
22:04karolherbst: Jtag :)
22:05tobijk: should be driven by some battery driver already?!
22:05tobijk: if not i'm really surprised
22:05karolherbst: default ACPI stuff
22:05karolherbst: but that's boring
22:06karolherbst: hihi, backlight keyboard schematics
22:07tobijk: on / off i presume?
22:07tobijk: or can you "highlight" certain keys?
22:08karolherbst: I have a fancy one
22:08karolherbst: rgb leds
22:08tobijk: "worker assistance" -> let an ai show you what you have to type ;-)
22:09tobijk: with a voice yelling at you: "do it, type E"
22:15karolherbst: power on sequence, nice
22:16karolherbst: ahh, here the interesting thing ->S3 sequence
22:17tobijk: karolherbst: you are investigating your systems power drainage on idle?
22:20karolherbst: I also broke my HDD activity LED by toying around with the EC
22:21karolherbst: maybe I figure out what I did wrong
22:21tobijk: not sure where the dgpu is connected, but it is still enabled (going to idle) while 3.3 and 5V are phasing out?!
22:21karolherbst: seems like it
22:22tobijk: sounds like a source of pontential problems :>
22:22karolherbst: my GPU LED is connected to L2dGPU_PWR_EN
22:25karolherbst: okay, found the battery
22:28karolherbst: connected to the EC SMBUS, mhh sounds annoying
22:29tobijk: with the battery i would be cautious
22:30karolherbst: well, I just want to read it out via sbs
22:30tobijk: with my fan, i just poked value in there to get it to full throttle :D
22:32karolherbst: duh, my touchbad is connected to the EC directly
22:32karolherbst: and keyboard
23:00Lekensteyn: karolherbst: my laptop drains 10-13W idle and about twice that (iirc) when GPU is on; are you sure your GPU is on?
23:02karolherbst: Lekensteyn: 16W was with GPU being marked as off
23:04karolherbst: anyhow, I think I would be able to measure the exact power drain on the MXM bus
23:10karolherbst: Lekensteyn: how much knowledge do you have regarding SBS connected batteries and ACPI to read those out?
23:13Lekensteyn: not that much unfortunately
23:14Lekensteyn: it's possible that something is not entirely correctly set. Battery drain in system sleep is quite bad, after two days it is surely out of power
23:15karolherbst: I really would like to get the power drain out of the battery to have a more precise measurment :(
23:17karolherbst: ACPI 5.0
23:17karolherbst: ._BST method
23:19karolherbst: it's implemented
23:19karolherbst: Lekensteyn: how can I call an ACPI method again through that acpi module?
23:20karolherbst: duh :/ it's some async stuff
23:28karolherbst: it reports 0xffffffff :(
23:28airlied: powertop shows it ?
23:29karolherbst: I simply know I have a battery with those 7 pins or whatever those extended ones have
23:31Lekensteyn: karolherbst: if you have CONFIG_ACPI_DEBUGGER_USER=m (or =y), you can use the "acpidbg" program in tools/power/acpi/tools/acpidbg/ to evaluate commands
23:31karolherbst: but it tells me how fast it charges
23:32Lekensteyn: (alternative you can also use the acpi_call module, echo > /proc/acpi/call \_SB.PCI0.... && cat /proc/acpi/call)
23:32karolherbst: yeah, I use acpi_call already
23:32karolherbst: \_SB.BAT0._BST gives me [0x2, 0x1b6, 0x1440, 0x418d]
23:32karolherbst: when charging
23:33karolherbst: it seems like wrongly implemented
23:33Lekensteyn: isn't the information available through /sys/class/power_supply/BAT0/... ?
23:33karolherbst: well, some information is
23:33karolherbst: but not the one I want to have
23:33karolherbst: "cat: /sys/class/power_supply/BAT0/current_now: No such device"
23:33karolherbst: when discharging
23:34Lekensteyn: even if you can read the fields directly, the granularity might still be 5 secs or something
23:34Lekensteyn: but if you are watching over time it is probably ok
23:34karolherbst: I can read everything out, except current_now when discharging
23:35karolherbst: I think the module has a few bugs
23:36Lekensteyn: on my old Clevo laptop there used to be a check for negative current in which case the value is made unavailable, does your BST method have a similar thing?
23:36karolherbst: the value makes sense
23:37karolherbst: 0xf37c when GPU on 0xf and glxgears slow
23:37karolherbst: around 0xf633 if GPU on 0x7 and glxgears slow
23:38karolherbst: 0xfa83 when GPU ogg
23:38karolherbst: that's the value which is checked against 0x8000 mask
23:39karolherbst: Lekensteyn: mind calling this method on your clevo and see if you get kind of sane data as well?
23:39Lekensteyn: let's see if I have that field
23:41karolherbst1: meh "[drm:drm_atomic_helper_swap_state] *ERROR* [CRTC:32:pipe A] hw_done timed out"
23:44karolherbst: 23W : 0xefc9
23:44karolherbst: 12W: 0xf3c4
23:44karolherbst: power usage is from the GPU sensors
23:46Lekensteyn: karolherbst: "sudo dd if=/dev/mem bs=1 skip=$((0xFF700100+0x2A)) count=1 2>/dev/null | xxd" gives me varying values. When I unplug it, it seems negative, now when I plug it in it gives zero (full battery)
23:46karolherbst: so 0x2a on the EC?
23:47Lekensteyn: the first address is from "OperationRegion (RAM, SystemMemory, 0xFF700100, 0x0100)", the second value was calculated by piping the contents of the following Field in the "fieldsize" utility I created
23:47Lekensteyn: fieldsize.c in https://github.com/Lekensteyn/acpi-stuff.git
23:47karolherbst: what values do you get?
23:48Lekensteyn: at first it was 0xba
23:48Lekensteyn: also saw 0x80 and 0x65
23:48Lekensteyn: when unplugged I saw 0xf5
23:48Lekensteyn: o wait I am doing something wrong
23:49Lekensteyn: this field is 32 bit, but I am reading it as 8but
23:49karolherbst: makes sense
23:49karolherbst: isn't it 16bit?
23:49Lekensteyn: "BPR0, 32, // byte 0x2A bit 0"
23:50Lekensteyn: it is a 32-bit field, but & 0xffff in _BST
23:50karolherbst: I see
23:50Lekensteyn: it changes about every time I read it out
23:50karolherbst: makes sense
23:50Lekensteyn: using this now: sudo dd if=/dev/mem bs=4 skip=$(((0xFF700100+0x2A)/4)) count=1 2>/dev/null | xxd
23:50karolherbst: it has the same memory region for me
23:51karolherbst: 0xa00b when charging
23:51karolherbst: value decreasing
23:51karolherbst: but this is what we already get from the kernel
23:52Lekensteyn: according to the ACPI spec it is the Battery Present Rate expressed in mW or mA
23:52karolherbst: ohh wait
23:52karolherbst: the values make sense for me
23:52karolherbst: it jumps between 0x3000 and 0xb000 roughly
23:53karolherbst: although 0xb000 is a bit too high
23:53karolherbst: but maybe CPU spikes
23:53psyk: hi karolherbst
23:54karolherbst: psyk: hi
23:54psyk: any useful info from that mmiotrace?
23:55karolherbst: that intel syncing is annoying me big times now...
23:56karolherbst: Lekensteyn: as it seems the value doesn't get above 0xffff
23:57Lekensteyn: field should be reported in mA unit btw (first field of the PBIF package is 1)