01:00tiny001: what is IGP???thanks
01:05towo^work: IGP integrated graphics processor
01:09tiny001: where to set it ??
01:10towo^work: where to set what?
01:11towo^work: the igp is the default output device on optimus systems
01:11towo^work: it's the only device which is connected to a display
01:13tiny001: i know now,
01:34pmoreau: l1k: Hello! I compiled the different kernels yesterday, so I'll most likely test today since I only need to boot and test, which doesn't take long. :-)
02:18orbea: heh.... http://dpaste.com/07N7061
03:04bozhan: hi, do i have to set DRI_PRIME=1 when i run piglit test?
03:24bozhan: imirkin: where to send you result of piglit test of mu card?
03:27mupuf: imirkin: speaking about storing piglit results, I need to set up some sort of storage + automatic generation of reports so as people can send their results and we can compare them
03:28mupuf: There is a new GUI for comparing results that has been developed at Intel Finland and which we will be trying to get merged upstream, it is really good to compare the results of a lot of machines, that would do very nicely for us
03:33mupuf: and, months after I said it would land, I finally have some sort of auto-bisect working. As in, when a performance change happens between 2 commits, it will try to look for the commits that improve it. The only problem is that some benchmarks have a very weird variance and it screws up with the system that will detect how many runs of the benchmark are necessary to reduce the variance to under the threshold between the two performance averages
03:34mupuf: I have been pulling my hair on this, but I guess it is just easier to not try to over-optimise the thing and run the benchmarks more times than necessary
03:35karolherbst: mupuf: does it also take the driconf file into account?
03:35mupuf: karolherbst: as in?
03:36karolherbst: yeah well, we got a perf regression by 25% in unigine caused by the driconf file
03:36karolherbst: and if you bisect with a local mesa, it doesn't work well
03:36karolherbst: it was something I had to deal with
03:36mupuf: well, since the driconf file is not deployed, it would not be caught
03:37mupuf: well, I need to check, at least
03:37karolherbst: yeah but I have a system installed one in /etc
03:37karolherbst: and if I compile mesa locally, the system wide one is still be used
03:37mupuf: but if it is deployed and used, then yes, it will find it
03:37karolherbst: so if a performance regression is caused by a config there, I can't find it
03:37karolherbst: but it depends on how your stuff deploys mesa for testing I guess
03:38karolherbst: just a thought I had, because this issue really annoyed me, because it didn't make any sense until I found the issue
03:38mupuf: if you change it manually between the two runs, it will see a performance regression but will fail to reproduce the previous reading
03:38mupuf: at least, this is my goal, not the current status
03:39karolherbst: right, but that file was changed by upstream mesa ;)
03:39mupuf: well, if this is what you are tracking, it is all good
03:39mupuf: the problem is when you have multiple things changing at the same time
03:40mupuf: I guess I could use env_dump to detect if the files opened by the benchmark changed or not
03:40mupuf: it is not difficult
03:40mupuf: and use the environment diffing to detect changes like this
03:40karolherbst: well I was bisecting mesa
03:40karolherbst: and then a changed driconf file by mesa should be also detected
03:41karolherbst: that's just the problem I had
03:41mupuf: yeah, and whatever you did, you could not reproduce the previous reading, which is a good sign that you are bisecting the wrong component
03:41mupuf: yes, that would be nice
03:41karolherbst: I also just used my compiled mesa with the LD_LIBRARY_PATH and LIBGL_DIRVERS_PATH thingies
03:41mupuf: yep, that's the way to go
03:42mupuf: although I do not need to use LIBGL_DIRVERS_PATH
03:42karolherbst: right, except it uses the system wide driconf file :D
03:42mupuf: yeah, it tries in different folders
03:42karolherbst: yeah no idea, I am more explicit about this, because I _think_ I had issues with that
03:42mupuf: LIBGL_DEBUG=verbose will tell you what driver is picked up
03:43mupuf: and also which DRI version you are using
03:44mupuf: I guess I will create a chroot on reator to do the CI
03:44mupuf: so as you cannot mess up with the settings in my back :D
03:45mupuf: still not idea how I will prevent you from running stuff
03:45mupuf: I guess when someone will ssh into reator, I will stop the CI altogether
03:45mupuf: until no-one is on the machine
03:47mupuf: or I could do the CI on my two laptops I do not use
03:47mupuf: nvd9 and nv86
03:48karolherbst: mupuf: or just recreate the root?
03:49karolherbst: ohh wait
03:49karolherbst: mupuf: well you could configure cgroup the right way for this
03:49mupuf: for the cpu, yes
03:49karolherbst: mhh right, there is no gpu controller for cgroup yet :/
03:52mupuf: I guess I could display a warning that the CI is running
03:52mupuf: and send another message when the test is over and you can work
03:52mupuf: worst case scenario, it would take 5 minutes for you to gain access
03:52bozhan: so if my card is optimus did i have to run xrandr --offloadsing........ and then to run piglit wirh DRI_PRIME=1 ......
04:03karolherbst: mupuf: yeah, I think that would be the best idea
04:04karolherbst: otherwise someone might reboot because he wants to use the blob or something
04:04karolherbst: bozhan: http://nouveau.freedesktop.org/wiki/Optimus/
04:05bozhan: karol i know that... with my poor english i am trying to ask... did i have to run piglit test setting that enviorment:)))
04:06karolherbst: well it also works for piglit if that's what you ask
04:10bozhan: if i set xrandr --setprovideroffloadsink nouveau Intel and run DRI_PRIME=1 ./piglit-run.py -x glx -x streaming-texture-leak -1 --dmesg tests/gpu.py ~/piglit-results/nvXX-`date +%Y-%m-%d`-$USER
04:10bozhan: after several test X server crashes and i have to logon again
04:14karolherbst: blacklaser: how many runs?
04:16RSpliet: karolherbst: I pushed a mountain of compile fixes, but bear in mind
04:16RSpliet: - half of what you find in the GDDR5 script is wrong, old, stale or needs to be verified; use with caution and don't try to blindly run it
04:16RSpliet: - I most likely fucked up the voltage GPIO naming and conditions
04:16RSpliet: - none of it is tested on an actual machine; random broken-ness is plausible
04:19RSpliet: the state of what is right and wrong in the GDDR5 script is mostly in my head... :-P
04:19RSpliet: nonetheless, it can be a good inspiration for where to look when trying to map VBIOS bits to memory reg behaviour observed in your (DDR3?) scripts
04:20karolherbst: RSpliet: wich of those commits are upstreamed already?
04:21RSpliet: "clk/g84: Enable reclocking for GDDR3 G94-G200" is the last patch to be found upstream
04:21RSpliet: couldn't be arsed to rebase against drm-next yesterday
04:21karolherbst: k, thanks
04:21karolherbst: nah, I have to compile this on 4.2 anyway
04:21RSpliet: it's a drm-next 4.3 tree iirc
04:21RSpliet: oh yes, 4.3-rc1
04:22karolherbst: yeah, no problem then
04:22RSpliet: might rebase over the weekend, no promises made
04:23karolherbst: I think I need a script to apply kernel based trees on module based trees :D
04:24RSpliet: surely Ben must have one of those
04:26karolherbst: I think he has one for the opposite direction
04:27karolherbst: RSpliet: k, seems to work, only compile error left is inside nouveau_display
04:27karolherbst: but that because I am on 4.4
04:28RSpliet: it has a few warnings because I didn't tidy up everything
04:28RSpliet: display error is likely kernel mismatch
04:28karolherbst: I think I will spend some time for the dynamic reclocking code today anyway, cause there are some issues in the way I do stuff there :/
04:29karolherbst: but I am sure I will have some time for the fermi stuff today too
04:29RSpliet: if you're interested, you could also take a look at dyn reclocking for pre-GT215s
04:30RSpliet: no cstates, just pstates. No HWSQ, but I'd be very happy to enable that by default in nouveau for NVAA/NVAC IGPs
04:30karolherbst: is there anything known about some counters on those chips?
04:31RSpliet: not with me, but I've never diven into it given how my mind has been solely on memory reclocking scripts
04:31RSpliet: a shame really, but well, a man's got to do
04:31karolherbst: yeah no problems
04:31karolherbst: the requiernment for that dyn reclocking is, that nouveau can somehow check the current load
04:31karolherbst: without this, well it is tricky to reclock
04:31RSpliet: hehe, well, surely there are mechanisms
04:31karolherbst: I hope so
04:32RSpliet: but how they work and who monitors them, beats me :-D
04:33karolherbst: yeah well, if nobody knows that, then I think it has to wait for pre GT215 gpus :/
04:33karolherbst: because I don't have such
04:33karolherbst: well I have a FX 5200 somewhere....
04:33RSpliet: anyway, for the IGPs I am very confident that reclocking is stable (given how it doesn't touch RAM)
04:33RSpliet: hmm, those are a bit too old I'd say
04:33karolherbst: yeah and I have no computer to plug it in anyway
04:41pmoreau: RSpliet: Yes please, enable it for NVAC! You'll get plenty of beers at FOSDEM! O:-)
04:55pmoreau: If you need any traces or to do some testing, I'll be happy to do that, starting from Thursday.
04:58karolherbst: pmoreau: how does the blob messure the gpu core load on those :p
04:59pmoreau: karolherbst: Good question! I'll happily have a look at that, but for this kind of questions, it'll have to wait until FOSDEM. I have to take care of the talk first. :-D
04:59karolherbst: no problem
04:59pmoreau: But if it's testing, that I could before FOSDEM. :-)
04:59karolherbst: I have no clue how that is done on those, so mhh
05:02karolherbst: Tom^: actually the issue in the code was pretty trivial in the end, I just prefered the wrong stuff :D
05:08RSpliet: pmoreau: do realise that NVAC doesn't have a voltage regulator... the power consumption profit is not that big :-P
05:13mwk: 3 down, 5 to go
05:21pmoreau: RSpliet: Meh… But getting some extra performance when needed doesn't seem to bad. :-)
05:21RSpliet: pmoreau: indeed. My board boots in the highest perflvl though... which is impressive given how you can alter the clock of the max perflevel in the BIOS setup utility of the motherboard :-D
05:22pmoreau: Oh wow, I guess it's not a laptop motherboard, is it?
05:22RSpliet: nah, it's a mini-ATX board
05:22pmoreau: Mine boot on second lowest IIRC
05:36karolherbst: mupuf: it seems like nouveau changes the clocks of a cstate if the pstate has a higher min clock in the Boost table
05:36karolherbst: mupuf: do you think it is just better to "disable" this cstate instead of changing the clocks?
05:57mwk: well that was unexpected.
05:58mwk: imirkin: turns out ex2 has a sat modifier on g80 (clamp to [0, 1]) - any use for that?
05:59tacchinotacchi: you can send me RTFM if you want but, how does linux know what modules to load based on the hardware?
06:00mwk: tacchinotacchi: each module file has a special section listing the PCI IDs of devices it knows
06:00mwk: then, after module instalation, depmod program searches all these sections and makes a big list somewhere in /lib/modules
06:01mwk: and then, when system boots, or when a new PCI device is detected, udev checks its PCI id and searches in that list, then loads the module
06:01mwk: that's not just PCI ids, there are lots of kinds of IDs in there... USB IDs, etc.
06:03tacchinotacchi: k thank you
06:14mwk: ok, let's try rsqrt...
06:19RSpliet: mwk: does it have a "neg" modifier as well? I guess you could transform clamp(1/2^x) to clamp(2^-x) that way
06:28mwk: but the preex2 instruction does
06:54mwk: so... lg2
06:56karolherbst: Tom^: there? I need you to verify something for me
07:08codehotter: Can someone help me with a little end-user troubleshooting? I would like to use the HDMI display and my laptop display at the same time.
07:08codehotter: If I plug in a VGA monitor, I can use those two in a dual monitor setup perfectly, everything works. However, as soon as I plug in the HDMI display, everything goes to ****
07:09codehotter: My computer becomes really slow, and I have 4 mouse cursors on the screen, moving around, even though I'm not moving the mouse.
07:09codehotter: It's completely unusable
07:09codehotter: Hopefully this is a stupid misconfiguration that I can easily fix, any tips?
07:10codehotter: I have a NVIDIA Corporation GK107GLM [Quadro K1100M] in M4800
07:10karolherbst: only the quadro?
07:11codehotter: No, this is a laptop with two cards
07:11karolherbst: then intel is your main gpu I assume?
07:11karolherbst: and the VGA port is wired to intel and HDMI to nvidia?
07:11codehotter: well I don't know what main means, but the second card is intel
07:12karolherbst: main means it is driving your display
07:12codehotter: I'd assume the laptop display is wired to the intel card, and the hdmi probably to the nvidia, right.
07:12codehotter: I don't actually know. How do I check?
07:12karolherbst: xrandr most likely
07:13karolherbst: and the x log
07:14codehotter: http://fpaste.org/309840/45261164/ xrandr output with hdmi connected
07:14codehotter: wait, it's hdmi, right?
07:14karolherbst: but it says vga ;)
07:15karolherbst: okay, but it seems like it is all wired to intel actually
07:15karolherbst: except you setup some reverse prime stuff
07:15codehotter: well I also have a VGA monitor connected
07:15codehotter: I'll disconnect it and try again
07:16codehotter:googles reverse prime
07:16karolherbst: mhhh k
07:17karolherbst: codehotter: ls /sys/class/drm/
07:17codehotter: card0 card0-DP-1 card0-DP-2 card0-DP-3 card1 card1-DP-4 card1-eDP-1 card1-HDMI-A-1 card1-VGA-1 controlD64 controlD65 renderD128 renderD129 ttm version
07:18karolherbst: then the DP-1, DP-2 and DP-3 are from your nvidia gpu
07:18karolherbst: okay, then it makes sense
07:18karolherbst: but you are sure it is a HDMI port?
07:19karolherbst: imirkin: in which case are HDMI ports identifies as DP ones?
07:19codehotter: As best I can tell, the connector looks like a HDMI one. It has 'hdmi' written on it
07:20karolherbst: codehotter: does changing the resolution of the HDMI connected help in any way?
07:20codehotter: Is there a way I can do this from the commandline? I can set up the command before I plug in the display and try.
07:20codehotter: I can't see what I'm doing once I plug it in
07:20karolherbst: ohh k
07:21karolherbst: codehotter: well you could use ssh
07:21codehotter: right. What should the command be?
07:21karolherbst: DISPLAY=:0 xrandr ... something
07:21karolherbst: have to check how to do that again
07:23karolherbst: DISPLAY=:0 xrandr --output DP-1-3 --mode 1920x1080_50.00
07:24karolherbst: codehotter: then check with DISPLAY=:0 xrandr if the DP-1-3 display changed resolution
07:26codehotter: karolherbst: my laptop display is working now. My external monitor is showing my desktop background, but I can't get any windows to appear on there by dragging them
07:27codehotter: also on my laptop display, my cursor is missing from screen until I move it
07:27codehotter: if I go into gnome 'arrange displays', the number 1 shows on my laptop display, but the number 2 is not appearing on the external monitor
07:27karolherbst: try xrandr --output DP-1-3 --mode 1920x1080_60.00
07:27karolherbst: just to check if 60Hz also works
07:28karolherbst: codehotter: anyway, what kernel are you running?
07:28codehotter: karolherbst: it says mode not found, unless I remove the _60.00 part
07:29codehotter: same for _50.00 by the way, I should have mentioned that
07:29karolherbst: ohh k
07:29karolherbst: xrandr says that the 60.00 thing is selected?
07:29karolherbst: I don't really now the syntax of xrandr, so
07:29codehotter: it shows a star by it
07:30karolherbst: and still 1920x1080+1920+0 ?
07:31karolherbst: did you try moving windows through both sides?
07:31karolherbst: I think it is right of your internal one, but who knows
07:31codehotter: yes, I can move windows left but not very far, I can move them all the way to the right, they never appear
07:32codehotter: (until I move them back left into my laptop monitor)
07:32codehotter: Is this something that is supposed to work?
07:32karolherbst: it should work
07:32karolherbst: well the resolution problem is another issue though
07:32codehotter: Do I need to configure anything special for this to work? I think I've left everything on the default configuration with my distro
07:33karolherbst: maybe there is something silly inside the xorg.conf files
07:33codehotter: There is no xorg.conf file
07:34codehotter: Do I need to use --setprovideroutputresource ? What is reverse prime you were talking about?
07:34karolherbst: codehotter: maybe there is something inside dmesg or the xorg.logs
07:35karolherbst: codehotter: it seems like to be automatically setup for you already
07:36karolherbst: but you can try to execute xrandr --setprovideroutputsource nouveau Intel and see if that changes anything
07:36codehotter: no, it's the same
07:36codehotter: is reverse prime what I should be doing here?
07:37codehotter: What's wrong with the ordinary prime or not using prime at all? What's prime?
07:37karolherbst: prime is used when you have multiple gpus ;)
07:37karolherbst: so you can use your nvidia card for rendering for example
07:37karolherbst: try out DRI_PRIME=0 glxinfo | grep "OpenGL vendor string" and DRI_PRIME=1 glxinfo | grep "OpenGL vendor string"
07:37karolherbst: one should say intel the other nouveau
07:38codehotter: right, 0 is intel, 1 is nouveau
07:38karolherbst: and with DRI_PRIME=1 glxgears you render glxgears on the nvidia gpu
07:39codehotter: OK. So can I use intel for everything and disable the nvidia for now?
07:39codehotter: or the other way around
07:39codehotter: because it's not working.
07:39codehotter: I do not need any good video performance, I just need my stuff to appear on my displays
07:40karolherbst: well if you want to use hdmi, you have to use the nvidia gpu
07:40karolherbst: codehotter: DRI_PRIME=1 glxgears doesn't work?
07:40mupuf: karolherbst: Here you go, a complete bisect: http://pastebin.com/GF0LQKjq
07:40codehotter: karolherbst: it does!
07:40codehotter: I mean my hdmi display isnt' working, I can't get any windows to appear on it
07:40karolherbst: codehotter: yeah, that's an issue which can be fixed, somehow
07:41codehotter: karolherbst: could it be that my laptop display is wired to the nvidia card?
07:41mupuf: I just had to run this command first: (./ezbench -b glxgears:window -c '44fe868d278af2b9eec3b69a1d1f90c69a71d311 b59fad8478787665b7dc1618ca2a8b8df02feade' -r 1 mesa_test) which says to run the benchmark once for two commits
07:41Tom^: karolherbst: sure
07:41codehotter: and the hdmi port to the intel?
07:41karolherbst: codehotter: nope, hdmi is wired to nvidia
07:41karolherbst: you can't change that
07:41codehotter: karolherbst: how do you know this?
07:41karolherbst: ls /sys/class/drm/
07:41karolherbst: card0 : intel
07:41karolherbst: card1 : nvidia
07:42karolherbst: and with the xrandr output you can map that stuff
07:42codehotter: right, and eDP1 is my laptop display, right?
07:42codehotter: if I disconnect the HDMI display, that's all that remains in xrandr output
07:42codehotter: and it's card1?
07:43karolherbst: ohh right, card1 is intel for you
07:43karolherbst: and card0 is nvidia
07:43codehotter: no, card1 is nvidia
07:43karolherbst: it depends a bit on the load order of the kernel modules
07:43codehotter: if I do DRI_PRIME=1 | grep vendor I get nvidia, does the DRI_PRIME number map to the card number?
07:43codehotter: oh, ok
07:44karolherbst: mupuf: nice
07:45karolherbst: codehotter: so there are two problems here: 1. the highest resolution somehow messes up, 2. for some weird reasons nothing shows up on your offloaded display :/
07:45codehotter: karolherbst: I think the nonhighest resolution is still messed up
07:46codehotter: I've set it back to the highest resolution again, and my laptop display is still working, except my mouse cursor is acting very strangely.
07:46karolherbst: ohh k
07:46karolherbst: then try something lower
07:46karolherbst: like 1152x864
07:46codehotter: on the external or laptop?
07:47codehotter: OK, I did that. It's now completely black
07:47karolherbst: Tom^: https://github.com/karolherbst/nouveau/commits/master_karol_no_touchy two newest commits
07:47codehotter: my desktop background does not appear either
07:47codehotter: my laptop display is still broken
07:48karolherbst: okay, then something really messy is going on
07:48karolherbst: mupuf: do you know how reverse prime reacts to "strange" refresh rates?
07:49mupuf: what do you mean by strange?
07:49codehotter: laptop display is still working
07:49mupuf: is it linux 4.4?
07:49karolherbst: 60.15 on intel
07:49codehotter: but the external display is completely black now
07:49mupuf: well, it is not supposed to care about the refresh rate
07:49karolherbst: ohh k
07:49mupuf: but nvidia landed some patches in the intel drm
07:49codehotter: if I disconnect the HDMI display, my mouse cursor is normal again on the laptop display
07:49mupuf: to get rid of tearing
07:49karolherbst: because codehotter has some strange problems ;)
07:50mupuf: which means it is waiting for the display to be done with the buffer before reusing it
07:50mupuf: is 4.3 working?
07:50karolherbst: codehotter: care to check 4.3?
07:50codehotter: Plugging in HDMI has the following effect: 1) nothing appears on hdmi display 2) on laptop display, my mouse cursor disappears when not being moved, and occasionally I see multiple cursors
07:51codehotter: I can try 4.3, sure!
07:51codehotter: wait, my distro doesn't carry packages for it
07:51mupuf: codehotter: what distro is that?
07:51karolherbst: codehotter: what is the next older kernel you could use?
07:52mupuf: any 4.x kernel should be fine, I guess
07:52mupuf: except 4.4, of course :p
07:52codehotter: I am on Fedora 24 (rawhide)
07:52codehotter: mostly because I tried to upgrade from F22 to F23 and it upgraded me to rawhide instead. I don't know why. I'm fine with it, because I can catch issues before my other team mebers eventually have to update
07:52codehotter: I can try to recompile Fedora 23 kernel
07:53karolherbst: yeah try to get a pre 4.4 kernel working
07:53karolherbst: because if that works we know something messed up
07:54karolherbst: codehotter: could you still give us your dmesg output?Ü
07:54karolherbst: and x log
07:54karolherbst: maybe something interessting is in their
07:54codehotter: Is my browsing history in there? :P or anything else private?
07:55codehotter: Oh, I see some kind of stacktraces
07:55karolherbst: dmesg is just the output of your kernel
07:56karolherbst: mhh invalid EDID
07:56karolherbst: yeah well, that makes somewhat sense
07:57karolherbst: mupuf: seems like reading out the EDID is somehow broken?
07:57codehotter: should I try another monitor?
07:57karolherbst: or the display just sends garbage
07:57karolherbst: codehotter: if you have different ones, yes
07:57codehotter: yea I do
08:00mupuf: this is likely the hw lying about the output being connected to the nvidia gpu
08:00codehotter: the second monitor isn't hdmi
08:02karolherbst: mupuf: how can this happen?
08:02mupuf: the presence detection line may be wired to both the intel and nvidia gpu?
08:02mupuf: sounds funky
08:02karolherbst: mupuf: well the VGA port is wired to intel and this one works
08:03mupuf: or ... the hdmi port is broken?
08:03mupuf: no idea on hdmi if the EDID are read through dedicated wires or not
08:03karolherbst: mupuf: can we start a X server on the nvidia gpu while the main xserver already grabbed the card through the ddx?
08:04mupuf: don't think so
08:04mupuf: http://4.bp.blogspot.com/-PsXAe3bsRzc/T9uz064HlCI/AAAAAAAAAZg/GiiiQP5MbTI/s1600/hdmi_pinout.png <-- the i2c lines are still separate
08:04mupuf: so, it is possible that the cable is broken, or the connector
08:05codehotter: I attached a TV with hdmi cable
08:05mupuf: but if it is a regression, then it is weird and should be investigated
08:05karolherbst: codehotter: ohhh a TV
08:05karolherbst: like a old one or a new one?
08:05mupuf: codehotter: did it used to work?
08:05karolherbst: and with old I mean like 5 years
08:05codehotter: mupuf: first time I'm trying
08:05mupuf: karolherbst: TVs should be no probs
08:05codehotter: karolherbst: no, it was a monitor just now, I'm testing a TV to see if it's any better
08:05karolherbst: nah, I meant maybe we have to test a really low resolution
08:05karolherbst: ohhh okay
08:06mupuf: codehotter: same cable?
08:06codehotter: same cable
08:06mwk: all 6 G80 LUT ops simulated down to a bit :)
08:06karolherbst: codehotter: and does it work?
08:06codehotter: OK so now what happened is, I briefly had mirrored input, but now the TV is a 'screenshot' of what I had a mmoment ago
08:06codehotter: and only my laptop display is working
08:06mwk: now I just need that with less copypaste
08:06codehotter: also, my cursor is still really strange
08:06karolherbst: codehotter: same errors in dmesg?
08:06mupuf: mwk: what ops? Which processor?
08:06mupuf: back to the vp2 REing?
08:07mwk: mupuf: the main shader/compute one
08:07mwk: rcp, rsqrt, sin, cos, ex2, lg2
08:07codehotter: DDC responded, but no EDID for DP-3
08:07mupuf: oh, I see, nice
08:07codehotter: it's still putting it as DP-3
08:07karolherbst: mupuf: seems like you are most likely right, broken port or broken cable
08:07imirkin: mwk: interesting... we knew about sat modifiers on ex2 & co for fermi, but not tesla
08:07codehotter: karolherbst: if I boot into windows it all works
08:07mwk: I'll have to throw in presin/preex2 for a complete set
08:08codehotter: without issue
08:08karolherbst: codehotter: k
08:08karolherbst: I wanted to ask that next
08:08mwk: imirkin: tesla has it only on ex2
08:08karolherbst: codehotter: okay, do this then
08:08karolherbst: codehotter: stop your X server
08:08karolherbst: codehotter: create a local xorg.conf file with this content: https://gist.github.com/karolherbst/3cd9e29e31a4d4e21cbc
08:09mwk: rcp,rsqrt,lg2 have neg/abs input mods, ex2 has sat mod, sin/cos have none
08:09karolherbst: I hope your nvidia card is located at 01:00.0?
08:09karolherbst: you can check with lspci
08:09imirkin: mwk: cool. sat modifiers are funny... i think fmul has one but only on g200+
08:09mwk: I'll check it
08:09imirkin: this was determined experimentally :)
08:10mwk: if they really added modifiers after the fact... I'm doing my testing only on G200 so far
08:10mwk: so it's possible that ex2 sat is also G200+ only
08:10codehotter: karolherbst: yes it's 01:00.0. If I stop my xserver, I have to cancel the kernel compilation because I started it here
08:10karolherbst: codehotter: and do this: Xorg :8 -config $path_to_created_file_here -sharevts -noreset
08:11codehotter: Is the test with 4.3 still relevant?
08:11hio33: What level of hardware documentation is required to most easily write a performant OpenGL driver?
08:11karolherbst: codehotter: yeah we could test that
08:11karolherbst: codehotter: but can't you continue the compilation later?
08:11codehotter: OK then I'm going to let it finish
08:11karolherbst: hio33: if you got a lot of time, then none
08:11codehotter: I'd have to start over. I'm using a clean rebuild in chroot, not compiling manually
08:12imirkin: mwk: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_target_nv50.cpp#n192
08:12mupuf: mwk: amazing job, that's very nice :)
08:13imirkin: you don't get an invalid opcode or anything with that bit set, it just... doesn't saturate.
08:13karolherbst: Tom^: did you test with both commits applied?
08:13mwk: yeah, as usual for unused bits
08:13hio33: karolherbst: if Nvidia released the equivalent amount of information that AMD did, would that satisfy the requirement? I'm talking kernel driver not firmware.
08:13mwk: I guess they did add it later
08:13Tom^: karolherbst: niet. trying to fix up this ipad for work. then i got to make food and do some laundry
08:13Tom^: karolherbst: life sucks. :P
08:13mwk: all the more reason to run my test on different GPUs...
08:14imirkin: hio33: it takes a lot to write a performant GL driver. the issues tend to be around (a) compiler quality and (b) resource management
08:14imirkin: hio33: neither of those require much documentation
08:15karolherbst: I think an important factor is more the compiler quality itself
08:15karolherbst: like how to schedule instructions, reduce register usage
08:15karolherbst: usual stuff
08:15imirkin: hio33: however if this is a veiled "how come nouveau is so slow" question, that has nothing to do with opengl -- it has to do with clock speeds.
08:15karolherbst: well pixmark_piano is pretty fast on nouveau
08:15karolherbst: 90% perf compared to the blob
08:16hio33: imirkin: so the compiler is implemented in user space?
08:16imirkin: hio33: sure
08:16imirkin: karolherbst: ... if you change clocks.
08:16mwk: imirkin: I'm going to cover all arithmetic opcodes with testcases like that, btw, so if there are any funny differences between GPUs we should know...
08:17mupuf: mwk: you think they changed the semantic of ops between families?
08:17hio33: So let me reword my question, how much documentation is needed to write a performant compiler?
08:17mwk: mupuf: could be.
08:18imirkin: mwk: neat :)
08:18karolherbst: imirkin: yes, but this case is special anyway
08:18karolherbst: hio33: well you need documentation about all hw instructions basically
08:18imirkin: hio33: one would need detailed info about the shader's execution model, instruction delays, etc.
08:18mupuf: well, let's hope not too often :) That would be great to get a new GPU, run the hw tests, make them pass then write the changes for mesa
08:18mwk: mupuf: from imirkin's information, they definitly added some features on G200
08:18mupuf: adding is not surprising
08:19hio33: Are you talking about OpenGL instructions?
08:19mupuf: I just wondered how common it was for them to change. I guess not too common because it would be a pain for the compiler guys
08:19mwk: but I'd not be at all surprised if nv40 or gf100 used an entirely different SFU algorithm
08:19mupuf: hio33: those do not exist
08:19imirkin: hio33: no, the shader executor... kinda like the CPU. but GPU :)
08:20hio33: So you basically need to know how the firmware works?
08:20imirkin: talking about "OpenGL instructions" is the same nonsense as talking about "C++ instructions"
08:20imirkin: huh? no, how the hardware works.
08:20imirkin: what firmware?
08:20hio33: The firmware that's run inside the card
08:20mwk: mupuf: as for the instructions themselves [not implementation details], there are apparently 3 or so versions of Fermi ISA
08:20mupuf: hio33: https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline you need to understand this
08:21mwk: but we don't know of any difference between them
08:21mwk: would be nice to find out
08:21mupuf: hmm, that is interesting!
08:21mupuf: clearly, yes
08:22mupuf: hio33: when you understand this article, you will be in a position to understand our answers and you will likely be able to infer them
08:23mupuf: good thing is that nvidia will likely help us on the resource management since nouveau is being used on at least of few products
08:23hio33: mupuf: I'll read it. Isn't there *stuff* in-between the shader and the kernel driver though? Doesn't the graphics chip basically have an ARM core managing it?
08:23mupuf: I mean, one product, but it sold at least a few of those :D
08:23imirkin: there are auxiliary cores
08:23imirkin: but... they don't do any heavy lifting
08:24mwk: mupuf: ideally we'd have a testsuite like the vp1 one for the shader cores
08:24mupuf: mwk: agreed, but that is a shit-ton of work, isn't it?
08:24karolherbst: hio33: gpus have an instructions set like cpus
08:24hio33: So does AMD provide documentation for their shader pipeline then?
08:24mwk: the vp1 test generates random instructions, random hardware context, single-steps, and checks against the simulator
08:24mupuf: no idea how you managed to write these tests so quickly
08:24mwk: but... that's not so easy for shaders
08:24mupuf: do you have a reference implementation?
08:24mwk: since you have *lots* of state
08:25mupuf: and not all of it is accessible
08:25mwk: and you have to be very careful to exclude instructions that can do weird stuff, like branching
08:25mwk: or modifying global state
08:25imirkin: mwk: other than the hidden address bit, is there anything?
08:25mwk: and test them separately somehow
08:25mwk: imirkin: what hidden address bit?
08:25karolherbst: hio33: no idea if they do, but most likely
08:25imirkin: the "this address register is now stuck" hidden address bit
08:25mwk: umm what?
08:26imirkin: if you set it to too high a value?
08:26imirkin: am i making that up?
08:26mwk: it's the first time I heard of that...
08:26hio33: karolherbst: do gpu isa correspond to OpenGL commands at all?
08:26imirkin: so that when you go out of bounds, you never come back
08:26mupuf: imirkin: a lot of the state is not exposed through MMIO, only xfer can access it IIRC
08:26karolherbst: hio33: mhh do cpu isa correspond to C commands at all?
08:27mwk: imirkin: anyhow, as for annoying state... barriers, for one
08:27mwk: the whole call stack
08:28imirkin: yeah........ ok.
08:28mwk: the varying inputs to pixel shaders - we don't even know what these look like
08:29mupuf: you would need to enable full preemption to be able to reverse that, right?
08:29mwk: mupuf: as for SFU reference implementation, yeah, I made one
08:30hio33: So seriously why doesn't Nvidia release docs for their shader pipeline? Is it really about patents?
08:30mwk: I need to uncopy-paste it, but it works perfectly
08:30mwk: mupuf: yeah, single-stepping would be nice
08:31mwk: luckily, I can do that for Teslas except G80
08:31imirkin: hio33: because they don't have to? who knows
08:31mupuf: mwk: save the full state, single step, save the full state then diff?
08:31mupuf: yep, would be nice :)
08:31hio33: imirkin: trying to use software as an advantage over the competition?
08:31mwk: and, being me, I'd also write random crap all over the state beforehand
08:31mupuf: isn't the full preempt buggy on tesla?
08:31mwk: oh, no
08:32mwk: it's a different thing
08:32mwk: I cannot save and restore the whole graph's state
08:32imirkin: hio33: releasing takes more effort than not releasing. they don't see any upside to releasing.
08:32imirkin: hio33: at least that's what i assume is their thought process
08:32mwk: but the ISA-visible state can be looked at and modified
08:32hio33: imirkin then my next gpu will be AMD lol
08:33imirkin: hio33: good plan
08:33mupuf: mwk: ack, sounds sufficient then
08:34hio33: With Vulkan will it be easier to develop open source graphics stack?
08:34hio33: Also, BTW, why is it so difficult to change a clock speed? Please don't flame me...
08:34karolherbst: Tom^: ohh wait, but could you switch to the 0d pstate and cat the cstate file in debugfs?
08:34imirkin: hio33: if you do it wrong, the gpu hangs. there are tons of parameters, and we don't know where to get them from.
08:35hio33: Can't you just copy what the blob does?
08:35Tom^: karolherbst: uhm sure, before the mem change you did everything sort of worked, went from 07 to 0d and jumped fine between cstates. just that it never went below 0d again.
08:35Tom^: karolherbst: after mem change all hell broke loose. :P
08:35imirkin: hio33: sure. and that works great. on that one gpu.
08:36karolherbst: Tom^: doesn't relly matter, I just need the cstate table nouveau generated
08:36imirkin: hio33: but take a slightly different model, with slightly different ram chips, and ka-boom
08:37karolherbst: yeah lol, on the ubuntu machine where the fermi card is in, somewhat set the taskset to 1 for all process, so everything ran by the user runs on the cpu core 1 :/
08:38hio33: imirkin: will the chip actually brick, or will the onboard firmware prevent that?
08:38mupuf: hio33: it is almost impossible to brick a GPU
08:38mwk: some of us tried :)
08:38hio33: That's good
08:39imirkin: hio33: i wouldn't say the gpu is unbrickable, but normally it'll just hang until you reset it
08:40hio33: When developing a driver for modern undocumented GPU, is there ever a difficulty in knowing what responsibility the onboard firmware has versus what the driver should take?
08:40imirkin: not really...
08:40karolherbst: hio33: well that's part of the RE thing to fine out ;)
08:41karolherbst: but usually if the nvidia driver does something, then nouveau also needs to handle that
08:43hio33: Thanks for being active and answering my stupid questions, I'll go read up on how a gfx card actually works. Seems like anandtech is not enough :D
08:44hio33: Oh and does anyone know the irc chan for AMD's new driver?
08:45imirkin: "new driver"?
08:45imirkin: open source amd stuff in #radeon
08:46imirkin: closed source amd stuff in #ati iirc
08:48mwk: that leaves presin
08:49mwk: I guess I'm supposed to multiply the input by something close to 2/pi
09:12karolherbst: RSpliet: yeah, your stuff seems to compile fine now :)
09:14mupuf: mwk: would be nice to find if they sacrificed precision over cost of implementation :)
09:15karolherbst: RSpliet: stuff will be here: https://github.com/karolherbst/nouveau/commits/fermi
09:29karolherbst: RSpliet: maybe I take a look at core reclocking first, because that also doesn't seem to work yet
09:29karolherbst: and it may be actually easier to implement
09:41mwk: mupuf: of course they did
09:41mwk: that's called "floating point math"...
09:41mupuf: and LUTs ;p
09:42mwk: jokes aside, presin is just a multiply with 0x0.a2f983 + denormalization
09:53mwk: ok, that covers all the ops
09:54mwk: my TODO list says I should also check condition code output and shared space input...
11:32karolherbst: mupuf: I have the same ssh issues here in local network :O
11:32mupuf: karolherbst: cisco modem/switch?
11:33karolherbst: openwrt tp-link
11:33mupuf: because in my case, it definitely is due to the modem
11:33karolherbst: ohh k
11:33mupuf: I have a switch before it now, and all my issues are gone. You still have it because you have to go through the modem
11:33mupuf: and this is a known problem
11:34karolherbst: ohh fermi core reclocking works already?
11:34mupuf: that I may solve by putting it in bridge mode, or just returning it
11:34mupuf: karolherbst: I would suggest checking with nvatiming to verify
11:34karolherbst: well pstate returns higher clocks
11:35karolherbst: and offloading seems to work
11:36karolherbst: well the difference with glxgears doesn't seem that great, odd
11:40karolherbst: meh, everything just takes agaes though ssh :/
11:40karolherbst: maybe there is something funky with the kernel
11:41karolherbst: and I think I found a bug with my pcie stuff
11:48karolherbst: mupuf: we have to make the nouveau kernel a bit more resistant to infinite loops and such stuff... this is a bit annoying when the nouveau module hangs the entire system to death, allthough it doesn't do anything
11:52karolherbst: .... seriously? "netpoll: netconsole: wlan0 doesn't support polling, aborting" ...
11:52mupuf: karolherbst: how do you want to make it more resistant?
11:53karolherbst: mupuf: not to do stuff like that: https://github.com/karolherbst/nouveau/blob/master_4.4/drm/nouveau/nvkm/subdev/pmu/base.c#L63-L65
11:53karolherbst: this should -ETIMEOUT at some point
11:54mupuf: yes! Definitely!
11:54karolherbst: and we can't use nvkm_msec here either ;)
11:54karolherbst: because that can also hang infinitly
11:54karolherbst: but ben said he may take care of this, so I wait for this
11:58karolherbst: mupuf: this is so annyoing...
11:58karolherbst: now the laptop is even connected through a cable
11:59karolherbst: same issue still
12:04mupuf: karolherbst: hmm
12:04mupuf: can you check if you have a lot of packet loss?
12:05mupuf: ping -i 0.2 google.com
12:05karolherbst: from where should I execute it?
12:05mupuf: your machine
12:05mupuf: your laptop*
12:05karolherbst: well usually I have none, why?
12:06mupuf: you can ping another local machine too, if you want
12:06mupuf: because that's where my lag comes from
12:06mupuf: if you have packet loss, I also suggest you check with wireshark what is going on
12:06karolherbst: internal network stuff feels different
12:06karolherbst: but no package lost
12:07karolherbst: ping is just between 20ms and 2000ms
12:07karolherbst: actually between 5ms and 2000
12:07mupuf: is this wifi?
12:07mupuf: 5ms is a lot already
12:07karolherbst: ohhh wait
12:07karolherbst: there is a pattern
12:07karolherbst: looks like package bundling
12:08karolherbst: good thing is, I can install software on my router :)
12:08karolherbst: bad thing is, there is like 8k space
12:09mupuf: tcpdump may fit :D
12:09mupuf: but I highly doubt it
12:09karolherbst: actually there is a webserver on it
12:09karolherbst: for the admin GUI stuff
12:09karolherbst: maybe it was 8m
12:09karolherbst: because it has alos 32mb ram
12:10mupuf: sounds more likely
12:11karolherbst: and now I can't ping my other laptop anymore :/
12:15karolherbst: yeah there is some weird stuff going on
12:15karolherbst: mupuf: it is even better with my laptop on wifi and the other one via ethernet
12:16karolherbst: this pattern ...
12:17karolherbst: mupuf: ping 220.127.116.11 gives me like 2-6 ms :D
12:18karolherbst: and my router gives me like 0.8ms
12:18mupuf: sounds more reasonable
12:18karolherbst: mupuf: maybe some internal routing is just bricked?
12:18karolherbst: my router uses a 3.18 kernel by the way
12:18mupuf: how about you just check out what is happening using wireshark? :D
12:19karolherbst: well I got an idea
12:19karolherbst: because I don't think wireshark will tell me anything
12:19mupuf: it will show you the traffic, you'll see if this is a local issue or your router's
12:19karolherbst: yeha lol, the other laptop just hangs for no apperant reason now
12:27karolherbst: uhhhh the kernel ooms....
12:28karolherbst: fcitx just uses over 92% of memory ...
12:35mupuf: karolherbst: 2016-01-12 22:35:03: (WW) The build got broken due to commit '61c2468'
12:35mupuf: It also bisects compilation failures now
12:36karolherbst: nice :)
12:36karolherbst: but I think this can do git bisect already ;)
12:36mupuf: the goal is to leave the thing unattended
12:37mupuf: and it will bisect the performance of multiple benchmarks on multiple commits
12:37mupuf: and data will be added every day
12:37mupuf: when a list of commits do not compile, what do you do with the tests? :D In this case, I will move them to before and after the build failure
12:38mupuf: this is nothing git bisect would do for me
12:39imirkin: karolherbst: btw, unless you're passing --sysconfdir=/etc but then not installing the drirc there, it should be loading the correct drirc for you
12:39mupuf: and more importantly, I never have to tell it what to do
12:39imirkin: karolherbst: make sure you *DO NOT* use LIBGL_DRIVERS_PATH, and *always* make install and use LD_LIBRARY_PATH
12:40karolherbst: I meant broken builds
12:40karolherbst: imirkin: :/ meh
12:40karolherbst: then I have to specify an install path :D
12:41imirkin: karolherbst: do you want it to work, or do you want to have these issues every time?
12:41imirkin: make the install path ~/install
12:41imirkin: that's what i do
12:41mupuf: yop, same here
12:42mupuf: karolherbst: http://fs.mupuf.org/mupuf/nvidia/dev-env.sh
12:42mupuf: source this in your .bashrc (or whatever shell you have)
12:43mupuf: and then, when running configure, add --prefix=$NVD
12:43mupuf: all this is documented in the wiki of nouveau btw :p
12:43karolherbst: mupuf: okay, in the end it was fcitx fault for ooming the kernel
12:44karolherbst: mupuf: maybe your router is running out of memory? :/
12:44mupuf: Fcitx (Flexible Input Method Framework) is a lightweight input method framework aimed at providing environment independent language support for Linux. --> Super lightweight if it OOM the kernel :D
12:44karolherbst: I guess there was a bug
12:44mupuf: sure, that was a joke :P
12:44karolherbst: and the config file got messed up or something
12:44mupuf: No idea about the router
12:44mupuf: but it is cisco's fault, not mine
12:44mupuf: they rolled an updated and boom
12:44karolherbst: maybe it has to send to many data to the NSA and the encryption stuff needs to much memory
12:44karolherbst: who knows
12:45karolherbst: mupuf: an update fixed it or since an update it runs badly?
12:45mupuf: the latter
12:45karolherbst: can't you simply install a older software?
12:46mupuf: I do not have control on it
12:47karolherbst: damn you cisco
12:47mupuf: yop, overpriced shit
12:49karolherbst: ohh wait
12:49karolherbst: now I got a drop
12:49karolherbst: couldn't even ping on the laptop
12:49karolherbst: restarted networkmanager / or waited, who knows, and now it works again
12:49karolherbst: maybe dhclient is messing up?
13:05karolherbst: mupuf: just noticed, after the gpu got suspended, some pci regs seems to be empty out of the sudden
13:06karolherbst: nvapeek 0x80000 0x1000 returns ...
13:06karolherbst: ohh it was 88
13:06karolherbst: silly me
13:10gryffus: karolherbst: hi, i just wanna tell you, if you need some fermi testing, i have GeForce GT 440 here.
13:29ravior_: I've updated the defect for Bug 71659. Using a combination of debug parameters for nouveau I think I got a little closer to the problem.
13:30imirkin: ravior_: please update your kernel
13:30imirkin: ravior_: an important fix went into 4.2.5 or so
13:31imirkin: ravior_: which resolved issues for many plasmashell users
13:31ravior_: Unfortunately I can't do that because of a kernel panic problem on the hardware I'm using. https://bugs.archlinux.org/task/46894
13:31imirkin: ravior_: can you apply a patch?
13:32ravior_: For the kernel I'm using? Sure.
13:33imirkin: ravior_: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a6c521bb41ce862e43db46f52e7681d33e8d771
13:33imirkin: no idea if it'll solve your problems, but it can't hurt :)
13:34ravior_: imirkin, Thanks for the guidance. I'll reply with more info after I'll try it out. Thanks again.
13:35imirkin: ravior_: there are also a bunch of fixes to various things in drm-next if you dare try such a cutting-edge kernel
13:35imirkin: ravior_: although none *directly* addressing a ctxsw timeout
13:37ravior_: Unfortunately, I've tried a bleeding edge kernel (4.4 RC7), but it seems that it freezes after initializing the random pool.
13:37ravior_: That problem happens on e6420 from Kernel 4.2.3
13:38imirkin: ravior_: sad. well i don't have time to debug your other issues :)
13:38ravior_: imirkin, Sad indeed. Thanks for your help. It was more than I expected. :)
13:38ravior_: I'll take it one step at a time.
13:39ravior_: I'll eventually get to the bottom of this.
13:39karolherbst: skeggsb: ohh there needs to be a little pcie fix :/
13:42karolherbst: skeggsb: https://github.com/karolherbst/nouveau/commit/83110ed1e2ad96da5f77491b294a9d897abf9404
13:43imirkin: karolherbst: oops :)
13:44karolherbst: yeah, kind of
13:45imirkin: karolherbst: send to ml... ben can miss things in scrollback
13:46karolherbst: ohh wait, there needs to be more actually I guess
13:47karolherbst: now it looks good: https://github.com/karolherbst/nouveau/commit/c6b1409e6b2ba159af14c06a3cc5e5c0bea43c80
13:48imirkin: what was wrong with the original?
13:48imirkin: i mean, it should be
13:49imirkin: if (!pci || !pci_is_pcie(pci->pdev))
13:49imirkin: the extra pci && bit you added is unnecessary
13:50karolherbst: makes sense
13:53karolherbst: then the issue was a missing !
13:54karolherbst: now to fermi performance :)
13:59karolherbst: mhhh the gpu isn't fast enough that the pcie link matters much
13:59karolherbst: glxgears 0f: 4024 fps, 0f+5.0GT/s: 4105 fps
14:00imirkin: for what situation?
14:00imirkin: the one where everything is in vram?
14:00karolherbst: 07: 3700fps 07+5.0GT/s: 3713fps
14:01karolherbst: imirkin: well on my laptop the difference is pretty huge
14:01imirkin: coz you render into vram, then copy from vram over the pci bus to the other gpu
14:02karolherbst: ohh so memory performance is also important
14:03mwk: imirkin: ex2.sat works just fine on G98 too
14:03imirkin: mwk: cool. but fmul.sat doesn't... at least not on G96
14:04imirkin: i don't think we ever tested on G98
14:04mwk: I'll also try G80 when I can get it powered up
14:06mwk: yeah, no differences at all between G98 and G200 SFU results
14:09karolherbst: Tom^: you need actually more, so when you got time, ping me :D
14:09karolherbst: RSpliet: so core reclocking on fermi seems to work
14:13karolherbst: 195 fps for glxspheres on my fermi
14:13karolherbst: ohh wait
14:13karolherbst: 252 fps on 0f pstate
14:13karolherbst: only 248 without pcie reclocking
14:14karolherbst: 25% more perf
14:14karolherbst: RSpliet: do we want to enable some fermi reclocking for 4.5 then?
14:14karolherbst: pcie and core?
14:14karolherbst: we can add support for memory always later then
14:16karolherbst: gryffus: do you have a self compiled kernel?
14:16karolherbst: gryffus: you could try out if the engine reclocking bits are already working for you
14:17karolherbst: it doesn't do much though, but it is at least something
15:04Helios747: I was told that it's possible to get a setup working where I can switch between nouveau and nvidia's blob without having to swap around packages all the time. How do I get this to work? I have nvidia optimus (Haswell GPU + GT 755m), am not driving a second display, only the laptop's display. I was told that's the best case scenario for what I want?
15:04Helios747: I just need DRI3? How do I set this up in Ubuntu?
15:05imirkin: Helios747: make sure your intel ddx is built with --enable-dri3
15:05imirkin: Helios747: and then throw Option "DRI" "3" into your xorg.conf's device section
15:06Helios747: What is ddx?
15:06imirkin: Helios747: xf86-video-intel, in your case
15:07Helios747: Gotcha, I'll look at how that package is built
15:07imirkin: Helios747: btw what gpu is that GT 755M? just want to make sure it's not a maxwell...
15:08Helios747: Is that what you meant?
15:09Helios747: Huh, googling that shows it both as a 6xx series chip and a 7xx series
15:09imirkin: Helios747: GK107 is kepler, you're good.
15:10imirkin: Helios747: marketing names have little bearing on what's inside the wrapping unfortunately
15:11Helios747: I've read about instances of some newer gen GPUs being from the same gen as the "older gen"
15:11Helios747: Heh, interesting that I got one of those.
15:11Helios747: Guess it works out for what I want to do in this case
15:11imirkin: nah... most 7xx's are keplers
15:11imirkin: but a few are maxwell
15:12Helios747: Why would it be a problem if it was maxwell?
15:12imirkin: there's little rhyme or reason to the numbering scheme. i'd just stick to the chip names :)
15:12Helios747: Does nouveau have problems with maxwell atm?
15:12imirkin: the 3d stuff isn't as well developed/maintained
15:12imirkin: nobody has one
15:12Helios747: Which is sorta what I'll need for Dolphin testing ;)
15:12imirkin: (at least nobody who works on the GL stuff)
15:13imirkin: i'm waiting for the GM20x situation to get resolved before thinking too hard about it
15:13imirkin: Helios747: btw, if you're looking for performance, you might want to check out karolherbst's kernel branches which have improved reclocking capabilities
15:14imirkin: Helios747: although it'd be worth trying with just a vanilla kernel 4.4 install
15:14karolherbst: imirkin: though I suspect default nouveau should be plenty for his gpu
15:14karolherbst: normally mobile chips don't do 1.2V volting
15:14imirkin: Helios747: that's only if you want to be able to increase your gpu clocks... which you might want to do if you want dolphin to be playable
15:14Helios747: I'm mostly doing this for testing while we're in feature freeze. Not to actually play Dolphin on
15:15karolherbst: Helios747: stock clocks are _slow_
15:15imirkin: Helios747: ok, then any kernel should do just fine. default clocks are something like 10% of max.
15:15imirkin: (depends on exact config of course)
15:15Helios747: karolherbst, link to your branch? >_>
15:15imirkin: maybe less. they like to save power for some reason.
15:15karolherbst: Helios747: well stock should be fine though
15:16karolherbst: imirkin: I think on mine it is like 25%
15:16karolherbst: maybe 20%
15:16imirkin: Helios747: just use kernel 4.4. if that doesn't work, we can move up from there
15:16imirkin: karolherbst: really? your default memory clock speed is...
15:16karolherbst: pretty fast actually I think
15:16imirkin: and max?
15:16Helios747: Alright. That should be easier than trying to argue with Ubuntu's package manager and video drivers. Heh
15:17imirkin: karolherbst: oh. that's low.
15:17karolherbst: it's not that fast
15:17imirkin: i thought 6G was standard as the gddr5 max clock speed
15:17imirkin: or 7G
15:17karolherbst: but it's 192 bit
15:17karolherbst: imirkin: the 780M also has only 5000
15:17karolherbst: but 256bit
15:18karolherbst: his will have 5400MHz, but only 128 bit ;)
15:18karolherbst: 128 bit is the usuall stuff except for those more high end gpus
15:19Helios747: So when I install nvidia's drivers from ubuntu's repos, it'll blacklist nouveau. Should I manually go in and remove that blacklist? How will I stop the drivers from fighting each other on boot?
15:20karolherbst: imirkin: https://gist.github.com/karolherbst/f8cc576dc8b2f7690383
15:20imirkin: Helios747: blacklist both
15:20imirkin: Helios747: problem solved :)
15:21Helios747: I'm assuming you're being sarcastic. :P
15:21imirkin: Helios747: actually not really...
15:21imirkin: karolherbst: usb-related it seems
15:22Helios747: Hah, do I just have to set ubuntu to not start x on boot and modprobe the driver I want to use on boot, then startx?
15:22Helios747: Wait, no I shouldn't have to, the intel GPU is still there
15:22Helios747: and loaded
15:23Helios747: Sorry, I'm not particularly knowledgable about this. :P
15:23Helios747: I've never used nouveau much, actually
15:23imirkin: no worries
15:23imirkin: we all gotta start sometime
15:23karolherbst: that went bad
15:25karolherbst: Helios747: I have such a setup
15:25karolherbst: also on another the ubuntu machine I have here, too
15:26Helios747: mmm, don't think my xf86-video-intel package was built with --enable-dri3
15:27Helios747: Gotta rebuild it
15:27imirkin: yeah, they disable it by default
15:27karolherbst: Helios747: xorg-edgers ppa
15:27karolherbst: you want to use that
15:28Helios747: karolherbst, I was *thinking* about using that >_>
15:28Helios747: Sure, my system will probably crash a lot, but it'll do all the work for me. :D
15:29karolherbst: why should it crash a lot?
15:29Helios747: Last time I used that repo on a different system it was *not happy*
15:29Helios747: that was several years ago though
15:29karolherbst: ohh I see
15:29karolherbst: yeah maybe now more care about stable devpackages too
15:30karolherbst: using it for months on my other machine though
15:30karolherbst: good thing is, they have dri3 enabled
15:30Helios747: Yeah. Things change, improve. And this is a different system
15:30karolherbst: and this is basically the easiest way if you want to have bleeding edge opengl on ubuntu
15:30Helios747: Plus I really don't want to go through the effort of recompiling packages... heh
15:31karolherbst: imirkin: on one scene in unigine heaven: 3fps => 10 fps
15:31karolherbst: from 07 to 0f
15:31Helios747: I think cononical has some kernel 4.4 package with an ubuntu config somewhere
15:32karolherbst: imirkin: 0a gives only 5 though and there I have max core clock already
15:32karolherbst: but 1620MHz memory
15:36karolherbst: RSpliet: by the way, where could I find your SEQ scripts?
15:36imirkin: skeggsb: just did a little trace of a shadertoy shader to see where all the cpu time that X was taking up was going
15:36imirkin: skeggsb: looks like it's all going to nvkm_instobj_new: http://hastebin.com/jehonubuwe.md
15:36imirkin: skeggsb: this is with kernel 4.3.0
15:48Helios747: Hmm, I installed the xorg-edgers ppa and updated, glxinfo shows version string as Mesa 11.0.4
15:48Helios747: Shouldn't that be higher
15:49Helios747: Or some git hash, at the very least
15:49Helios747: 4.4 booted correctly at least
15:49imirkin: Helios747: add "options nouveau pstate=1" into some modprobe.conf file
15:51Helios747: I ran an 'update-initramfs -ck all' for good measure and this got spit out
15:51Helios747: W: Possible missing firmware /lib/firmware/i915/skl_guc_ver4.bin for module i915
15:51Helios747: Should I be concerned
15:52imirkin: do you have a skylake gpu?
15:52imirkin: doesn't matter then
15:52imirkin: skl = skylake
15:53imirkin: hsw = haswell
15:54Helios747: stuck that line you gave me in a modprobe.d config file, updated the initramfs and rebooted. Still getting 11.0.4 with 'glxinfo | grep OpenGL'
15:55imirkin: oh sorry, it wasn't supposed to address that
15:55imirkin: it was supposed to allow you to reclock once you load nouveau :)
15:55imirkin: the glxinfo thing is the version of mesa you've installed
15:55Helios747: Well that's good too!
15:55imirkin: perhaps you didn't do an apt-get distupgrade or however debian works
15:55Helios747: Yeah, shouldn't that be higher since I'm on the latest?
15:55imirkin: sorry, i use gentoo
15:55imirkin: things are easy there.
15:55Helios747: I did apt-get dist-upgrade
15:55imirkin: well you clearly are *not* on latest
15:56Helios747: let me check the package version..
15:57Helios747: xserver-xorg-video-intel, version 18.104.22.1687+git20150808-0ubuntu4
15:57Helios747: I see git in there
15:57imirkin: that's the ddx
15:57imirkin: look for things with the word "mesa" in them
15:58karolherbst: Helios747: after switching to the ppa, you _have_ to do apt-get update, upgrade
15:58imirkin: i've heard of "oibaf ppa" as a thing people on ubuntu use. no idea what that is tbh.
15:58karolherbst: crap :D
15:58karolherbst: "Updated and Optimized Open Graphics Drivers"
15:58karolherbst: it has optimized in its title so it is obivously crap :p
15:59Helios747: ahhhh, libgl1-mesa-glx is 11.0.2
15:59Helios747: How the heck? How did that not get updated
15:59karolherbst: imirkin: I think the ppa adds gallium nine support though
15:59imirkin: like i said, i don't know nothin' about no ubuntu. just repeating sequences of letters that i think may be relevant :)
15:59Helios747: karolherbst, I did 'sudo apt-get update && sudo apt-get dist-upgrade'
15:59Helios747: Is that no good
16:00imirkin: does xorg-edgers include updated mesa?
16:00imirkin: i suspect it might be xorg only
16:00karolherbst: Helios747: on which ubuntu are you?
16:00karolherbst: imirkin: also mesa
16:00karolherbst: willy that is?
16:00Helios747: Willy wonka or whatever
16:00karolherbst: it should have 11.0.4~git20151026+11.0.ec14e6f8-0ubuntu0ricotz~wily
16:00Helios747: the latest version released
16:00imirkin: wtf kind of version is that?
16:01imirkin: karolherbst: oh what? 11.0.4?
16:01imirkin: that's what he was seeing
16:01imirkin: karolherbst: why is it so old?
16:01Helios747: I don't see the githash
16:01Helios747: All I see is 11.0.4
16:01Helios747: thats it
16:01Helios747: Version: 11.0.2-1ubuntu4
16:01karolherbst: yeah should be fine for now
16:01karolherbst: imirkin: no clue
16:01karolherbst: imirkin: I thought they use newer packages
16:01imirkin: well, commit ec14e6f8 is the 11.0.4 release
16:02imirkin: so no git hash
16:02karolherbst: anyway, it should work for now
16:02Helios747: Maybe I should just install arch linux and be done with it
16:02imirkin: Helios747: just use oibaf ppa for updated mesa.
16:02Helios747: imirkin, with xorg-edgers?
16:02Helios747: Or without
16:02imirkin: Helios747: with
16:03imirkin: Helios747: you want xorg-edgers coz that has the dri3-enabled intel ddx
16:03glennk: or just run mesa out of the src dir, its not like building it is complicated compared to say building dolphin :-)
16:03imirkin: or does oibaf ppa also have that?
16:03karolherbst: imirkin: xorg-edgers ppa states: fully or none at all
16:03imirkin: karolherbst: ah. well, don't listen to me for ubuntu advice.
16:03Helios747: I'll check to see if oibaf has dri3
16:03imirkin: glennk: i'm assuming a certain aversion to compiling things if one uses ubuntu.
16:04karolherbst: I think oibaf has also dri3
16:04imirkin: glennk: afaik it's fairly difficult to get a reasonable dev environment set up on there
16:04Helios747: It is fairly annoying.
16:04Helios747: I'm pretty close to just installing arch
16:04Helios747: Especially since it wasn't happy with letting me split my LVM+LUKS across two drives
16:21Helios747:flips metaphorical table and installs arch linux
16:21Helios747: Not sure why I didn't go this route in the first place