01:45 hakzsam: imirkin, pushed
03:00 hakzsam: imirkin, I have a new series for nv50, but I need to run a full piglit test http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nv50_query_header
03:29 karolherbst: mupuf: seems like this C state thingy is a hardware bug :/
03:29 karolherbst: this also happes with the acpi driver
03:29 mupuf: first bug I ever solved for myself in linux
03:29 mupuf: forcing linux to never go to the C3 state because the bios would freak out :D
03:29 karolherbst: :D
03:30 karolherbst: well, the C states are working for me
03:30 karolherbst: 7 of the 8 cores are in C7-HSW state
03:30 karolherbst: and one not
03:30 karolherbst: and this usually happens after suspend
03:30 pmoreau: karolherbst: Still need that testing (glxinfo + cat vgaswitcheroo/switch)?
03:30 karolherbst: pmoreau: no, I figured the bug out
03:30 pmoreau: Cool!
03:31 karolherbst: it is caused by libdrm_intel but it's at fault
03:31 karolherbst: *not
03:31 karolherbst: mupuf: turbostat: https://gist.github.com/karolherbst/bb806094d6ea7abe0c10
03:33 karolherbst: it is kind of ugly, because I never hit deeper package power state in this case
03:36 LocoMan: hi guys
03:39 karolherbst: hi
03:39 LocoMan: Maybe someone can help me, I use Debian 8 with i3wm. I tried to install Nvidia legacy driver for my GTX 460M. So I start to boot in recovery mode to free xorg server, I ran the NVIDIA.run wich told me that 'nouveau driver' was installed in my system. So the installer told me that it can try to disable it in order to be able to install NVIDIA driver. But it fails and now I don't have any graphic driver
03:40 karolherbst: mupuf: where do I report hardware bugs? :D
03:40 LocoMan: I know that nvidia launcher add some file in a certain folder (I read but not remember...) and I just have to erase them..
03:40 karolherbst: LocoMan: nope only nouveau here sorry ;)
03:40 LocoMan: YES, but I want to recover nouveau driver :)
03:41 karolherbst: ohhh
03:41 karolherbst: LocoMan: I bet there are some libgl symlinks wrongs
03:41 karolherbst: LocoMan: update-alternatives
03:41 LocoMan: hum, how can I check it ?
03:42 karolherbst: run update-alternatives
03:42 LocoMan: can you tell where the nouveau driver files are stored ?
03:42 karolherbst: LocoMan: doesn't matter, update-alternatives should take care of this
03:42 karolherbst: there are two or three options related to graphics
03:42 mupuf: karolherbst: to your laptop manufacturer
03:42 LocoMan: this command need some parameters
03:43 mupuf: but first, try updating the bios
03:43 LocoMan: the bios ? Sorry ?
03:43 karolherbst: LocoMan: not for you
03:43 LocoMan: ^^
03:43 karolherbst: mupuf: I used recent microcode
03:43 karolherbst: *use
03:43 karolherbst: also the cpu isn't on the board itself, but in a socket
03:44 karolherbst: and warrenty is gone already :D
03:44 mupuf: you really think the bug is in the cpu? I doubt that very highly
03:44 mupuf: especially since it worst after a cold boot
03:44 karolherbst: cold boot is fine, suspend isn't
03:45 karolherbst: maybe some issue in the suspend code?
03:45 mupuf: possible that the problem could be linux-related
03:45 karolherbst: okay, will create a new kernel bug for this then
03:45 mupuf: go check it out!
03:48 karolherbst: I also only enter pc3 state with 30%, but I somehow now what causes this (ethernet driver and audio driver together somehow)
03:48 karolherbst: but I also heard it is like hardware broken on haswell :D
03:49 LocoMan: I tried to follow this https://wiki.ubuntu.com/X/Troubleshooting/VideoDriverDetection#Problem:__Need_to_fully_remove_-nvidia_and_reinstall_-nouveau_from_scratch
03:49 LocoMan: but the commands tells me that I have not installed Nvidia or nouveau driver
03:50 karolherbst: LocoMan: nouveau isn't a thing you install usually, there is a nouveau mesa driver and some deps, but that's it
03:50 karolherbst: ohh wait
03:50 karolherbst: there is also the ddx :D
03:50 karolherbst: wait
03:50 karolherbst: these commands look stupid
03:51 LocoMan: ?? The only things I know is that nouveau driver was installed, nvidia driver tried to disable it by creating some files.
03:51 karolherbst: LocoMan: update-alternatives is the important part
03:51 karolherbst: especially: update-alternatives --config gl_conf
03:52 LocoMan: I tried, no result
03:52 karolherbst: and sudo update-initramfs -u
03:52 karolherbst: LocoMan: did you set it to /usr/lib/mesa/ld.so.conf?
03:52 LocoMan: error: no alternative for gl_conf
03:52 LocoMan: wait
03:52 LocoMan: no
03:53 karolherbst: what does update-alternatives --display gl_conf give you
03:53 LocoMan: I don't have /usr/lib/mesa
03:53 LocoMan: It displays the things I told you
03:54 LocoMan: 12:52:48 LocoMan | error: no alternative for gl_conf
03:54 karolherbst: then install libgl1-mesa-glx
03:54 karolherbst: and libgl1-mesa-dri
03:54 LocoMan: hum, 'mesa is already the latest version'
03:55 karolherbst: fun
03:55 LocoMan: yes :)
03:55 karolherbst: no clue then, seems to be a distribution problem or something, don't know
03:56 LocoMan: I think there are there, installed, but just disabled
03:56 karolherbst: I blame the distributions to make it so hard though :D
03:56 LocoMan: they*
03:56 karolherbst: LocoMan: maybe try --reinstall
03:56 LocoMan: ok
03:56 towo`: update-alternatives --display glx
03:56 towo`: gl_conf is not a valid alternativbe
03:57 LocoMan: towo`: no alternative for glx
03:57 LocoMan: reinstallation is in process
03:58 LocoMan: done
03:58 towo`: LocoMan, oh i see, you have played with the run-installer
03:58 LocoMan: maybe
03:58 towo`: then you on your own
03:58 LocoMan: wich means ?
03:58 towo`: this installer breaks many things in debian because of overwriting systemfiles
03:59 towo`: and at important thing, it breaks the alternaives system
03:59 LocoMan: oh ok. I knew that I shouldn't trust nvidia
04:00 LocoMan: but, I'm so disapointed, because the run-installer told me some important things (which files modified to disable nouveau driver) and HOW TO RECOVER nouveau driver.....but I forget how
04:00 karolherbst: LocoMan: just use distribution specific packages
04:01 LocoMan: I did
04:01 karolherbst: they usually do things better
04:01 karolherbst: ?
04:01 LocoMan: or not ^
04:01 karolherbst: run-installer is not distributions specific
04:01 LocoMan: oh ok
04:01 karolherbst: apt-get install is :p
04:01 karolherbst: if you did it through apt-get it's fine
04:01 karolherbst: if not, no
04:01 LocoMan: yes it's right sry
04:02 LocoMan: so maybe if i re-run the installer, it will told me how to disable nouveau driver :p
04:02 LocoMan: "re-desable" precisely
04:02 pmoreau: LocoMan: Look in /etc/modprobe.d/ for some .conf file
04:02 LocoMan: !!! it's there
04:03 pmoreau: And remove/add the line "blacklist nouveau"
04:03 LocoMan: sorry, I remember that something have been done there
04:03 pmoreau: nvidia probably added a nouveau.conf file containing "blacklist nouveau"
04:03 karolherbst: mupuf: funny thing: it get deeper Cstates after a warm reboot too
04:04 LocoMan: root@debian-G73SW:/home/locoman# ll /etc/modprobe.d/
04:04 LocoMan: fbdev-blacklist.conf nvidia-installer-disable-nouveau.conf
04:04 LocoMan: modesetting.conf
04:04 LocoMan: there it is :
04:04 LocoMan: !
04:04 karolherbst: :D
04:04 LocoMan: So I think I should erase nvidi-installer-disable-nouveau.conf ?
04:05 pmoreau: Or remove/comment the line "blacklist nouveau" inside that file
04:05 karolherbst: remove the file
04:05 LocoMan: # generated by nvidia-installer
04:05 LocoMan: blacklist nouveau
04:05 LocoMan: options nouveau modeset=0
04:05 LocoMan: the content ^
04:05 karolherbst: remove everything "# generated by nvidia-installer"
04:05 pmoreau: Ok, and the se:D
04:05 karolherbst: :D
04:05 pmoreau: s/se/second
04:05 pmoreau: line
04:05 LocoMan: ok
04:06 LocoMan: now, maybe I juste need to reboot ?
04:06 LocoMan: just*
04:06 karolherbst: maybe
04:06 LocoMan: (I'm french anyway)
04:06 karolherbst: ohh wait
04:06 karolherbst: no
04:06 karolherbst: you need to update your initramfs
04:06 LocoMan: ok, so, how ?
04:07 karolherbst: there are commands
04:07 karolherbst: I am not into initramfs so I can't say for sure, but something like update-initramfs or something
04:07 pmoreau: I guess I never used initramfs
04:07 towo`: update-initramfs -u
04:08 pmoreau: Apparently I do, but never needed to update it (apart from when I update the kernel)
04:08 LocoMan: woow it add a lot of files
04:08 LocoMan: It's done ;)
04:09 pmoreau: LocoMan: Just to make sure: what is left in that file?
04:09 LocoMan: I don't understand
04:09 pmoreau: In the nvidia-installer-disable-nouveau.conf
04:10 LocoMan: nothing I erased it :D
04:10 pmoreau: Ok, great! :-0
04:10 pmoreau: * :-)
04:10 LocoMan: so, let's go reboot
04:14 LocoMan: wwooooot it worked
04:14 LocoMan: thx a lot guys :)
04:15 LocoMan: Now, maybe I can update nouveau driver, if it's needed (I'm unable to run steam, I thought it's graphics problems)
04:16 karolherbst: LocoMan: dmesg and X log then
04:17 LocoMan: hum, command not found
04:17 pmoreau: Latest version of the kernel is 4.2.3, and latest version of Mesa is 11.0.3 iirc
04:17 karolherbst: dmesg?
04:17 LocoMan: sry, typo
04:17 LocoMan: [ 12.302920] r8169 0000:04:00.0: firmware: failed to load rtl_nic/rtl8168e-2.fw (-2)
04:18 LocoMan: the only error
04:18 pmoreau: What does Steam complain about?
04:18 karolherbst: LocoMan: just paste it somewhere on the web
04:18 karolherbst: maybe there is something odd, maybe not
04:18 LocoMan: euh, can you told me the pipe to put it in a file ?
04:18 pmoreau: dmesg > some_file
04:19 LocoMan: lol so easy thx
04:19 pmoreau: ;-)
04:20 pmoreau: You can also do `dmesg | xclip` to have it directly into X clipboard
04:20 towo`: or install libapp-nopaste-perl
04:20 towo`: then dmseg | nomaste
04:20 towo`: grr
04:20 towo`: then dmseg | nopaste
04:21 LocoMan: it's better
04:23 LocoMan: xclip not working :(
04:23 pmoreau: LocoMan: But which error message does Steam gives you?
04:23 pmoreau: Do you have it installed?
04:24 LocoMan: http://pastebin.com/JXeakZbq
04:24 LocoMan: my bad, I tried dmesg > xclip --'
04:24 towo`: LocoMan, you know that steam is a 32bit app?
04:25 LocoMan: towo`: yes, so I add architecture i386
04:25 towo`: LocoMan, that means, you also need all gl related libs in 32bit too
04:25 towo`: LocoMan, especialy libgl1-mesa-glx:i386
04:25 LocoMan: and, so, I don't have them ?
04:25 towo`: who knows?
04:26 LocoMan: I have them ^^
04:26 towo`: you haven't told the error which steam gives you
04:26 LocoMan: (just checked)
04:26 karolherbst: LocoMan: what is the error you get when starting steam
04:27 LocoMan: there are no error
04:27 LocoMan: nothing start
04:27 pmoreau: Start Steam from a terminal
04:27 pmoreau: You wil get some nice mesages that way
04:27 pmoreau: s/mesages/messages
04:27 karolherbst: mhh usually steam complains when some lib is missing :/
04:27 LocoMan: how to ?
04:28 karolherbst: steam in the console
04:28 pmoreau: by running steam
04:28 pmoreau: like you did for dmesg
04:28 LocoMan: Yes I had this problem on an other pc, where there was no nvidia and no amd graphic card...
04:28 LocoMan: juste chip, but it's not the problem there ^^
04:28 LocoMan: Installing breakpad exception handler for appid(steam)/version(0)
04:28 LocoMan: libGL error: unable to load driver: nouveau_dri.so
04:29 LocoMan: libGL error: driver pointer missing
04:29 LocoMan: libGL error: failed to load driver: nouveau
04:29 LocoMan: libGL error: unable to load driver: swrast_dri.so
04:29 LocoMan: libGL error: failed to load driver: swrast
04:29 pmoreau: Ok
04:29 LocoMan: oops I forget 2 lines : locoman@debian-G73SW:~$ steam
04:29 LocoMan: Running Steam on debian 8 64-bit
04:29 LocoMan: STEAM_RUNTIME is enabled automatically
04:29 pmoreau: Reinstall the 32-bit libraries for mesa and mesa-driver
04:30 pmoreau: (Maybe the 64-bit ones as well as NVIDIA might have screweed them)
04:30 pmoreau: s/screweed/screwed
04:31 LocoMan: done
04:31 LocoMan: reinstalled libgl1-mesa-glx:i386
04:32 LocoMan: same probleù
04:32 LocoMan: same problem
04:34 karolherbst: maybe reinstall libgl1-mesa-dri too
04:34 karolherbst: libgl1-mesa-dri:i386
04:34 karolherbst: I don't think the drivers are in teh glx package
04:35 LocoMan: impossible to find package
04:35 karolherbst: :O
04:35 karolherbst: https://packages.debian.org/jessie/libgl1-mesa-dri
04:35 pmoreau: And if you run `LIBGL_DEBUG=verbose steam`?
04:35 pmoreau: That will tell us where it is looking for the drivers
04:36 karolherbst: LocoMan: also could you give us "ls /usr/lib/i386-linux-gnu/dri/"
04:37 LocoMan: locoman@debian-G73SW:~$ ls /usr/lib/i386-linux-gnu/dri/
04:37 LocoMan: dummy_drv_video.so i965_dri.so kms_swrast_dri.so nouveau_drv_video.so nvidia_drv_video.so r300_dri.so r600_drv_video.so radeonsi_dri.so s3g_drv_video.so vdpau_drv_video.so
04:37 LocoMan: i915_dri.so i965_drv_video.so nouveau_dri.so nouveau_vieux_dri.so r200_dri.so r600_dri.so radeon_dri.so radeonsi_drv_video.so swrast_dri.so vmwgfx_dri.so
04:37 karolherbst: okay, that looks good
04:37 karolherbst: then steam is messing up or the environment
04:38 LocoMan: for steam verbose : http://pastebin.com/ySvLmzZe
04:39 karolherbst: GLIBCXX_3.4.20 :D
04:39 karolherbst: not the fun starts
04:39 karolherbst: *now
04:39 LocoMan: what ?
04:41 karolherbst: version of libc6-i386
04:41 karolherbst: you may want to update this pacakge
04:42 karolherbst: ohh wait
04:42 LocoMan: hum, not installed yet ^^
04:42 pmoreau: Just remove home/locoman/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6
04:42 karolherbst: this is libstc++
04:42 karolherbst: ohhhh eight, stupid steam runtime :/
04:42 pmoreau: It will use the system version and be fine
04:43 LocoMan: so I rm the file or not ?
04:44 pmoreau: yes
04:44 LocoMan: done
04:44 LocoMan: WOOOOOOOOOT
04:44 pmoreau: ;-)
04:44 pmoreau: Because it uses the libstc++ installed on you system
04:45 LocoMan: I think I'll comeback more often in your channel :p
04:45 pmoreau: Which is not super-crazy-old like the one that Steam packages
04:45 pmoreau: LocoMan: Beware that you will need to remove that file each time after Steam is updated (cause it will redownload it)
04:46 LocoMan: oh god
04:47 LocoMan: lol, you're right, steam juste update and is broken again x)
04:47 pmoreau: Oh, and you probably want to install that texture package
04:47 pmoreau: :-D
04:47 pmoreau: But you know how to fix it ;-)
04:48 karolherbst: he won't get much perf with nouveau anyway sadly :/
04:48 karolherbst: but
04:48 karolherbst: it will change!
04:48 karolherbst: some day
04:49 pmoreau: LocoMan: Make sure you have that package installed "libtxc_dxtn", as well as its 32-bit counter-part
04:49 pmoreau: Otherwise you will experience missing textures in some game
04:49 LocoMan: what are you tring to say karolherbst ?
04:51 LocoMan: So, if I understand, I should install legacy driver ? :p
04:51 pmoreau: Which GPU do you have?
04:51 LocoMan: gtx 460m
04:51 LocoMan: it's no so important to me if I can't launch games
04:51 pmoreau: Hum, Fermi
04:52 LocoMan: yes
04:52 pmoreau: You will be able to launch games, just they might run quite slow compared to NVIDIA driver
04:52 pmoreau: Depends on which clocks your card boots by default
04:53 pmoreau: karolherbst: Didn't you investigate Fermi reclocking and had some success?
04:54 LocoMan: ok
04:54 LocoMan: but NVIDIA driver not installing properly
04:55 LocoMan: Ok, I need prepare my meal :p
04:55 LocoMan: so thx you a lot, and have a good day guys !
04:56 LocoMan: bye bye
04:56 pmoreau: Same to you!
04:57 mupuf: karolherbst: is it considered crazy to look for the power consumption value and other parameters in the memory of pdaemon?
04:58 mupuf: because this fucking driver does not want to let me know what is the power consumption
04:58 mupuf: and it always polls 2 lanes of the INA3221
04:58 mupuf: never 3, never 1
04:58 mupuf: whaetever I write in the vbios
05:00 karolherbst: mhhh
05:01 karolherbst: strange
05:01 mupuf: yes, as you say
05:02 mupuf: so, let's go and check in memory if I can find something!
05:08 karolherbst: :D
05:08 karolherbst: that's sounds like a lot of fun
05:09 mupuf: let's hope that nvidia keeps the "RAM" in the cache
05:09 karolherbst: mupuf: maybe reading out the power consumption is just broken on non quadro cards and they didn't care fixing it
05:09 mupuf: and no in a BO
05:09 mupuf: it is not broken, they just want people to buy more expensive gpu
05:10 karolherbst: okay :D
05:11 mupuf: if it were broken, they would not use it to enforce a power cap
05:16 karolherbst: okay, makes sense
05:24 karolherbst: mupuf: any steps how I should add reading out power consumption in ezbench or shall I just hack in something :D
05:24 mupuf: yes, I definitely do have a view on this
05:24 mupuf: opinion*
05:25 karolherbst: k
05:25 mupuf: the best way would be to create a launcher in python that will both run the command and start the monitoring
05:25 mupuf: when the benchmark exits, we stop the acquisition and exit
05:26 karolherbst: okay, so first I have to write a seperate daemon anyway
05:26 mupuf: why?
05:26 karolherbst: ohh it sound like it
05:28 mupuf: no, it is a launcher
05:29 mupuf: monitor_app.py list of metrics -- command to run with its arguments
05:29 mupuf: this launcher should also have the ability to dump information about the environment
05:29 mupuf: like, the list of libraries used, etc
05:30 mupuf: but that's for later
05:31 karolherbst: where is monitor_app.py ?
05:32 karolherbst: mupuf: or did you mean check_resource_usage.py ?
05:32 mupuf: it does not exist
05:32 mupuf: this is what we want to write
05:33 karolherbst: ohh okay
05:33 karolherbst: so I create a monitor_app.py file inside utils and hack the stuff in
05:33 mupuf: sounds good!
05:34 karolherbst: well, and I get to learn python at the same time, sounds like fun
05:34 karolherbst: mupuf: I guess monitor_app will be a thread, which can be started, stoped, paused whatever
05:35 karolherbst: mupuf: which python version is minimum? 3.3, 3.4?
05:35 mupuf: I have to admit I do not pay too much attention to that beyond writing the code using python3
05:35 karolherbst: :D
05:36 karolherbst: okay
05:36 karolherbst: then I won't either
05:36 karolherbst: I just use what is easy and works with my python version
05:36 karolherbst: which is 3.4
05:36 mupuf: if a class landed in python and you want to use it, do it
05:36 mupuf: let's not waste time for outdated distros
05:36 mupuf: or do any poor reimplementation of someone else's work
05:37 mupuf: what I try to pay attention to is the list of dependencies on external programs when writing in bash
05:37 karolherbst: okay
05:37 mupuf: that part is important because I will need to document everything needed when things settle down!
05:37 karolherbst: I won't need external tools though
05:38 mupuf: probably not, no
05:38 RSpliet: mupuf: HA
05:38 RSpliet: "when things settle down"
05:38 karolherbst: mupuf: do you think it also makes sense to monitor gpu usage on nouveau with the pdaemon counters?
05:38 mupuf: definitely, yes
05:38 karolherbst: I could add this too after powr consumption
05:38 karolherbst: k
05:38 karolherbst: then we may have to think about a nice debugfs/sysfs interface
05:39 RSpliet: noble, but I think that'll only happen when the earth ceases to exist
05:39 mupuf: RSpliet: hehe, well, they will have to very quickly, because I will stop working full time on this in about a week. After that, I will mostly manage it and make it work for our internal usage
05:39 mupuf: which means, documenting!
05:39 karolherbst: :D
05:40 karolherbst: so, how to write classes in python :D
05:40 pmoreau: Oh! assignSlots: "driver callback to assign input/output locations"
05:40 pmoreau: I should have a look at that!
05:40 mupuf: karolherbst: try to keep in mind that there are multiple drivers on earth
05:40 karolherbst: I know
05:41 mupuf: so, it has to be modular
05:41 mupuf: basically, collect anything that can help us understand what is happening
05:42 mupuf: cpu usage, engine usages, pcie usage, memory usage, power, temperature, fan speed
05:42 karolherbst: I was thinking about having a simply monitor class with like three methods: startMonitor(POWER | USAGE | ....), stopMonitor, getResults. and dispatch the stuff internally
05:42 mupuf: everything that is fast to collect
05:42 karolherbst: or shall I just collect everything
05:42 karolherbst: :D
05:42 mupuf: no, we need to let user decide
05:42 karolherbst: okay
05:43 mupuf: the trick is that we will need to wait to know what driver to use by actually running the app and waiting for the libgl to spit out what it uses
05:44 karolherbst: no glxinfo call before?
05:44 mupuf: how could you trust it?
05:44 karolherbst: or might that give us fals results
05:44 karolherbst: mhh right
05:44 mupuf: but we need to keep the overhead as low as possible
05:45 karolherbst: maybe pausing the process until we are ready may work?
05:45 karolherbst: but it shouldn't take a lot of time either
05:45 karolherbst: so, meh
05:45 karolherbst: okay
05:46 karolherbst: so basically I do as much as possible inside the ctor or init of the moitor class
05:46 mupuf: well, the problem is that we also would miss the init time
05:46 karolherbst: and add a method to feed it with additional information from the app
05:46 mupuf: there is always the possibility to run the app a first time until we get all the info
05:46 mupuf: kill the app, set up everything and run the app again
05:47 mupuf: this time, we would just check that it indeed uses the same libraries
05:47 mupuf: but at least, we would not miss the init
05:47 karolherbst: why should it use different libraries?
05:47 mupuf: and then we can keep the configuration in a cache
05:47 mupuf: reasons?
05:47 mupuf: like, if they try to react to a crash
05:48 mupuf: but forcing using a system library or something
05:48 karolherbst: ohhh
05:48 mupuf: some benchmark dlopen libraries at run time
05:48 mupuf: so...
05:48 karolherbst: then we kill with -TERM and hope for the best :D
05:48 karolherbst: :p
05:49 karolherbst: okay, we can't trust the app, I get it
05:51 mupuf: well, we can always have an option to say : trust the app and use your cache
05:51 mupuf: so as, cpu-bound tasks can be run with it
05:52 mupuf: or we can detect that a task is cpu-bound and just start trusting the app to reduce the variance of the result. But I am dubious that we can make this work easily
05:53 karolherbst: mupuf: in which class shall I use my Monitor class then=
05:53 karolherbst: Ezbench ?
05:54 karolherbst: ohh wait, no, this is the application class
05:54 mupuf: no, create an external tool
05:54 mupuf: it will be called from a profile
05:56 karolherbst: and on term it should stop monitoring and print the results?
05:57 mupuf: it should write the results to a csv file, based on a parameter
05:58 karolherbst: okay
05:58 mupuf: as in, the parameter is tell you which file to write to
05:58 mupuf: one file for the environment used
05:58 mupuf: and one for the metrics
06:00 karolherbst: what kind of environment, like which card/driver was recognized and which files/interface were polled to get the data?
06:01 mupuf: environment: cpu, chipset, bios version, which card/driver (version included), librariries used
06:02 mupuf: x or wayland, compositor
06:02 mupuf: and that should be it
06:02 mupuf: I am not asking you to add that, just keep that in mind when designing it
06:02 karolherbst: :D
06:02 karolherbst: okay
06:03 karolherbst: if I desing it as an too, it still has to somehow know which card is getting used, so it also needs a parameter for this
06:11 mupuf: no
06:11 mupuf: it should find it by itself
06:12 karolherbst: but how can it know which card is getting used in the benchmark?
06:12 karolherbst: if there are many
06:12 karolherbst: or shall just all be monitored?
06:14 mupuf: nope, you need to monitor the right one, and we solved this problem yesterday, didn't we?
06:15 mupuf: LBGL_DEBUG=verbose app --> works for mesa
06:15 mupuf: strace -e open -- app --> works for nvidia
06:16 karolherbst: yeah I know, but if I write this as a tool, which get's called in the launcher script, I usually don't know what benchmark is getting executed. Maybe I am confused by the design though :/
06:18 mupuf: everything needs to be integrated
06:18 mupuf: and yes, it is not a trivial design
06:19 mupuf: ok, let's start simple then
06:19 mupuf: first, run glxinfo --> extract all the parameters
06:19 mupuf: then setup everything and run the benchmark
06:20 mupuf: I will add support for checking the actual environment later
06:20 mupuf: that should work in most cases
06:26 john_cephalopoda: Hey
06:36 mupuf: john_cephalopoda: hey
06:36 mupuf: just so you know, it is not really nice to say just hello on irc and expect answers :D
06:37 mupuf: if you have any questions, say hello and your question immediatly after
06:37 john_cephalopoda: :P
06:37 john_cephalopoda: I'm not really sure if I have questions.
06:38 karolherbst: :D
06:39 john_cephalopoda: I got a program that complains that "OpenGL extension GL_EXT_texture_compression_s3tc not supported", but I am not sure if that is a problem with my mesa or with my nouveau. So I joined here precautionary, in case that it is some nouveau thing. :P
06:39 mupuf: well, you are on the right channel for nouveau
06:39 mupuf: you need to install an external library
06:40 karolherbst: mupuf: I somehow like python, but I never got time to actually code something usefull in it :D
06:40 mupuf: john_cephalopoda: http://dri.freedesktop.org/wiki/S3TC/
06:40 mupuf: karolherbst: I hate scripts, but you gotta accept that for some tasks, they are truely more efficient of the developer's time!
06:40 karolherbst: mupuf: though on some distributions they now use s2tc instead of s3tc
06:40 mupuf: python is still low-level enough, so i prefer this one
06:42 john_cephalopoda: Thanks
06:44 karolherbst: mhh ben seems to be pretty busy :/ I hope he manage to pull in the gddr5 fix and maybe also the pcie stuff :/
07:02 karolherbst: mupuf: I like that it is that easy to parse arguments in python :D
07:15 hakzsam: imirkin, well actually, there are some regressions since the compute support is enabled by default ... some piglit interpolation tests fail now... I'm sorry but I don't know why I didn't see them because I ran a full piglit. Anyway, I'm working on it and if I don't find a fix quickly I'll revert that patch
07:16 hakzsam: imirkin, I suspect that uploading const parameters for compute overwrite the 3d ones
07:17 Rovanion: Hi, it seems like my GTX 570 ever clocks up from the idle 50MHz level. Is this to be expected with the nouveau driver?
07:18 hakzsam: imirkin, the cool stuff is that now I have a real use case which fails :)
07:19 hakzsam: imirkin, for example, interpolation-flat-gl_BackColor-flat-vertex.shader_test
07:22 karolherbst: Rovanion: sadly yes
07:23 karolherbst: Rovanion: and for fermi you can't even reclock manucally yourself :/
07:23 karolherbst: but we try to work on that
07:24 Rovanion: karolherbst: Okey. So I've never done work on the linux graphics stack, but I've been programming for the last seven years now. Is this something which you could imagine a newcomer going in and being able to solve?
07:25 Rovanion: With some interest and motivation - I gotta get nouveau going since the nvidia driver crashes. That or installing Windows again.
07:25 karolherbst: Rovanion: yeah, some stuff I am pretty new to nouveau myself
07:26 karolherbst: Rovanion: ask RSpliet what you could do fermi related, he started to work on that some days ago
07:26 Rovanion: RSpliet: Got any pointers for me?
07:26 karolherbst: Rovanion: bad thing though is, that you sometimes need the binary driver to verify things
07:27 karolherbst: especially for reclocking it is critical to know what the blob is doing
07:27 Rovanion: Well, the binary isn't completely unusable, it's just unstable.
07:27 karolherbst: what means "unstable"?
07:27 karolherbst: X crashes?
07:28 Rovanion: Specifically: I can sometimes play two games of dota 2 before it crashes, sometimes I don't get to start one.
07:28 karolherbst: ohh :/
07:29 karolherbst: Rovanion: maybe you want start by upgrading your kernel and get a local nouveau module build and deployed
07:29 Rovanion: X locks up and forces a reboot of the system.
07:29 karolherbst: Rovanion: this is the latest patch regarding fermi reclocking: https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/6a6c82ed9a2c693041aa474fe4441be7fde121aa
07:29 karolherbst: it is there to calculate the memory timings
07:30 karolherbst: what you could do is, try to get the input data the blob is using
07:30 karolherbst: throw them into this algorithm
07:30 karolherbst: and verify if the results are the same
07:30 karolherbst: for that you need also envytools installed
07:31 Rovanion: So with the latest kernel you mean 4.2.3?
07:31 karolherbst: it is good that you have a gddr5 card, because RSpliet also used one
07:31 karolherbst: Rovanion: should work
07:31 karolherbst: Rovanion: then you should fetch this git repository: http://cgit.freedesktop.org/~darktama/nouveau/
07:32 karolherbst: compile it, install it and check if your compiled version get used
07:32 karolherbst: you can also try to work on the OpenGL side, but I think for fermi it makes a lot more sense to help reclocking the cards
07:35 Rovanion: The nouveau repo, does it have any ./configure or anything like that which can list which packages I'm missing to copmile it?
07:36 karolherbst: it is a kernel module
07:36 karolherbst: you just compile it
07:36 karolherbst: cd drm
07:36 karolherbst: make
07:36 karolherbst: all you need is the header package of your kernel
07:36 Rovanion: Still has dependencies. apt-get build-dep solved some but not all.
07:36 karolherbst: the kernel is the only one
07:37 karolherbst: you need to go into drm first
07:37 karolherbst: or make -C drm
07:37 Rovanion: Missing soc/tegra/fuse.h.
07:37 karolherbst: you are on arch, aren't you?
07:37 Rovanion: Nope, ubuntu.
07:38 karolherbst: uhh, ubuntu also misses this file?
07:38 karolherbst: Rovanion: open drm/nouveau/include/nvif/os.h
07:38 karolherbst: remove #include <soc/tegra/pmc.h>
07:38 karolherbst: this file is only important for arm systems anyway
07:38 karolherbst: but usually this header is part of the kernel in all cases
07:38 karolherbst: but some seems to not include it
07:39 Rovanion: Continued to build now with both the tegra headers removed.
07:39 karolherbst: both?
07:41 Rovanion: Yeah, there were two tegra headers right after one another, both were missing on my system.
07:41 karolherbst: ohh okay
07:41 Rovanion: Getting this now though: Some warning being treated as an error: http://paste.debian.net/316472/
07:41 karolherbst: ohh right the newest nouveau sources include both :D
07:42 karolherbst: it uses the 3.13 kernel
07:42 karolherbst: that won't work
07:42 karolherbst: which kernel are you currently running?
07:42 Rovanion: 3.13, haven't installed 4.2 yet.
07:42 karolherbst: you need to run 4.2 before this works
07:42 Rovanion: Right
07:43 karolherbst: I mean you can also compile against 4.2, but then you can't use the module
07:43 karolherbst: so you need to install and boot into 4.2 anyway
07:52 Rovanion: The kernel git repo is quite large :D
07:55 karolherbst: Rovanion: is there no 4.2 package?
07:55 karolherbst: and usually you don't build the kernel from git
07:56 Rovanion: karolherbst: Yeah, I'm getting a prebuilt generic package. But I'm getting the kernel tree anyways, got some fun to doo there too.
07:56 karolherbst: mhhh why do you need the kernel tree?
07:57 karolherbst: ahhh
07:57 karolherbst: I see
07:57 karolherbst: --depth 1 helps
07:57 karolherbst: you can't bisect then or see the history, but it is faster
07:58 Rovanion: Because this is taking an hour. Still, I probably want to check out the latest stable tag at some point.
08:00 karolherbst: if you don't care about history, add "--depth 1" to the git clone command
08:21 hakzsam: imirkin, well, my hypothesis seems to be correct, binding a CB compute overwrites the 3D state and we need to re-bind all the 3D const buffers. We already do this just after uploading input params and launching the grid
08:22 hakzsam: I have a patch which seems to fix those interpolation tests
08:31 hakzsam: imirkin, http://hastebin.com/avuticiruz
08:31 hakzsam: I'm running a full piglit run to confirm the fix
08:34 hakzsam: in my opinion, that "re-bind all the 3D const bufs" is somehow a workaround, but heh
08:35 karolherbst: mupuf: can you think of any reason why the nvidia devtmpfs files are opened, but not used for GL?
08:39 mupuf: devtmpfs?
08:40 mupuf: karolherbst: ^^
08:40 karolherbst: the name of the fs usually mounted at /dev :p
08:43 karolherbst: I have only a handfull of situations I can test if my algorithm for detecting the gpu/driver used and the pci slot of the used card
08:46 mupuf: oh, sorry
08:51 mupuf: I guess they just open them for no other reason than: it makes the code easy to read and write
08:55 karolherbst: I meant more awesome use cases like, nvidia gpu used for displaying and amd card used for rendering
08:55 karolherbst: stuff like that
08:57 karolherbst: mupuf: ohhh I found a mistake with our LIBGL_DEBUG=verbose idea: what if there are multiple cards with the same ids
08:58 karolherbst: also maybe later somebody also wants to benchmark SLI load and stuff
08:58 karolherbst: :D
09:02 mupuf: darn it, right
09:02 mupuf: well, we could modify mesa to start dumping the node it uses
09:02 mupuf: that would help
09:03 mupuf:is still thinking
09:05 karolherbst: but then we depend like on a mesa feature :/
09:06 karolherbst: have to check something
09:06 mupuf: yes... Luckily, this is only a problem with X
09:06 mupuf: on wayland, this will not be an issue
09:06 mupuf: and we can just use an equivalent to strace to monitor which libgl is being used
09:06 mupuf: and which node
09:07 mupuf: and I also need to support the case of the jetson... no pciid :D
09:07 karolherbst: mupuf: the last pci file open seems to be a good indicator
09:07 karolherbst: "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/uevent" with DRI_PRIME=1
09:08 karolherbst: "/sys/bus/pci/devices/0000:00:02.0/resource" on intel
09:08 karolherbst: ohh wait
09:09 karolherbst: https://gist.github.com/karolherbst/cb57a78fa55c8f074940
09:09 karolherbst: I just run strace and LIBGL_DEBUG=verbose together
09:09 hakzsam: imirkin, confirmed! I sent the patch
09:09 karolherbst: this might be good enough
09:11 karolherbst: yeah, that might actually work
09:11 karolherbst: just cut the uevent away
09:11 karolherbst: and we can check if hwmon is there
09:19 mupuf: hmm, that may even be a better solution than reading just the pciid, yes
09:19 mupuf: since it would likely work on the jetson too
09:19 mupuf: I am reading up on replacement for strace which is super slot
09:19 mupuf: slow
09:19 karolherbst: k :)
09:20 mupuf: sysdig looks amazing, but perf trace sounds more suited, looking more into it
09:21 mupuf: it requires linux 3.7 though
09:21 mupuf: which is ... probably old enough :D
09:21 mupuf: december 2012
09:22 mupuf: yeah, 3 years old, that is good-enough
09:22 mupuf: even debian is more up to date!
09:23 Yoshimo: debian, feels like stoneage sometimes
09:25 karolherbst: mupuf: what is perf trace?
09:25 karlmag: Is bashing two rocks against each other to get bits a supported HID device? :-P *ducks*
09:25 mupuf: karolherbst: you have never heard of perf? It allows polling cpu performance counters, but also it can tell you where you spend most of your time while executing your program
09:25 karolherbst: I know perf
09:25 karolherbst: but I can't do perf trace
09:26 mupuf: perf trace ls
09:26 mupuf: I had to do this though: sudo mount -o remount,mode=755 /sys/kernel/debug/tracing
09:27 mupuf: glxinfo/14968 ioctl(fd: 4</dev/dri/card0>, cmd: 0xc0106446, arg: 0x7ffe6d5ee020 ) = 0 <-- well, that was simple
09:27 karolherbst: I have that node already
09:27 mupuf: it resolves the fd for us
09:27 karolherbst: libgl also prints the fd
09:27 karolherbst: libGL: pci id for fd 5: 10de:11e0, driver nouveau
09:28 mupuf: yes, but in this case, look, it says the fd 4 corresponds to the file /dev/dri/card0
09:29 mupuf: which is exactly what we need
09:29 karolherbst: I see
09:29 mupuf: and there are no race conditions because the kernel resolves it for us
09:29 mupuf: at the time of use
09:30 mupuf: I am trying to get perf trace to display strings and not their pointers though
09:30 karolherbst: mhhh okay
09:30 karolherbst: perf trace is just plain weird
09:30 karolherbst: it is listed in --help
09:30 karolherbst: but I can't call it
09:30 karolherbst: aha "trace command not available: missing audit-libs devel package at build time."
09:31 linkmauve1: Oh, this is nice, I’d like strace to do the same.
09:32 mupuf: time perf trace -e open find /sys > /dev/null 2> /dev/null --> 0m0.186s
09:32 mupuf: time strace -e open find /sys > /dev/null 2> /dev/null --> 0m0.731s
09:33 karolherbst: :D
09:33 linkmauve1: Ow.
09:33 linkmauve1: Although, not *that* bad.
09:33 karolherbst: it is bad :D
09:33 linkmauve1: strace also resolves the cmd and arg in your example from earlier.
09:35 karolherbst: mupuf: perf trace needs root user though :/
09:36 mupuf: vblank_mode=0 strace -e open glxgears --> 2336.177 FPS
09:36 mupuf: vblank_mode=0 perf trace -e open glxgears --> 8834.257 FPS
09:36 mupuf: vblank_mode=0 glxgears --> 11118.477 FPS
09:36 mupuf: karolherbst: not here
09:36 karolherbst: mupuf: I bet it is suid
09:36 mupuf: linkmauve1: so, not *that* bad? :D
09:37 linkmauve1: ^^'
09:37 karolherbst: mupuf: or at least trace is
09:37 mupuf: -rwxr-xr-x 2 root root 11648496 Sep 10 07:11 /usr/bin/perf --> not here
09:37 karolherbst: mupuf: trace is the binary called with perf trace
09:37 karolherbst: ohh wait
09:37 karolherbst: you opened debug with 755
09:37 karolherbst: :O
09:38 karolherbst: well
09:38 mupuf: -rwxr-xr-x 2 root root 11648496 Sep 10 07:11 /usr/bin/trace
09:38 karolherbst: I don't think it is a good idea to do that
09:38 karolherbst: and even worse is to actualy promote that
09:38 mupuf: debug tracing, yes
09:38 mupuf: not debug
09:39 mupuf: need to check what can be done through it
09:39 karolherbst: a lot of bad things
09:39 karolherbst: I bet you can easily read out passwords that way :p
09:39 mupuf: if it is all disponibility-related, this is a big meh
09:40 karolherbst: also you can most likely just scan all frames going through mmio and stuff
09:40 mupuf: if you can trace any process, sure
09:40 mupuf: in the case of ptrace, you can only ptrace your children
09:40 mupuf: no, that you cannot do
09:40 karolherbst: ohh right, the trace needs ot be enabled before nouveau gets loaded :/
09:40 karolherbst: right
09:41 mupuf: still is bad though
09:41 mupuf: let's see what we can do
09:42 karolherbst: events looks nice :D
09:44 mupuf:'s plan is to ask users to create an account that you cannot log into and that has the rights to run sudo without password. It will then run benchmarks using yet another user so as they cannot ... you know .. become root :D
09:45 mupuf: but we need ezbenchd to be able to request root rights because we often need to fiddle with clocks and that requires root access
09:45 karolherbst: mhh right
09:46 mupuf: yet, even in this scenario, we cannot run the script your are writing as root
10:09 karolherbst: mupuf: okay, so what is the plan?
10:09 mupuf: still looking into this
10:10 mupuf: perf trace requires rx on the folders leading to /sys/kernel/debug/tracing/events/syscalls/
10:10 mupuf: and apparently, rx is also enough there
10:11 mupuf: I guess be more selective and just allow that
10:11 mupuf: strace is much much slower, as the benchmarks showed
10:13 mupuf: strace provides 20% of the native speed for glxgears, contrarily to 80% for perf trace
10:13 mupuf: however ... even 80% is still bad
10:13 karolherbst: why should we run the gl applications under trace?
10:14 mupuf: because how else can you be sure of which libraries it is using?
10:14 mupuf: you can poll randomly on /proc/$pid/maps
10:15 mupuf: but it means being root agai
10:15 mupuf: n
10:24 karolherbst: :/
10:24 karolherbst: or maybe we just write our own preload thingy
10:25 karolherbst: with ldd and dlopen we kind of know what libraries are being used
10:25 karolherbst: and with open/ioctl we know which cards are used and how many commands are going to the kernel
10:26 karolherbst: and it may be also faster in the end than trace or strace
10:31 karolherbst: mupuf: you can read maps without being root though
10:31 mupuf: ah, right, I picked the wrong process :D
10:31 karolherbst: hey
10:31 karolherbst: ....
10:31 karolherbst: :D
10:31 karolherbst: this actually helps
10:32 karolherbst: htop can also print fd => file mappings
10:32 karolherbst: as non root
10:32 karolherbst: so we can map the libGL fd to the dri devic
10:32 karolherbst: e
10:32 mupuf: well, it is not too hard
10:32 karolherbst: without using strace or something
10:33 mupuf: lrwx------ 1 mupuf mupuf 64 Oct 17 20:32 /proc/24070/fd/4 -> /dev/dri/card0
10:33 karolherbst: yes
10:33 mupuf: but the problem is that it is not atomic
10:33 mupuf: so, time of check vs time of use
10:33 karolherbst: right, the process quits later
10:33 karolherbst: but that's not the big problem then
10:34 mupuf: it may close the fd and open another one
10:34 mupuf: and then you would not see the right value
10:34 mupuf: and how do you know which fd to look for? You iterate through all of them?
10:35 karolherbst: libGL: pci id for fd 4: 8086:0416, driver i965 there is the fd
10:35 mupuf: ah right
10:36 mupuf: well, I guess this would be good-enough
10:36 karolherbst: we could write our own minimalistic gl application
10:36 karolherbst: which just returns some info
10:36 karolherbst: we could also use pyOpenGL or something :D
10:36 mupuf: how would it get access to that?
10:36 mupuf: this is all internal to mesa
10:36 karolherbst: mhhh
10:37 mupuf: the only solution to solve everything is tracing ... which can be slow
10:37 karolherbst: start subprocess with LIBGL_DEBUG=verbose and pipe the output
10:37 mupuf: yes, this is how we are going to do it for now :)
10:37 karolherbst: and we just sleep at the end
10:37 mupuf: and then read the fd 4's symlink
10:37 karolherbst: until we get a kill signal
10:37 karolherbst: yes
10:38 karolherbst: this just means we have to use an unbuffered pipe though
10:38 mupuf: yes
10:38 karolherbst: so mhh
10:39 karolherbst: do we want to depend on PyOpenGL ?
10:39 karolherbst: maybe it is easier to just hack some c file together
10:39 mupuf: why do you need c here?
10:40 karolherbst: we need to create an opengl context somehow, or when does libgl return this line?
10:40 karolherbst: or do we want to use pyopengl?
10:41 mupuf: ok, back to the begining :D
10:41 mupuf: do we want to have a two-phased start or not?
10:41 karolherbst: I don't really mind
10:42 mupuf: the two phase start would be to launch gl application and trace it somehow to understand what the app uses
10:42 mupuf: as in, driver + node
10:42 mupuf: and then fetch stuff about the gpu
10:43 mupuf: when this is done, set up the monitoring infrastructure and start the real app
10:44 mupuf: if we go for the one phase one, we need to be a busy bee at the begining of the launch of the application to setup everything as fast as possible
10:44 karolherbst: mhhh
10:44 mupuf: in practice, tests runs for at least 10s
10:45 mupuf: although some IGT tests for intel can be much faster (but can be made to run for longer, for the purpose of better metrics collections)
10:45 mupuf: or we would just don't care
10:46 karolherbst: maybe having a preloaded library is the best apporach :/
10:46 karolherbst: because we can track time of context creation
10:46 karolherbst: and other stuff
10:47 karolherbst: we can actually get stuff direclty and don't need to poll all the time
10:47 karolherbst: parsing the maps file is a bit of an overhead too
10:47 karolherbst: and we would have many cpu wake ups
10:48 mupuf: how would the preload work?
10:48 mupuf: do you want to reimplent open?
10:48 karolherbst: mhh hook into gl(x) calls
10:48 mupuf: that could work
10:48 karolherbst: primusrun already does it
10:48 mupuf: which gl calls?
10:48 karolherbst: it has a nice list of calls someone has to provide and stuff
10:49 mupuf: sure, but what for?
10:49 karolherbst: like glxCreateContext if we want that
10:49 mupuf: how would it help us? :s
10:49 karolherbst: mhh maybe somebody would like to know how long a library needs to actually create a gl context
10:49 karolherbst: anyway, this preload approach would make this possible, if somebody would like to know that
10:49 karolherbst: we don't have to implement it
10:49 mupuf: yes
10:49 karolherbst: but we could
10:49 mupuf: I guess we could reimplent ioctl
10:50 karolherbst: well the reimplements aren't that hard in fact
10:50 karolherbst: we just need to dlopen some stuff
10:50 karolherbst: dlsym the original function
10:50 karolherbst: and call that
10:50 mupuf: so as, whenever someone calls ioctl, we would know on which fd it is called and be able to find the node like that
10:50 karolherbst: yes
10:50 mupuf: and when we have found it, we can just drop the hook (can we?)
10:50 karolherbst: and because we are inside that process, we know for sure
10:50 karolherbst: mhhh
10:50 mupuf: yes
10:50 karolherbst: we could turn it into a noop
10:50 mupuf: how is that something wanted? :D
10:51 karolherbst: I meant out overhead
10:51 karolherbst: I don't know if we can manipulate the global symbol table that easily :D
10:51 karolherbst: mhhh
10:52 mupuf: well, I guess we could have a static bool ignore_hook that we check before checking anything
10:52 karolherbst: we would need to use @gnu_indirect_function
10:52 karolherbst: I think we could exchange the ifunc
10:52 mupuf: that would be the best, but how difficult is it?
10:53 karolherbst: we can cheat a bit from primus, it is doing this, but I have no idea how to rebind the ifunc
10:53 karolherbst: I try to investiage
10:53 karolherbst: http://pasky.or.cz/dev/glibc/ifunc.c
10:54 mupuf: the problem with LD_PRELOAD is that it does not have to work
10:54 karolherbst: ohh wait :/
10:54 karolherbst: ifuncs return function pointer
10:54 mupuf: if someone decided to use a very light libc, we are screwed because they do not support LD_PRELOAD
10:54 karolherbst: once we return one, we can't change it
10:54 karolherbst: but we can return the other one on next ifunc calls
10:54 karolherbst: :/
10:55 karolherbst: mhhh
10:55 karolherbst: right
10:56 mupuf: ifuncs are good looking :D
10:56 mupuf: but that may be overkill
10:57 mupuf: the good thing about hooking like that is that we have no cost when not actively calling the function
10:57 mupuf: so it is perfect for open
10:57 mupuf: and adding libraries to a list
10:58 mupuf: oh! Even better, we can just override dlopen
10:59 mupuf: no need to hook open
11:00 mupuf: because we can use the maps file to find all the libraries that got linked at load time
11:00 mupuf: and dlopen takes care of the rest
11:00 karolherbst: right
11:02 mupuf: that should take care of most cases
11:02 karolherbst: if stuff gets serious
11:02 karolherbst: we can always just name ourself libc.so, do LD_LIBRARY_DIR and just provide the interface
11:02 karolherbst: overkill
11:02 karolherbst: but works with every C stdlib implementation
11:02 karolherbst: :D
11:03 karolherbst: and just return the dlsyms of the dlopen system libc.so in the ifuncs
11:03 karolherbst: so we only have any overhead when the symbols are collected
11:04 karolherbst: we would just need like every function that libc possibly exports :p
11:04 mupuf: lol
11:04 karolherbst: and all the other stuff
11:04 karolherbst: :D
11:04 karolherbst: there is some macro magic possible though :D
11:05 mupuf: well, for a starter, I would like to see if we can measure the impact of a naive approach
11:05 mupuf: want to code the example of shall I do it?
11:05 karolherbst: I won't have enough time for today
11:05 karolherbst: I will be like only 30 minutes here and then gone for today
11:05 mupuf: ack
11:06 mupuf: then I will do it
11:06 karolherbst: with ifuncs you can do a lot of shady things :D
11:07 mupuf: if I can measure a performance impact on glxgears, I will checkthat
11:07 mupuf: glxgears is probably the worst case scenario for this
11:08 karolherbst: if you always hook into ioctl, I would say like <1%
11:08 karolherbst: if your filter is fast enough
11:09 mupuf: well, the filter should be as fast as reading 2 numbers, the real function to call and a boolean
11:11 mupuf: well, glxgears only does ioctls on /dev/dri/card0
11:11 mupuf: that sounds good!
11:12 mupuf: same for xonotic
11:25 pmoreau: imirkin: I have a couple of questions regarding NV50 IR: 1) Is https://phabricator.pmoreau.org/P48 a correct translation of `void pi(float* out) { out[0] = 3.14159f; }`?
11:26 pmoreau: 2) Where do the 0x70 and 0x50 offsets come from in the preceeding paste?
11:26 imirkin: nnnot really
11:26 pmoreau: :-(
11:26 imirkin: not blatantly *incorrect*, bbbuttt....
11:26 pmoreau: :-D
11:26 imirkin: i would expect the float* value to come in from c0[]
11:26 imirkin: i.e. the params buffer
11:27 imirkin: i would also expect it to be a 64-bit value on fermi+
11:27 imirkin: also the +0x50 offset appears to be bogus
11:27 pmoreau: Well, I'll start with Tesla, but you're right
11:27 pmoreau: I never asked for those offsets, they just came by
11:27 imirkin: on tesla it's a 32-bit value, iirc compute shaders can only access 32 bits at a time
11:28 pmoreau: So, the load should be c[] but the store still g[]?
11:28 imirkin: that's my guess, yes
11:28 imirkin: try to figure out where the offsets come from
11:28 pmoreau: Ok, makes sense
11:29 pmoreau: I'll try to. I just used the store method of DataArray
11:29 imirkin: if pi is a kernel, params should come from constbuf
11:29 imirkin: if pi is a function that's called, then i dunno how function arg passing is done in nv50 ir
11:29 pmoreau: constbuf being mapped to c0[], right?
11:29 imirkin: but i would imagine it'd happen via either registers or l[]
11:29 pmoreau: Ok
11:46 imirkin: skeggsb_: how do i find the gpu addr of a nouveau_bo?
11:51 imirkin: skeggsb_: i'm very confused by the interface... trying to infer it from nvc0_bo_move_copy, but... not being very successful
11:52 mupuf: pmoreau: having fun, I see :p
11:53 pmoreau: mupuf: ;-) I do!
11:53 pmoreau: For now, OpenCL doesn't like math and I get pi = 0.00000f
11:54 pmoreau: But hopefully, it'll soon learn the truth!
11:54 mupuf: close-enough
11:55 imirkin: meh. off-by-4. not so bad.
11:58 karolherbst: mupuf: perf impact=
11:58 karolherbst: ?
11:58 mupuf: I just started writing the file, was on the phone before
12:01 karolherbst: mupuf: ohh okay :)
12:02 karolherbst: mupuf: anyway, I don't think you can do ifuncs if you preload. There you have to just to export the symbol and dlopen libc.so... I think they only work if the library gets loaded normally, not sure though :/
12:02 mupuf: we\ll see
12:02 mupuf: let's start with ioctls
12:04 mupuf: ok, I hooked open
12:04 mupuf: now, ioctl
12:05 mupuf: and then dlopen
12:05 mupuf: and that should do the trick :)
12:16 mupuf: karolherbst: hmm, we may have a problem, sir
12:16 mupuf: ioctl has a variable number of arguments
12:16 mupuf: I'm sure no-one uses it in practice, but it is there
12:16 mupuf: what the fuck...
12:19 mupuf: well, let's try the only case that should exist
12:24 mupuf: ok, worksforme
12:35 mupuf: karolherbst: no visible impact on the performance :D
12:35 mupuf: Yeeeepppppeeeee
12:41 mupuf: now, let's do useful work!
12:42 mupuf: as in, log which libraries are being used
12:45 mupuf: karolherbst: dlopening lib libGL.so.1
12:45 mupuf: dlopening lib /home/mupuf/install/lib/dri/i965_dri.so
13:06 pmoreau: Func args should be better handled depending if the func is a kernel or not
13:06 pmoreau: Now, taking care of those offsets
13:09 karolherbst: mupuf: :)
13:09 karolherbst: well ioctl is an async operation anyway somehow
13:09 karolherbst: so
13:16 mupuf: WHAT?
13:16 mupuf: async? :D
13:16 mupuf: well, it is a syscall,
13:16 mupuf: if it creates a new job inside the kernel, then yes
13:17 mupuf: but the call itself is purely synchronous
13:20 karolherbst: ohh okay
14:34 pmoreau: imirkin: Found out for the offsets: they come from idx * vecDim, where I set idx to the same index as the one used by SPIR-V.
14:34 pmoreau: (and vecDim is 4)
14:35 pmoreau: So I should maintain a map + counter per DataArray to solve it
14:36 imirkin: not sure i follow
14:39 pmoreau: For example: offset 0x70 is obtained by `idx =i * vecDim + c`, where `i = 7`, `vecDim = 4`, `c = 0` and `addr = idx * eltSize + baseAddr` (in mkSymbol)
14:39 pmoreau: So even if i only have one value for that DataArray, I will still have i = 7 cause that is the id used by SPIR-V
14:40 imirkin: id of what?
14:41 pmoreau: id of return value
14:41 pmoreau: Can be a type, a constant, the result of an instruction
14:41 imirkin: what's the significance of 7?
14:41 imirkin: what if it were, e.g., 70000?
14:42 pmoreau: let me find you an example
14:42 pmoreau: https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#_example
14:43 pmoreau: The id I use is the one from the result-id column
14:43 imirkin: so... not at all related to the index
14:44 pmoreau: Well, index of what? :-)
14:44 imirkin: of the variable in the params/const/etc array
14:44 pmoreau: Right
14:45 pmoreau: That's why I should add a map and counter per array
14:45 pmoreau: But, I just figured that out
15:31 pmoreau: Ok, fixed
15:33 pmoreau: I'll look tomorrow at how to bind the args of the kernel to the c[], g[] & co. from NV50 IR.
16:15 karolherbst: mupuf: how is it going?
16:15 mupuf: karolherbst: pretty well!
16:15 karolherbst: :)
16:15 karolherbst: nice
16:16 mupuf: no performance impact despite the ugly lock that I am using
16:16 mupuf: ioctl on fd 4 --> /dev/dri/card0
16:16 mupuf: it does the resolving, but no more than once
16:16 karolherbst: why locking?
16:16 mupuf: because the fd 4 may be closed
16:17 karolherbst: ohh right
16:17 karolherbst: how long do you lock?
16:17 mupuf: a ridiculously-small amount of time
16:17 karolherbst: :D
16:17 karolherbst: k
16:17 mupuf: and I see no perf impact at all
16:17 mupuf: I have a DB containing one bit per possible fd
16:17 karolherbst: yeah, I am not really surprised
16:17 mupuf: 32 longs is enough
16:18 mupuf: I put 64 for good measure as this can be changed dynamically
16:18 mupuf: it is thus imperfect
16:18 karolherbst: I think ioctls actually waste more time doing the context switch
16:18 karolherbst: therefore the difference should be really small
16:18 mupuf: or actually doing real work
16:18 karolherbst: if it's just a if case in teh end
16:18 karolherbst: yeah
16:19 mupuf: https://hastebin.com/yohewehohe.coffee <-- the current state of the code
16:19 karolherbst: mupuf: you could add a likely branch in the if (done) dl.ioctl(params) if you want
16:19 mupuf: already done
16:19 karolherbst: :D
16:20 mupuf: well, unlikely on the size check
16:20 karolherbst: I would add a done bool field
16:20 karolherbst: if (done) return orig_ioctl(fd, request, arg);
16:20 karolherbst: or do we want to do stuff forever?
16:20 mupuf: we have to
16:21 karolherbst: mhhh ohh right
16:21 mupuf: well, unless we assume that there is one single node that gets ioctls
16:21 karolherbst: OpenCL for example
16:21 karolherbst: in OpenCL you could open/close device as you like
16:21 mupuf: but a complex app may make ioctls to multiple devices
16:21 karolherbst: *devices
16:21 mupuf: or if you use bumbleebe or stuff like that
16:21 karolherbst: mhh right, too
16:21 karolherbst: ohh bumblebee doesn't do that much actually
16:22 mupuf: or whatever the name of the fancy one is :D
16:22 karolherbst: even primusrun doesn't do much
16:22 karolherbst: it just loads the nvidia gl library and the mesa one
16:22 karolherbst: :D
16:22 mupuf: see, 2 nodes!
16:22 karolherbst: right
16:22 karolherbst: and act as libgl.so
16:22 karolherbst: there is no preloading at all
16:23 mupuf:is so happy not to have to have to write this code :D
16:23 imirkin: hakzsam: can you put a wiki page together on making good use of the perf counters you added? e.g. GALLIUM_HUD, or somethign else? what the various counters mean, how to use them to figure things out, etc?
16:23 karolherbst: it is nice though
16:23 mupuf: imirkin: agreed!
16:23 imirkin: hakzsam: basically i'd like to make good use of them, but have no clue where to start
16:23 karolherbst: list of gl functions needed to be exported by libgl: https://github.com/amonakov/primus/blob/master/gl-passthru.def
16:23 mupuf: a status matrix would also be appreciated
16:23 karolherbst: :D
16:23 mupuf: karolherbst: hehe
16:24 mupuf: so, let's move to the dlopen case now
16:24 karolherbst: primus does all this exporting stuff through cpp loops
16:24 karolherbst: so this is quite easy to do
16:24 karolherbst: mhhh
16:25 mupuf: what I am doing is that I wait for dlopen to return a handle that is non-null and then I will display the path
16:25 mupuf: but I need to make sure it is an absolute path
16:25 karolherbst: mupuf: is there a way to let a function be called inside the application init sequence after all libraries are already opened?
16:25 karolherbst: something before main I mean
16:26 karolherbst: just to catch all libraries loaded into process space
16:26 mupuf: otherwise, ... the only thing I found is that I need to check /proc/pid/maps to find the actual full path
16:26 mupuf: that would not be sufficient
16:26 karolherbst: ohh right dlopen could pull in deps I assume?
16:26 mupuf: yes
16:27 mupuf: see, all the fun :D
16:27 imirkin: and it has its own logic for finding *which* lib to dlopen
16:27 imirkin: e.g. if you dlopen libGL it goes through its search paths
16:27 karolherbst: ohh right
16:27 _TPG: hi, anyone noticed that vbox with 3D support enabled and with instaled vbox additions crashes nouveau driver libdrm-2.4.65 ?
16:27 mupuf: as usual, all the fun!
16:28 _TPG: anyone familiar with that http://pastie.org/10489598 ?
16:28 imirkin: _TPG: a few people have made such reports
16:28 mupuf: karolherbst: now, the question is, shall I immediately run the SHA1 of the library or should I say that it will not change during the time of the run? :D
16:28 imirkin: _TPG: never investigated, as i have no desire to ever touch vbox.
16:29 karolherbst: mupuf: why run sha1?
16:29 karolherbst: ohh well :/
16:29 _TPG: imirkin: i understand your point, but in my case vbox is a part of my job
16:29 mupuf: well, the path is not enough, right?
16:29 karolherbst: mupuf: why shouldn't it?
16:30 mupuf: because, for instance, ezbench will recompile the driver but install it at the same path?
16:30 imirkin: _TPG: ok. try the nvidia blob driver maybe then?
16:30 mupuf: and how do you find out which version you are using?
16:30 karolherbst: we could of course also deal with stuff like old version of plugin unlaoded, new version loaded, but why?
16:30 karolherbst: mupuf: mhhh the benchark will be executed in a new process right?
16:31 _TPG: imirkin: i have no desire to ever touch nvidia blob driver
16:31 _TPG: ;-)
16:31 mupuf: nope, it is executed in the same process, because we use LD_PRELOAD
16:31 karolherbst: I meant a new run of the benchmark
16:31 mupuf: _TPG: then, I guess you will have to get a desire to debug the problem on nouveau then :D Welcome to the team!
16:31 imirkin: _TPG: then try a non-nvidia gpu :) i have no idea why nouveau + vbox = fail
16:31 mupuf: karolherbst: yes yes
16:32 karolherbst: I mean if you want to indicate that some library has changed between runs, then yes, a checksum would be nice (or other means to get the right version)
16:32 karolherbst: but with what does it help?
16:32 mupuf: karolherbst: right now, my only idea is, when compiling, storing a hash of the .so and then, when we have the hash of the lib that actually got used by the benchmark, we can compare those and find which git version was compiled, along with all the compilation flags
16:33 mupuf: it helps for ezbench, to make sure that we are using the version we expect
16:33 karolherbst: mupuf: don't we know before executing the process?
16:33 karolherbst: ahhh
16:33 karolherbst: okay
16:33 karolherbst: for verifing stuff
16:33 mupuf: yop
16:33 karolherbst: okay, yeah that makes sense
16:33 karolherbst: but then again: a full path is usually enough
16:33 mupuf: the best would be to hash it from memory, actually :D
16:34 mupuf:is not paranoid AT ALL
16:34 karolherbst: :D
16:34 karolherbst: okay
16:34 karolherbst: maybe we hit a bug inside the kernel file caching mechanism
16:34 karolherbst: _could_ be
16:34 imirkin: _TPG: the errors you're seeing basically can't happen... they're fifo command formatting errors -- only thing i can think of is if vbox has contexts active in multiple threads at once, draw calls would stomp over each other and could produce such results
16:34 imirkin: _TPG: but appliations that have contexts current in multiple threads at once are very rare, dunno if vbox is one of them
16:34 karolherbst: I also found already some weird gcc bugs, so it is not that we don't hit such stupid bugs :D
16:35 mupuf: karolherbst: I guess I can't do it from memory though...
16:35 karolherbst: mupuf: are you sure you want to use your bit_read, bit_write functions?
16:35 mupuf: because the elf format will not work
16:35 karolherbst: there should be something for that inside libc.so
16:36 karolherbst: and most likely something asm optimised on newer cpus
16:36 mupuf: karolherbst: really? If there is, I will get rid of it
16:36 karolherbst: I think sse4 added something like that?
16:36 karolherbst: don't know
16:36 karolherbst: have to search though
16:36 karolherbst: not sure
16:37 karlmag: Well whaddayaknow... Looks like I found a tesla based card I had no idea I had. GT220 (nva5/gt216) Hope it works.
16:37 mupuf: please keep me up to date with this
16:37 mupuf: in the mean time, I will add the code to get the hash strait away
16:37 mupuf: or at least open the fd and wait until the program closes to do the hash
16:39 karolherbst: mupuf: I found something for msvc :/
16:39 mupuf: karolherbst: ahah
16:40 karolherbst: mupuf: okay, the stuff I remembered was for least and mot significant bit :/
16:41 karolherbst: there are builtins for that
16:41 karolherbst: I keep digging though
16:41 mupuf: and also what is the first bit set
16:41 mupuf: and opposit
16:41 mupuf: e
16:41 _TPG: if you guys are interested you may take a look on my bugreport https://bugs.freedesktop.org/show_bug.cgi?id=92515 :)
16:41 karolherbst: yeah
16:41 mupuf: yeah, I am aware of those
16:41 karolherbst: but checking if a specific bit is set is quite expensive :/
16:41 karolherbst: I saw some O3 asm code
16:41 karolherbst: and it was a bit much :D
16:42 mupuf: the code should be plenty fast already
16:42 mupuf: there is up to one cache miss and one page fault
16:43 mupuf: same for the write
16:43 karolherbst: mupuf: linux has some asm code for that
16:43 mupuf: yeah, let's ignore that then
16:43 mupuf:will need to test his code though at some point
16:43 mupuf: the logic sounds sound
16:43 karolherbst: asm volatile("btr %1,%0" : ADDR : "Ir" (nr));
16:43 mupuf: (talking about bit_read/write)
16:44 mupuf: I doubt this is critical
16:44 karolherbst: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46091 :D
16:44 karolherbst: there is even a bug for that
16:46 karolherbst: mupuf: seems like if we really want to do that, there should be some asm stuff then :/
16:46 karolherbst: there is nothing provided through gcc or glibc as it seems
16:47 mupuf: ok, I will keep my code though
16:47 karolherbst: k
16:47 mupuf: because I use bit operations
16:47 mupuf: and not the expensive div and modulo operations
16:47 karolherbst: yeah, which are translated into like 12 instructions :D
16:47 mupuf: why are they?
16:47 karolherbst: the function in total
16:48 mupuf: a div takes a ton of cycles though
16:48 mupuf: and same for modulo
16:48 karolherbst: right
16:48 karolherbst: but gcc will do it best anyway
16:48 mupuf: again, not that we care
16:48 karolherbst: so maybe in the end it doesn't even matter
16:48 karolherbst: I just find it strange, that somebody actually has to code this :/
16:49 mupuf: right
16:49 mupuf: so, I cannot get the lib destructor to work :s
16:49 mupuf: so, we will have to hash on the spot
16:49 karolherbst: why not?
16:49 mupuf: well, it does not get called ...
16:50 mupuf: I wonder if a c++ object would get its destructor called, but I doubt it given that we do not get the signal...
16:50 karolherbst: depends on when
16:51 karolherbst: I already had a lot of fun with this, you can't imagine :D
16:51 karolherbst: basically, a dtor doesn't have to be called at all
16:51 karolherbst: you can alway do like new (ptr) Type;
16:53 mupuf: my bad, it does work
16:54 mupuf: but... not sure if I can still write stuff to a fd
16:54 karolherbst: as long is it is open, why not?
16:54 karolherbst: http://man7.org/linux/man-pages/man2/fcntl.2.html
16:55 karolherbst: fcntl(fd, F_GETFD) is the canonical cheapest way to check that fd is a valid open file descriptor. If you need to batch-check a lot, using poll with a zero timeout and the events member set to 0 and checking for POLLNVAL in revents after it returns is more efficient.
16:55 karolherbst: http://stackoverflow.com/a/12340730
16:56 karolherbst: sounds messy though
16:56 mupuf: AHAHAHAHAH
16:57 mupuf: I destroyed my session by running "system in a destructor"
16:57 karolherbst: :D
16:57 mupuf: now, the program crashes in a loop :D
16:57 karolherbst: yeah well
16:57 karolherbst: gdb and catch the signal
16:57 karolherbst: :D
16:57 karolherbst: ohh wait
16:57 karolherbst: :D
16:58 mupuf: ok, done
16:58 karolherbst: I like signals though, they are a lot of fun
16:58 mupuf: on the contrary
16:58 karolherbst: like accessing a NULL pointer inside your SIGSEGV handler
16:58 karolherbst: fun
16:58 mupuf: they are a giant pain the butt :D
16:58 mupuf: hehe
16:58 mupuf: this kind of fun, right!
16:59 karolherbst: or calling abort inside your SIGABRT handler :)
17:01 karolherbst: I like them though
17:01 karolherbst: I also like atexit :)
17:28 mupuf: karolherbst: ahah, if I open a file in _init(), then I get fd 1
17:28 mupuf: that is bad :D
17:28 karolherbst: like always?
17:29 mupuf: you mean that it remains 1 all the time?
17:29 mupuf: I can chec that
17:29 karolherbst: mupuf: "It describes _init/_fini as dangerous and obsolete, and recommends that __attribute__ ((constructor)) and __attribute__ ((destructor)) are used instead."
17:30 mupuf: yes, they are well decorated
17:30 karolherbst: there are soo many nasty tricks
17:30 karolherbst: it is just awesome
17:30 mupuf: yep
17:30 karolherbst: another good one: GNU GCC allows you to define your own function of the same name as an existing symbol. When linking, you provide an argument of -Xlinker --wrap=<symName>. Pretending you did this to main, you can call the real main via __real_main(...):
17:30 karolherbst: overriding main, why not
17:30 karolherbst: :D
17:30 mupuf: sure, warum nicht?
17:31 karolherbst: :p
17:31 mupuf: so, the answer to your question is no, it does not stay
17:32 karolherbst: k
17:32 mupuf: I guess the crt is happy and closes the fd :D
17:32 mupuf: hey, I do not care about this anyway
17:32 karolherbst: :D
17:35 mupuf: so, I guess I just need to create a function that will log the findings to a file, and if it is not open yet, open it before writing
17:35 mupuf: as simple as this
17:39 mupuf: actually, everything works as expected when the idiot between the keyboard and the chair sets the attribute constructor to the constructor, and not destructor
17:43 karolherbst: :D
17:44 karolherbst: I hope for the day, when people stop confusing egl with gles
17:44 karolherbst: :D
17:45 mupuf: who confuses both?
17:45 mupuf: in which context?
17:46 karolherbst: qt-5 does
17:46 karolherbst: maybe some gentoo devs
17:46 karolherbst: don't know
17:46 karolherbst: qtmultimedia with egl support pulls in qtgui with gles2 support, makes totally sense :/
17:56 mupuf: lol
17:56 mupuf: well, gles mandates egl
17:57 mupuf: I guess that's where all the confusion comes from
18:01 karolherbst: I know
18:16 karolherbst: mupuf: you are lucky that tomorrow is sunday :D
18:16 mupuf: karolherbst: why?
18:16 karolherbst: :D
18:16 mupuf: because I am going to bed late?
18:16 karolherbst: yes
18:16 mupuf: :p
18:16 mupuf: still trying to make this late SHA1 to work
18:17 mupuf: for some reason, it cannot read my list
18:17 karolherbst: mhh
18:17 mupuf: as in, I am sure I added data
18:17 mupuf: and when I arrive at the fini destructor, it looks like it has the old data in memory
18:18 mupuf: but I used a mutex to protect the read/writes
18:18 karolherbst: mhhh
18:18 mupuf: so ...
18:18 karolherbst: you aren't writing into global memory are you?
18:18 karolherbst: mhhh
18:18 karolherbst: there is no other way sadly :/ forget my stupid stuff I say :D
18:19 karolherbst: but I don't know if you are able to just read memory claimed by other libraries there :/
18:20 mupuf: it should be in my address space :s
18:21 mupuf: what the heck
18:22 karolherbst: I had a lot fund with destructor of global static objects in c++ and since then I won't want to have that fun anymore :D
18:25 mupuf: well, enough fun for me today!
18:25 karolherbst: :D
18:25 karolherbst: maybe I could try more stuff
18:27 mupuf: you want to get the code?
18:27 mupuf: sure thing, it still is a big piece of shit though
18:27 karolherbst: yeah, is there something left to do?
18:27 karolherbst: :D
18:28 mupuf: gcc -Wall -fPIC -shared -o env_dump.so env_dump.c -ldl -lpthread
18:28 mupuf: https://hastebin.com/vemubomaya.coffee
18:28 karolherbst: stupid ssl error :D
18:29 mupuf: if anything, it would be nice to finish the dlopen check result function to lookup in /proc/$pid/maps the full path of the library that just got added
18:29 mupuf: this is only necessary when the path is relative
18:29 mupuf: which mesa is doing
18:30 karolherbst: mhhh
18:30 karolherbst: I don't think you should call the function _fini and mark it as a destructor
18:31 mupuf: why not? afraid of it being called multiple times?
18:32 karolherbst: for example
18:32 mupuf: well, tweak the code as you wish
18:32 karolherbst: also I get "ERROR: ld.so: object 'env_dump.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored." :D
18:32 mupuf: you need to give a full path
18:32 mupuf: not a relative one
18:32 karolherbst: ohhh k
18:32 mupuf: LD_PRELOAD=$PWD/env_dump.so vblank_mode=1 timeout 1 glxgears; less /tmp/env_dump
18:32 mupuf: this is what I use for my tests
18:33 karolherbst: Dump_env: cannot open 'libudev.so.1' :/
18:33 mupuf: yes, guess why :D
18:33 karolherbst: no idea
18:34 mupuf: because the code I told you was missing ... is missing :D
18:34 mupuf: have a look at the code, it will be clear
18:34 karolherbst: ohhh
18:35 mupuf: cat /proc/$PID_OF_GLXGEARS/maps | grep libudev.so.1 --> 7f01db542000-7f01db560000 r-xp 00000000 08:02 2763971 /usr/lib/libudev.so.1.6.4
18:35 karolherbst: okay, so this mapping has to be done then
18:35 mupuf: yes
18:36 mupuf: and then, what I want to do is to open the file, but wait until the end of the benchmark to generate the SHA1
18:36 karolherbst: but the original dlopen was already called?
18:36 mupuf: yes
18:36 karolherbst: easy
18:36 mupuf: is there an api for that?
18:36 karolherbst: ever opend dlfcn.h?
18:37 karolherbst: check the Dl_info struct
18:37 mupuf: int dlinfo(void *handle, int request, void *info);
18:37 karolherbst: but there is something else
18:37 mupuf: very nice
18:37 karolherbst: yes :D
18:37 mupuf: well, that will do the trick then :D
18:37 karolherbst: I had sooo much fun with that, its just awesome
18:37 mupuf: well, I guess you can remove the path for the absolute path
18:37 mupuf: and just always get the l_name
18:38 mupuf: then, there will only be the issue that, at the end, it will tell you: Found 0 SHA1 to generate
18:38 karolherbst: the thing is, dlinfo is a bit misleading
18:38 mupuf: ah?
18:38 karolherbst: because you usually call it to get symbol information
18:39 karolherbst: or was it dladdr1? :D I really odn't know anymore
18:39 mupuf: dlinfo takes an handle as an input, so I would assume that it is fine
18:40 mupuf: anyway, should get going
18:40 mupuf: if you can figure out why we get Found 0 SHA1 to generate at the end, it would be great
18:40 mupuf: and when it does say the right amount, you can uncomment the loop too and check the fds
18:40 mupuf: they should correspond to the LINK ones found earlier in the report
18:41 karolherbst: mupuf: http://stackoverflow.com/a/20693897
18:41 karolherbst: that's what I meant
18:43 mupuf: this is for macos :D
18:43 karolherbst: I know
18:43 karolherbst: but it is also unix
18:43 mupuf: the question says that dlinfo works for linux
18:43 mupuf: hehe
18:43 mupuf: good that the gnu extensions are here
18:44 mupuf: you'll tell me later why you played so much with the linker :p
18:44 karolherbst: :D
18:47 mupuf: night!
18:47 karolherbst: good night
18:49 karolherbst: nice
19:02 karolherbst: mupuf: heap corruption, shame on you
19:02 karolherbst: sizeof(int) * (sha1_fd_count + 1)
19:03 karolherbst: mupuf: https://gist.github.com/karolherbst/448fbde609a3f6ffa954
19:22 karolherbst: :D
19:23 karolherbst: mupuf: you will LOVE this
19:23 karolherbst: mupuf: "Found 26 SHA1 to generate!" I know why but I will tell you tomorrow :p