01:15 pmoreau: pecisk: Cool! Try to go through the VBIOS scripts and see what Nvidia and the VBIOS do, that Nouveau doesn't.
01:40 pecisk: pmoreau, does it mean just go trough both traces and see what's happening differently?
01:41 pmoreau: You can first check what is happening in the VBIOS scripts, see which engines / regs are used, and then check those that are also used by the blob, and finally find if Nouveau uses them or not.
01:42 pecisk: pmoreau, which parts of VBIOS are those scripts? I browsed trough mine yesterday using nvbios
01:42 karolherbst: pmoreau: I already have an idea what could be wrong, beacuse maxwell seems to behave more different than other gens ;)
01:43 pmoreau: Cool! :-)
01:43 karolherbst: pmoreau: how much does nouveau relay on regs being "0x0" when they aren't used?
01:43 pecisk: ahh, saw something called Init script
01:43 pmoreau: Yep
01:44 pmoreau: basically, all lines with REG[some_address] &= some_expression, or similar
01:44 karolherbst: pmoreau: I noticed, that maxwell returns 0xbad11000 for a bunch of PCIE_2 regs, where kepler just returned 0x0
01:44 karolherbst: like for all
01:44 pmoreau: :D
01:44 karolherbst: this would make totoally sense
01:44 karolherbst: did you see his errors?
01:45 karolherbst: bad5500 reads in PIBUS?
01:45 pmoreau: I guess Maxwell under Nouveau returns 0xbad11000, probably not under the blob, right?
01:45 karolherbst: I bet those regs are just 0 on pre maxwell
01:45 karolherbst: pmoreau: mhhh
01:45 karolherbst: pmoreau: so the regs just return bad, because the egnine wasn't right initialized?
01:46 karolherbst: seem strange, because pcie speed change works fine on maxwell nethertheless
01:46 pmoreau: I would say so. Why would you have some regs to always return 0xbad11000?
01:46 karolherbst: don't know
01:46 karolherbst: but check that out: kepler: https://gist.github.com/karolherbst/eb44b2ba1f329df634cd
01:47 karolherbst: maxwell https://gist.github.com/karolherbst/335e57c84d69e112a0f3
01:47 karolherbst: and the usefull regs are working
01:47 pmoreau: Or is it some: "WIP, didn't had time to get it working on this chipset, let's hard code an error value and hope to get it working on the next chipset?" :D
01:47 karolherbst: :D
01:47 karolherbst: don't know
01:48 karolherbst: pmoreau: this is pecisks errors: https://gist.github.com/karolherbst/7732b1c3afd3eb959e54
01:48 karolherbst: it isn't bad for everything, so
01:48 pmoreau: interesting
01:48 karolherbst: yeah
01:48 karolherbst: as I said: it would make sense
01:49 karolherbst: when nouveau heavily rely an those being 0, it may mess thins up
01:49 pmoreau: What are those regs values when using the blob?
01:49 pecisk: sounds plausable
01:50 karolherbst: pmoreau: I don't know the regs :D
01:50 karolherbst: https://github.com/envytools/envytools/blob/master/rnndb/bus/pibus.xml
01:51 karolherbst: ohhh
01:51 karolherbst: somehow this doesn't make sense...
01:51 pmoreau: pecisk: Could you do a `nvapeek 8c000 1000 > some_file` after loading the blob and running like glxgears or glxinfo?
01:51 karolherbst: pmoreau: I did this on reator, so basically we could play around there ;)
01:51 karolherbst: there is a maxwell card in
01:52 pmoreau: Oh, so you could know what their value is with the blob
01:52 pecisk: pmoreau, roger
01:52 karolherbst: pmoreau: I could, yeah :D
01:52 pmoreau: :p
01:53 karolherbst: nether though of the possibility it may be different on the blob
01:53 pmoreau: pecisk: Whenever you have time of course :)
01:54 karolherbst: ohhhhhh shit
01:54 karolherbst: right
01:54 karolherbst: we can't use the blob right now because of kernel
01:54 karolherbst: the 4.2 RCs won't work
01:54 karolherbst: pmoreau: ever changed kernel on reator?
01:55 pmoreau: Never used reator yet ;)
01:55 karolherbst: ohh I see
01:55 pmoreau: The first time I wanted to, Martin was using it and ran the test for me :D
01:55 karolherbst: blob doesn't compile on 4.2 RC, because a symbol changed to GPL only by moving a function into inline
01:56 karolherbst: pmoreau: any clue about nouveau exporting sensors into liux frameworks, like the temp sensor?
01:57 pmoreau: Absolutely no clue! Sorry
01:57 karolherbst: I have a power sensor I would like to have exported too, so that I can see the power consumption under nouveau, too
01:57 karolherbst: k
01:57 pmoreau: I've been mostly fiddling with PDISP / EVO, and a tiny bit of PFB and PPCI without knowing what I was doing.
01:57 karolherbst: :D
01:58 pmoreau: I have the blob running on 4.2 on Arch. I could check how they did it
01:58 karolherbst: by the way, do you have a pcie v1 and pcie v2+ board?
01:58 karolherbst: and a kepler+ card?
01:58 karolherbst: :D
01:58 karolherbst: need to verify a stupid bit in a reg
01:59 karolherbst: mhh or maybe a pcie v2+ board with a v1 slot?
01:59 karolherbst: this would also be nice
01:59 pmoreau: I don't know :D Only have my old laptop at hand (G96 + MCP79).
01:59 karolherbst: ohh okay
01:59 karolherbst: pmoreau: I want to verify those: https://github.com/envytools/envytools/pull/21/files
02:00 karolherbst: I am sure about the system sped and cap speed though
02:01 pmoreau: I mostly have Tesla, one Fermi and one Maxwell (which is way to long to fit in the case... so never plugged it yet)
02:01 karolherbst: :(
02:01 pmoreau: How to check for the PCI version?
02:01 karolherbst: lspci -vv
02:01 karolherbst: "Capabilities: [78] Express (v2) Endpoint, MSI 00"
02:02 karolherbst: funny though, you can even move kepler into v1 mode on v3 boards
02:02 pmoreau: Capabilities: [78] Express (v2) Endpoint, MSI 00
02:02 pmoreau: Oh, same
02:02 karolherbst: yeah most like your 0x8c1c0 reg is 30036
02:03 karolherbst: which is the most common case
02:03 karolherbst: ohh this reg is kepler+
02:03 pmoreau: It's 0 for me :)
02:03 karolherbst: yeah I know
02:07 pecisk: pmoreau, karolherbst well, I can't get even blob working now...glxgears and glxinfo says BadValue, etc. and dmesg ACPI complains and this pci is not vga device
02:07 pecisk: trough bumblebee of course
02:12 pmoreau: :/
02:13 pecisk: what could be cause?
02:13 pmoreau: What does the nvidia-settings say?
02:14 pmoreau: But it seems really messed up
02:16 karolherbst: pecisk: I hope nouveau wasn't loaded?
02:19 pecisk: karolherbst, no, but I get constant ACPI error now and nouveau doesn't initialize nothing either
02:23 pecisk_: karolherbst: so I get this when I tried to run glxinfo and glxgears under optirun
02:23 pecisk_: http://ur1.ca/ntll0
02:23 pecisk_: modprobe nouveau does nothing, there's no info in dmesg
02:24 karolherbst: these ACPI warnings are not important
02:24 karolherbst: pecisk_: is bbswitch loaded?
02:24 pecisk_: karolherbst: no, but it wasn't also yesterday
02:25 karolherbst: this is related to the card being off I guess
02:25 karolherbst: or it was off or whatever
02:25 pecisk_: it is
02:25 karolherbst: sadly vgaswitcheroo only works when nouveau is laoded
02:25 karolherbst: and nouveau was able to identify the card
02:25 karolherbst: but this isn't always the case
02:25 karolherbst: pecisk_: is bbswitch installed?
02:25 karolherbst: if yes, then do modproble bbswitch
02:26 karolherbst: 'modprobe
02:26 pecisk_: well, package is but module is not for strange reason
02:26 karolherbst: it doesn't get automatically loaded
02:26 karolherbst: when you have it loaded, please cat /proc/acpi/bbswitch
02:26 karolherbst: when it says OFF
02:26 karolherbst: do echo ON > /proc/acpi/bbswitch
02:27 karolherbst: then try again under optirun
02:27 pecisk_: I have package installed but there's no module bbswitch anywhere
02:28 pecisk_: wtf Fedora :)
02:28 karolherbst: lol
02:28 karolherbst: pecisk_: please do find /lib/modules/ -iname bbswitch*
02:30 pecisk_: karolherbst: ha, they are funny guys
02:30 pecisk_: it's basically a src package
02:31 karolherbst: yeah I know
02:31 pecisk_: where readme says compile yourself
02:31 karolherbst: :D
02:31 karolherbst: lol
02:31 pecisk_: no akmod or anything
02:31 pecisk_: ok
02:31 karolherbst: yeah, this sounds really funny to me
02:32 pecisk_: well, someone thought it is better having package than none
02:32 pecisk_: which is ok, but there was no instructions
02:32 pecisk_: ohh well
02:33 pecisk_: karolherbst: ok, module loaded, bbswitch says ON on Nvidia device
02:35 karolherbst: mhh
02:35 karolherbst: then turn it off and on :
02:35 karolherbst: D
02:35 karolherbst: classical solution to classical problems :)
02:36 karolherbst: just echo OFF and then ON into it
02:36 karolherbst: maybe wait a few seconds
02:37 pecisk_: [ 2007.855315] ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
02:37 pecisk_: [ 2007.866313] pci_raw_set_power_state: 51 callbacks suppressed
02:37 pecisk_: [ 2007.866318] pci 0000:01:00.0: Refused to change power state, currently in D0
02:38 karolherbst: mhh, the warning doesn't matter
02:38 karolherbst: but the other things are strange
02:38 karolherbst: is nvidia or nouveau loaded?
02:38 pecisk_: no
02:39 karolherbst: then we may have to reset the entire card
02:39 pecisk_: when nvidia was loaded, it clearly said it refuses to be tuned off because of that
02:39 pecisk_: pci-reset?
02:39 karolherbst: 01:00.0 is your bus address?
02:39 karolherbst: echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/reset
02:40 karolherbst: echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/rescan
02:40 karolherbst: then try again to turn it off
02:42 pecisk_: karolherbst: "disabling discrete graphics" seems like worked this time
02:42 pecisk_: yeah, it's OFF
02:42 pecisk_: ok, turned back on
02:44 pecisk_: trying nvidia
02:45 pecisk_: glxgears not working :(
02:46 pecisk_: nouveau also is silent
02:48 karolherbst: mhh
02:48 karolherbst: seems like the card is really messed up
02:48 karolherbst: maybe you should cold reboot :D
02:50 pecisk_: karolherbst: what would be cold repoort in this sense?
02:50 karolherbst: power off your laptop
02:50 pecisk_: well, I did that, but one more time won't hurt
02:55 pecisk_: karolherbst: ok, phew, modprove nouveau gives me sched_err again
02:56 pecisk_: (after I turned it on via bbswitch)
02:56 pecisk_: reboot and I will try optirun
03:00 pecisk_: optirun doesn't work though, glxgears and glxinfo complains, nvidia-settings complains about not using Xorg nvidia driver
03:02 pecisk_: whut
03:02 pecisk_: Failed to load nvidia, module doesn't exist
03:03 pecisk_: well, config seems to be borked, nothing related to card I guess
04:30 karolherbst: pecisk_: maybe you should reinstall nvidia and make sure your xxorg.conf is still sane and nvidia blacklisted
04:50 pecisk_: karolherbst: I think I found out why it fails
04:50 pecisk_: will test
04:50 pecisk_: bb
05:21 pecisk_: karolherbst: it seems Xorg launched for Nvidia by bumblebee has problems to run glx module, although it loads it
05:39 karolherbst: I had such a problem on ubuntu once :/
05:39 karolherbst: you have to adjust the paths
05:39 karolherbst: wait
05:40 karolherbst: pecisk_: in the bumblebee conf in the driver-nvidia section you have a XorgModulePath= entry
05:40 karolherbst: mine is like this: /usr/lib64/opengl/nvidia/lib,/usr/lib64/opengl/nvidia/extensions,/usr/lib64/xorg/modules/drivers,/usr/lib64/xorg/modules
05:41 karolherbst: you need to adjust those paths to fit your installation though
05:51 pecisk_: karolherbst: fun, did dnf update and Fedora 23 has rolled Xorg 1.18 in beta period
05:53 pecisk_: from 1.17
05:54 pecisk_: reinstalled bumblebee, will see what happens
06:08 karolherbst: ohh
06:08 karolherbst: then you should look ingo Xorg.8.log
06:08 karolherbst: maybe the ABI changed and nvidia can't be loaded anymore
06:09 karolherbst: you could add in /etc/bumblebee/xorg.conf.nvidia Option "IgnoreABI" "1" to the ServerFlags
06:09 karolherbst: it may or may not work
07:35 pecisk: karolherbst, yeah, nvidia can't load anymore, Xorg 1.18 needs ABI 20
07:35 pecisk: is there even compatible binary driver for 1.18 yet?
07:37 karolherbst: you could try out the option
07:37 karolherbst: I know that it worked once for me
07:37 karolherbst: but who knows if it works now
07:38 pecisk: sure
07:48 Yoshimo: hdmi and dvi should be known to nouveau shouldn't they? I wonder why i get nouveau W[DRM] unknown connector type 70
07:53 karolherbst: Yoshimo: which card do you have? and what kernel/nouveau version are you using?
07:55 karolherbst: Yoshimo: any way, 0x70 is "Virtual connector for Wifi Display"
07:55 karolherbst: Yoshimo: doesn't xrandr show all your connectors?
07:58 Yoshimo: karol it is them gm204 980 still, i just tried 4.3rc1
08:04 karolherbst: yeah, but does xrandr show all your connectors?
08:04 karolherbst: 0x70 isn't either dvi nor hdmi
08:05 huehner: karolherbst,Yoshimo i had same warning on my gm206 960 but both hdmi + dvi-i (vga adapter) still worked just fine for me (starting with 4.0 kernel)
08:06 Yoshimo: huehner: it works fine, i was just wondering what it is
08:08 huehner: Yoshimo: not completely clear to me either, just seen that what karolherbst said above in nvidia docs 'virtual connector for Wifi Display' whatever that should be
08:11 karolherbst: maybe nvidia shield?
08:17 Yoshimo: searchengine hinted at miracast
08:17 karolherbst: ohh
08:17 karolherbst: maybe that's what nvidia shield is?
08:18 karolherbst: http://support-shield.nvidia.com/user-guide/index.htm#t=Miracast.htm
08:18 karolherbst: okay, quite
08:19 karolherbst: this entry is anyway useless
08:19 karolherbst: because it is on the vbios
08:19 karolherbst: I can't figure of any reason why this shouldn't work with any card
08:20 karolherbst: but there should be a nouveau module patch for it nethertheless
08:31 karolherbst: I think I will really add a way to "overclock" the nvidia card, would be nice if somebody would agree with me on a design for that
08:33 karolherbst: even if that will never land in the main tree ;)
08:34 mupuf: imirkin_: oopsie :D Thanks for noticing! I am reencoding it with the right second part!
08:34 karolherbst: mupuf: hi :) I need later help with the power sensor I've got if you got some time for that
08:35 mupuf: what do you want to do?
08:35 karolherbst: read the values out with nouveau
08:35 mupuf: you can read the power sensor from the userspace
08:35 karolherbst: it does work with the blob
08:35 karolherbst: howso?
08:36 karolherbst: with your pwr_read tool I was able to read them for the blob, but not with nouveau
08:37 karolherbst: I think there is something missing to activate this sensor?
08:37 mupuf: yes, I am sorry, the code is crap
08:37 mupuf: there is a if at the beggining of main
08:37 mupuf: if (1) --> if (0)
08:38 mupuf: and it should work with nouveau
08:38 karolherbst: ohh okay, and all the other stuff should still work?
08:38 mupuf: you will have to change the source code if you want to also dump frequencies
08:38 karolherbst: anyway, I would like to add this information to "sensors" in some way
08:38 karolherbst: ahh I see
08:38 mupuf: the entire program is a hack, I am sure you will agree with this :D
08:38 karolherbst: yes
08:38 karolherbst: works nice though
08:39 karolherbst: I think it would be nice to add those information to sensors
08:39 karolherbst: or just to the kernel frameworks
08:39 karolherbst: I have to figure a way out how to get the power usage of my laptop anyway, gpu would be a good start
08:41 karolherbst: mupuf: ohh I have to call this "use_ina3221" function?
08:41 mupuf: karolherbst: yes, I have code in the pipe for that
08:41 mupuf: the original point was to expose that from pmu
08:42 mupuf: I wrote the code for it... but nvidia released a signed microcode for it which means we would have to rewrite our interface and nvidia may also not expose it at all
08:43 mupuf: I have another patchset adding it in the kernel side
08:43 mupuf: but it won;t apply after the rewrite of nouveau
08:43 mupuf: I can start fixing it up
08:44 mupuf: I also need to finish my pcie parsing code so as you can write the reclocking code for pcie
08:44 karolherbst: ohh I shouldn't call that in the loop
08:44 karolherbst: "Failed to acquire bus access and/or talk to slave: Invalid argument" :/
08:45 karolherbst: mupuf: which pcie parsing code?
08:45 mupuf: for the vbios table
08:45 mupuf: there was somethingrelated to it
08:46 karolherbst: to parse the speed and width?
08:46 karolherbst: I have something like this: https://github.com/karolherbst/nouveau/commit/85f02317cc2a11e98a93383f0ccb6775f619fdbd
08:47 mupuf: does not look too bad
08:47 mupuf: why do you force the width to )xff though?
08:48 karolherbst: because nvbios doesn't parse it right
08:48 karolherbst: it is 255 on my card there too
08:48 karolherbst: and until we figure out how to parse it right, I just ginore it for now
08:48 karolherbst: mupuf: also your kepler card helped a lot yesterday :)
08:48 karolherbst: do you know that it is set to x4 width in reator?
08:49 mupuf: karolherbst: some older cards have it
08:49 karolherbst: mupuf: I know, it seems to work on tesla to set the width for "some" cards
08:49 karolherbst: most likely nearly no card
08:49 karolherbst: other cards were stuck at x1 after setting it
08:50 karolherbst: mupuf: do you know if one of the gpus is in a x4 pcie slot in reator? or are both x16?
08:50 mupuf: the kepler is on the second pcie slot
08:50 karolherbst: yeah I figured
08:51 karolherbst: but is it a x16 slot?
08:51 mupuf: no fucking clue :D
08:51 karolherbst: is it shorter than the other?
08:51 karolherbst: I want to fully understand this reg: https://github.com/karolherbst/envytools/commit/f0bd8c757030e95015bf65d1ccfc75aa46f33af0
08:52 karolherbst: so I kind of need that information :p
08:52 karolherbst: both values were 0x4 though for your kepler
08:52 karolherbst: so I doubt they represent what the card can do
08:52 pecisk: karolherbst, seems I will reinstall distribution :)
08:52 karolherbst: pecisk: why?
08:53 mupuf: karolherbst: hmm, I am still in toronto
08:53 karolherbst: mupuf: but if both slots are x16, then it most likely won't shot what the bus can do either
08:53 karolherbst: mhhh, I hoped you would remember this :/ oh well
08:54 karolherbst: the thing is, we might be able to change the width if two cards are installed
08:54 karolherbst: and depending on load, we might add add lanes to one card, and remove from the other card
08:56 mupuf: karolherbst: it is possible, but that is too much of a niche optimisation
08:56 pecisk: karolherbst, for some reason it doesn't boot anymore
08:57 pecisk: even everything in blacklists
08:57 pecisk: karolherbst, no biggie, I just freshly reinstalled it anyway
08:57 karolherbst: pecisk: :/
08:57 karolherbst: you reinstalled blob
08:57 karolherbst: this messes things up hard
08:58 karolherbst: I bet LibGL paths are messed up or something
08:58 pecisk: most likely :)
08:58 pecisk: no biggie
08:59 karolherbst: mupuf: I don't know why, but ioctl(fd, I2C_SLAVE, ina3221_addr) fails
09:00 mupuf: do you have a ina3221 or the other kind?
09:01 karolherbst: ina3221
09:01 karolherbst: at 0x80
09:01 karolherbst: EXTDEV 1: type 0x4e [INA3221] at 0x80 defbus 0 unk02_5 2 unk03 0x02
09:03 mupuf: all the mobos look the same
09:03 mupuf: I remember it is an msi
09:03 mupuf: and it finishes by g43
09:03 mupuf: but I do not remember the rest
09:03 karolherbst: ioctl returns -1
09:03 karolherbst: EPERM
09:05 mupuf: well, try with sudo then :D
09:05 karolherbst: I do
09:05 mupuf: the program works for me on reator, it would seem
09:05 karolherbst: maybe I forgot something in the kernel? who knows
09:05 mupuf: but it may not be the same exact code
09:05 mupuf: ssh and copy /root/src/pwr_read.c
09:06 mupuf: from reator
09:06 mupuf: the binary works for me at least
09:06 karolherbst: how do I copy with ssh again? :D
09:06 mupuf: http://pastebin.com/9atXq8Rf
09:06 mupuf: scp
09:07 mupuf: I won't give you the command line because I do not want people to know the ip of reator :p
09:09 karolherbst: scp: /root/src/pwr_read.c: No such file or directory
09:09 karolherbst: got it
09:09 karolherbst: you forgot pwr_read/ ;)
09:10 karolherbst: ohh it works now
09:13 mupuf: ack
09:13 mupuf: then I screwed up the other code :D
09:13 karolherbst: nope
09:13 karolherbst: I screwed it up
09:13 karolherbst: I somehow set the adress to 0x80 instead of leaving it at 0x40 :/
09:13 karolherbst: I thought the adress in the bios might be important
09:14 karolherbst: mhhh strange
09:14 karolherbst: power usage constant at 11.72
09:14 karolherbst: this seems wrong
09:14 karolherbst: but your code works
09:15 karolherbst: wow, 11W in idle for the gpu alone
09:16 karolherbst: 18W idle at 0f pstate
09:19 karolherbst: 65W with furmark :)
09:19 karolherbst: pci speed seems to have no effect on power consumption
09:20 karolherbst: mhh maybe 0.2W?
09:21 karolherbst: something around 0.15W in idle between 2.5 and 8.0
09:23 karolherbst: mupuf: this reg is read only
09:24 mupuf: karolherbst: yep :D without power gating, the gpu is consumming a ton of power
09:24 mlankhorst: indeed..
09:25 mupuf: karolherbst: the address found in the bios is in the 8 bit form
09:25 mupuf: instead of the normal 7 bits + r/w bit
09:26 mupuf: my code is doing the right thing. It iterates through all the possible addresses of the device
09:27 karolherbst: mupuf: it is less than with the blob
09:27 karolherbst: at idle
09:27 mupuf: wtf
09:27 karolherbst: lower voltage
09:28 karolherbst: ohh maybe not
09:28 karolherbst: blob is around 8.4W
09:28 karolherbst: nouveau with your voltage patch is around 10W
09:29 karolherbst: but I don't care that much about power consumption myself, I just want to consider it in some tests :)
09:30 mupuf: right :)
09:31 mupuf: Anyway, really have to go!
09:31 karolherbst: have fun
11:40 pecisk: karolherbst, fresh install, same issues - seems those packages doesn't work well with F23 (they are meant for F22). It feels something along the lines of Nvidia libraries are missing (OpenGL nvidia libs, or something)
11:48 karolherbst: mhhh
11:48 karolherbst: maybe
11:49 karolherbst: at least we got your traces
11:49 pecisk: yeah
11:49 pecisk: I can try install Fedora 22 for funsies
11:50 karolherbst: or try a real distribution for fun ;)
11:50 pecisk: burn :)
11:51 karolherbst: LFS sounds like a lot of fun
11:51 pecisk: I suspect something in F23 got updated and tanked those drivers
11:51 karolherbst: but I am too lazy for that
11:51 karolherbst: new X server ABI is always kind of bad with blob
11:51 pecisk: I left it at 17.2
11:51 pecisk: Xorg
11:51 karolherbst: then it should usually work
11:51 pecisk: yeah, as I said, I think Xorg driver was ok
11:51 pecisk: I suspect GL libs or something
11:52 karolherbst: but the bumblebee package looks like crap and installing blob without bumblebee is a world of pain
11:52 karolherbst: because you have to "repair" what the package installs breaks
11:52 pecisk: yeah, that's how I trashed Fedora previously, tried to use bumblebee to install 355 driver
11:53 karolherbst: sometimes blacklist entries are missing
11:53 karolherbst: for example in ubuntu nvidia modules are always versioned
11:53 karolherbst: so you need a blacklist file with every nvidia-$version combination
11:54 karolherbst: usually distributions are using some kind of automagic to determine what you want
11:54 karolherbst: like if nvidia blob is installed, you most likly want to run X on your nvidia card
11:54 karolherbst: but for hybrid GPU laptops or hybrid GPU desktop this is stupid
11:54 karolherbst: and even on the latter, some might use the nvidia card directly, others may want to use the intel card instead
11:55 pecisk: karolherbst, btw, one reason was that /dev/dri/card0 complained about permission denied in Xorg log
11:55 pecisk: but it has video group and I added user to video group
11:55 pecisk: and google says that note is not important
11:55 karolherbst: about DRI interface?
11:55 karolherbst: you can ignore that
11:55 pecisk: ok
11:56 karolherbst: mhhh
11:57 karolherbst: maybe I should go through the pain and write a wiki page about dual hybrid laptops for nouveau development setup
11:57 karolherbst: where nouveau/nvidia is exchangeable in an instant
12:08 pecisk: karolherbst, my only is that in dmesg there's about not being vga card when I try to do glxinfo...ACPI seems to be broken too (at least nvidia driver ackonledges it)
12:27 karolherbst: the ACPI warning doesn't matter
12:34 Yoshimo: how much stuff is left to be done for the gddr5 branch karol?
12:41 karolherbst: ohh not much gddr5 related itself I assume
12:41 karolherbst: everything I encountered so far was not gddr5 related
12:42 karolherbst: Yoshimo: did you try it out yourself?
12:43 Yoshimo: not yet, was just messing today with my old 560ti
12:43 karolherbst: we need to figure all these issues out, so that work on dynamic reclocking can begin
12:43 karolherbst: this is a fermi card, isn't it?
12:50 Yoshimo: yea GF110
13:06 pmoreau: imirkin: What are the arguments of DataArray::Store? I would have said (i: index, c: component) of the destination value and value the value to store.
13:07 pmoreau: imirkin: But in that case, why should lookup(m, i, c) == value?
13:14 imirkin: pmoreau: tgsi values are vec4's
13:14 imirkin: pmoreau: nv50 ir values are individual values
13:14 imirkin: pmoreau: so like TEMP[i] = vec4. c is which component of the vec4
13:14 pmoreau: I understood so far
13:16 pmoreau: It's mostly the lookup(m, i, c) == value which I don't understand: lookup(m, i, c) should return the destination, whereas value is the value to store. So how can they be equal?
13:34 imirkin: a value is a value is a value
13:34 imirkin: you can store things to values
13:34 imirkin: you can read from values
13:34 imirkin: a value is basically a register (virtually speaking)
13:35 pmoreau: So in that case, the value passed to store is not the value (aka. content) to store, but the destination?
13:36 imirkin: there is no "the destination"
13:36 imirkin: it's just a register
13:36 imirkin: the DataStore maps (i, c) -> register
13:36 imirkin: er, DataArray::Store
13:36 pmoreau: Hum, ok
13:37 pmoreau: I understand the == better then. :)
13:38 imirkin: because in TGSI, TEMP[0] is just a (vec4) register
13:38 imirkin: so if you write to TEMP[0].x and then read from it
13:38 imirkin: you want to be able to access the relevant value
13:38 imirkin: note that this is mostly useful for non-ssa inputs
13:38 imirkin: for SSA inputs you get to play with different shenanigans
13:38 imirkin: since stuff is defined only once
13:39 imirkin: so there's never a question of what's what
13:39 pmoreau: O.O
13:39 imirkin: but nv50 ir lowering passes expect non-ssa input
13:39 imirkin: so you have to de-ssa it first
13:39 imirkin: and then the nouveau compiler will re-ssa it and perform all the optimizations
13:40 pmoreau: If I only have "vec4 tmp = vec4(0.0, 0.0, 0.0, 0.0);" and never use tmp again, I shouldn't need to de-ssa it I guess.
13:41 imirkin: well, ssa only matters once you start having control flow
13:41 pmoreau: Right
13:42 pmoreau: And I am certainly not there yet. :D
13:42 imirkin: just giving you preview of what's to come
13:42 pmoreau: ;)
13:49 virtTimH: what's the difference between nouveau and nouveau_vieux? is it gallium?
13:50 virtTimH: so vieux is classic?
13:50 virtTimH: non-gallium...
13:51 imirkin: nouveau_vieux is for nv04-nv2x, nouveau is for nv30+
13:52 imirkin: and indeed, nouveau_vieux is a classic driver, no shader support
13:52 virtTimH: thanks imirkin
13:52 imirkin: GL 1.2
13:52 imirkin: (+ some extensions)
13:52 karolherbst: is anybody working on that :D
13:52 virtTimH: this might be non-nouveau specific, but any idea why I am getting this?
13:52 virtTimH: failed to load module: /usr/lib/libgallium.so.0: undefined symbol: _glapi_tls_Dispatch
13:53 karolherbst: imirkin: ohh something I remember, did you know that the G4 PowerMacs had a power safe CPU feature, which can be enabled?
13:53 virtTimH: i've built with enable-glx-tls
13:53 imirkin: karolherbst: git log src/mesa/drivers/dri/nouveau
13:53 imirkin: virtTimH: afaik that means you've done something very weird in terms of mixing versions, etc
13:53 karolherbst: virtTimH: make clean
13:53 karolherbst: the build system doesn't notice header changes
13:53 karolherbst: or not all
13:54 karolherbst: so there is an internal ABI mess up
13:54 virtTimH: k, trying, thanks
13:54 karolherbst: imirkin: I hope I remember right and you were the one playing around on G4s?
13:55 imirkin: karolherbst: i have a G5, and it does have cpufreq support
13:55 karolherbst: I really don't know what this was, but with the apple dev tools you could add an extension, so that you can enable experimental features.
13:56 virtTimH: karolherbst: doesn't seem to help
13:56 karolherbst: virtTimH: how fast you rebuild mesa :)
13:57 virtTimH: this is line right before
13:57 virtTimH: gbm: failed to open any driver (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)failed to load driver: nouveau
13:57 virtTimH: karolherbst: i4770 with 32GB RAM?
13:57 virtTimH: on an ssd
13:57 karolherbst: uhh ssd
13:57 karolherbst: right
13:57 virtTimH: oh god, for building
13:58 virtTimH: i'm spoiled.. got some for work about 3 years ago
13:58 karolherbst: mhh I also need to build classic and intel driver, so maybe that's why it takes so long here
13:58 virtTimH: you couldn't make me go back
13:58 virtTimH: i would quit
13:58 virtTimH: yeah, i just built swrast and noveau
13:58 virtTimH: nouveau*
13:59 pmoreau: I think I had the same issue of undefined symbol, with a clean build. I just removed --enable-glx-tls.
14:00 virtTimH: this could just be an issue with my craziness over here I don't understand, ok... more spelunking
14:00 virtTimH: pmoreau: oj
14:00 virtTimH: pmoreau: oh?
14:00 virtTimH: i'll try that, it's certainly trivial
14:01 pmoreau: :)
14:01 pmoreau: Especially when building Mesa that quickly!
14:01 virtTimH: aye
14:02 virtTimH: building is fun, love to see all the cores being used!
14:02 virtTimH: scratch that, pegged!
14:02 pmoreau: :D
14:03 pecisk: listening to AMDGPU talk from XDC - if that correctly implied, when radeon open source driver will get OpenGL 4.3 - 4.5, they will start phasing out binary driver
14:03 virtTimH: pmoreau: that went away but this came:
14:03 virtTimH: failed to load module: /usr/lib/libgallium.so.0: undefined symbol: _glapi_Dispatch
14:03 virtTimH: heh
14:04 pmoreau: Eh!
14:04 pmoreau: Quite sure I didn't had that one
14:05 virtTimH: nm seens to disagree
14:05 imirkin: pecisk: i'm guessing you forgot --enable-gbm or something in your mesa build
14:11 pecisk: imirkin, I will guess you didn't mean me :)
14:12 imirkin: no, indeed i did not. virtTimH --^
14:12 virtTimH: imirkin: i thought so, i decided to do it silently, about to install, thanks
14:13 pmoreau: imirkin: So, if store doesn't care about the destination "float tmp1 = 0.0f; tmp1 = tmp1 + 3.0f;" would translate in "mov %r0 0.000000; add %r1 %r0 3.00000;"?
14:13 imirkin: pmoreau: post-ssa, yes
14:14 imirkin: pmoreau: pre-ssa, it'd probably just be add %r0, %r0, 3.0
14:15 pmoreau: Hum... You can specify the destination of add... bad example
14:15 imirkin: what would be a good example? :p
14:16 pmoreau: Not sure I'll be able to find one for that case :D
14:16 virtTimH: nope, no combination of enable-glx-tls and enable-gbm make it go away
14:16 karolherbst: I would always do a clean build after messig with options ;)
14:16 virtTimH: i did
14:16 karolherbst: mhhh
14:17 virtTimH: i did like 4 different cleans
14:17 imirkin: virtTimH: what's your configure line?
14:18 virtTimH: ./autogen.sh --enable-glx-tls --enable-gbm --enable-gles2 --with-egl-platforms=x11,wayland,drm --prefix=/usr --with-dri-drivers=swrast,nouveau --with-gallium-drivers=swrast,nouveau
14:18 virtTimH: that was most recent
14:18 imirkin: fwiw you don't need --with-dri-drivers=swrast,nouveau -- you can just use --without-dri-drivers
14:19 imirkin: you probably also want --enable-texture-float
14:20 virtTimH: because using gallium drivers?
14:21 karolherbst: virtTimH: no, because you want to have it
14:22 virtTimH: what I mean is, i don't understand :)
14:23 virtTimH: i thought I wanted dri drivers
14:25 imirkin: you don't want the classic drivers
14:25 imirkin: you don't have any hw driven by them
14:25 imirkin: it won't hurt to have them
14:26 virtTimH: so the dri are classic, right?
14:26 imirkin: you can take my word, or you can investigate it yourself.
14:27 virtTimH: no sorry, i was just trying to get it straight in my head
14:38 virtTimH: 0000000000000000 D _glapi_tls_Dispatch
14:38 virtTimH: if that's what nm shows
14:38 virtTimH: that indicates it is defined, right?
14:39 virtTimH: i'm running strace on it
14:39 karolherbst: virtTimH: why not LD_DEBUG
14:39 virtTimH: karolherbst: no familiar?
14:40 virtTimH: err not*
14:40 virtTimH: will check nexst
14:46 virtTimH: karolherbst: LD_DEBUG=all
14:46 virtTimH: :)
14:48 karolherbst: which is a little overkill, but yell it should complain what is wrong
14:48 karolherbst: *about
14:57 virtTimH: clear
14:59 virtTimH: i mean, it's looking in the file that shows it defined
14:59 virtTimH: -\_o*o_/-
15:07 virtTimH: ok, thanks everyone, enough of this for now...
16:17 karolherbst: mupuf: is there by any chance some patches or a branch where some ina3221 stuff was done? And if not, what would be the required steps to add the power consumption to hwmon?
16:28 karolherbst: "using image from PROM" who "normal" is this on kepler?
16:28 imirkin: quite
16:28 imirkin: less normal on a laptop though... nowadays they all like to stick the vbios into acpi
16:30 karolherbst: ahh I see
16:30 karolherbst: I still try to figure out why I can't fake my bios, most likely because PRAMIN doesn't work?
16:31 imirkin: pramin works
16:31 imirkin: it's video ram
16:31 karolherbst: ohh okay
16:32 karolherbst: but the vbios isn't there or shouldn't be read from there?
17:29 joi: imirkin, karolherbst: I found the cause of fifo read faults with witcher2
17:29 imirkin: wow, awesome
17:29 karolherbst: joi: nice one
17:30 joi: mesa destroys buffers before they are used
17:30 imirkin: :(
17:30 karolherbst: this sounds not good
17:30 joi: yeah
17:30 karolherbst: but why does it crash the system?
17:30 karolherbst: it should rather print an error ;)
17:35 imirkin: joi: any particular idea *which* buffer?
17:36 joi: hard to tell
17:37 joi: it's used as source to GK104_COPY
17:37 imirkin: that's a resource upload
17:37 imirkin: what writes to it in the first place?
17:38 joi: it seems to be filled by cpu
17:38 imirkin: interesting.
17:38 imirkin: so it's a texture upload
17:39 imirkin: and we end up freeing the buffer before the copy executes?
17:39 joi: yes, and ioctl does not even reference it
17:40 imirkin: well certainly nve4_m2mf_transfer_rect looks right
17:40 imirkin: as does nve4_m2mf_copy_linear
17:40 imirkin: do you have the exact copy commands used?
17:40 joi: the trace is compressing, but I'll copy&paste parts of the trace which seem relevant
17:41 imirkin: i wonder if that whole approach isn't quite right
17:41 imirkin: since it never kicks the buffer out
17:41 imirkin: although iirc i've thought it might be bad before, and ended up deciding it was ok
17:43 joi: http://paste.ubuntu.com/12495786/
17:45 imirkin: joi: well, both buffers appear to be there... perhaps the presumed gpu_start is parsed wrong?
17:45 imirkin: it certainly has a src and dst buffer
17:46 joi: address 0x7bf5000 belongs to handle 1183
17:46 joi: which is not referenced by ioctl
17:47 joi: but is used in the command stream
17:47 imirkin: what about the dst address?
17:50 joi: buffer exists
17:50 imirkin: is the bo handle == gem handle?
17:51 imirkin: i wonder if there's a resource reference missing somewhere
17:51 joi: hmm
17:51 imirkin: since we don't kick the thing out
17:51 imirkin: we end up destroying the resource
17:51 imirkin: and then eventually it gets kicked out
17:51 imirkin: and the resource is already deleted
17:52 imirkin: i bet sticking a PUSH_KICK in those transfer functions will fix it right up
17:59 joi: gotta go, i'll upload the trace in the morning
18:00 imirkin: k see ya
18:00 joi: good night
18:07 karolherbst: is anybody of you able to see the power consumption of your nvidia gpu?
18:10 imirkin: nope
18:10 imirkin: i think mupuf has some though
18:10 imirkin: iirc that INA one was supported actually
18:10 imirkin: maybe i'm getting the models mixed up though
18:10 karolherbst: I have the same as mupuf have
18:10 karolherbst: with his pwr_read tool I can read the power consumption out, no problem
18:10 karolherbst: so there is a /dev/i2c file with the sensor
18:10 imirkin: but it's not hooked up in the kernel?
18:11 karolherbst: the tool uses the i2c interface
18:11 imirkin: right
18:11 imirkin: i mean it's not hooked into hwmon or whatever
18:11 karolherbst: mhhh
18:11 karolherbst: the temperature is hooked up with hwmon?
18:11 karolherbst: I mean, sensors displays the temp of my gpu
18:12 karolherbst: imirkin: any idea how to hookup such devices with hwmon?
18:12 karolherbst: didn't finy any references in the nouveau code for this :/
18:12 imirkin: nope
18:15 karolherbst: but it should be anywhere in subdev/therm
18:16 karolherbst: ohhh maybe not
18:16 karolherbst: because it doesn't make sense
18:16 karolherbst: nouveau_hwmon.c ...
18:17 karolherbst: silly me
18:18 karolherbst: okay, there is temp and fan
18:18 karolherbst: but no power consumption
18:19 karolherbst: ohhh okay, makes sense
18:40 karolherbst: imirkin: nouveau could also export voltages through hwmon :/
18:40 imirkin: could
18:49 karolherbst: imirkin: "power1: 10.00 uW" :)
18:49 karolherbst: I think I figured it out how to do that
18:50 imirkin: cool
18:50 karolherbst: the interface is messy though
18:50 karolherbst: because it's name based
18:50 karolherbst: you add something named "power[1-*]" and then the tools may think it is power related :D
18:50 karolherbst: https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface
18:52 karolherbst: okay, now the next step: "EXTDEV 1: type 0x4e [INA3221] at 0x80 defbus 0 unk02_5 2 unk03 0x02" and which of those: " 0: min = 1 mW, avg = 80000 mW, peak = 80000 mW (unkn12 = 1)" or "1: min = 1 mW, avg = 80000 mW, peak = 80000 mW (unkn12 = 0)"
18:53 karolherbst: defbus tells us which Power budget?
18:53 karolherbst: unk02_5 2 might be accuracy? "2: min = 1 mW, avg = 8000 mW, peak = 8000 mW (unkn12 = 0)"
18:54 karolherbst: mhh, that would be a really bad accurcy
18:55 karolherbst: but this hwmon interface looks awesome
18:55 karolherbst: we could put everything out there
18:55 karolherbst: memory voltage, core voltage, other votlages...
19:07 karolherbst: imirkin: seems like that I can maybe control my fans thorugh ACPI method calls :/
19:08 imirkin: seems very likely
19:19 karolherbst: mhh
19:19 karolherbst: 590 methods
19:19 karolherbst: that isn't "that" much
19:30 karolherbst: ha "CPU Fan Speed" found inside the acpi dump
19:30 karolherbst: but no gpu fan :/
19:39 karolherbst: ui, my EC is a PNP0C09