03:49 mithro: Any recommendations on well supported nouveau cards which might work to drive 3 x 4k monitors via DisplayPort and have OpenGL acceleration for Chrome?
03:50 karolherbst: kepler
03:50 karolherbst: though I am not sure if they can drive 3 4k displays
03:51 karolherbst: somebody might know more about which port combination might work on kepler
03:52 karolherbst: though first gen maxwell is also good enough, but maybe less stable
03:52 karolherbst: mithro: how much performance do you need?
03:53 mithro: karolherbst: Chrome is pretty much the only "3d" application I would be running
03:53 karolherbst: k
03:53 karolherbst: then I would say any kepler or maxwell card might be actually fine
03:54 karolherbst: maxwell2 gpus can't be reclocked with nouveau yet, but this might be possible later this year, depends on nvidia though
03:56 mithro: I was looking at https://nouveau.freedesktop.org/wiki/CodeNames/#NV110
03:56 mithro: I'd want something in the NVE0 family (Kepler) or NV110 family (Maxwell)?
03:57 karolherbst: all GKs and GM10x are fine
03:57 karolherbst: GM20x might be a bit untested yet
03:57 karolherbst: and I doubt anybody every had 3 4K display connected on them with nouveau
03:58 karolherbst: but you can also run into issues on those, but I hope they will be easy to figure out then
03:59 mithro: Any idea where the NVIDIA QUADRO K4200 fits? It seems to be a GK104GL according to wikipedia
03:59 karolherbst: yeah well, we can't know for sure
04:00 karolherbst: wikipedia is most likely your best bet
04:01 mithro: Looking at http://images.nvidia.com/content/quadro/product-literature/line-card/12611_ProGraphicsLineCard_GENERIC_JUN15_US_FNL_HR.pdf - it seems like that only supports 2 monitors on DisplayPort :/
04:02 karolherbst: does it have to be a quadro
04:02 karolherbst: ?
04:04 mithro: Well, I the Quadro K2200 or Quadro K4200 seem to be "supported" by my work
04:05 mithro: karolherbst: but open to any suggestions
04:05 karolherbst: ahh, well usually I would choose plain desktop cards cause they are usually cheaper
04:06 mithro: karolherbst: Graphics card naming is soo confusing :/
04:06 karolherbst: yes it is
04:06 karolherbst: but quadros are usually used for professional stuff
04:07 mithro: I think my work buys them because they come in the workstation machines by default
04:10 karolherbst: yeah well it is your choice in the end
04:10 karolherbst: I don't think many used 4k displays with nouveau yet, so it is all a bit unstable and may break here and there
04:10 mithro: I'm mainly looking for a way to do this setup with FOSS drivers at the moment
04:16 RSpliet: three of those monitors put a big strain on memory bandwidth, although we are improving the ability of changing the memory speed to a point where we can do it with quite a high reliability, I find it hard to say it's ready for prime-time yet
04:16 mithro: karolherbst: soo... I'm looking for something like the GeForce GTX 780 ?
04:17 karolherbst: RSpliet: yeah I would say it too, but he still have the best chances with kepler and maxwell1
04:18 karolherbst: mithro: I think the 780 might be actually fine, Tom^ has a 780 Ti and I worked with him to get nouveau stable on his card
04:18 RSpliet: not sure if you can find a card with so many DP outputs
04:18 karolherbst: but no idea how that goes regarding 4k displays
04:18 karolherbst: RSpliet: there are actually gpus with 6 DP ports....
04:19 mithro: I only need 3.... :P
04:20 karolherbst: but I don't see any pre 900 one with 3
04:20 mithro: karolherbst: where are you looking?
04:20 karolherbst: mithro: https://geizhals.eu/?cat=gra16_512&xf=5425_3~135_DisplayPort~653_nVIDIA#gh_filterbox
04:21 karolherbst: but maybe somewhere else there are some
04:22 mithro: The new Quadro M(X)000 seem to have 4 - they at GM2XX though?
04:23 karolherbst: do you need DP or mini DP=
04:23 karolherbst: ?
04:23 RSpliet: mithro: don't bet on a GM2xx, it'll take us at least half a year to get the memory bandwidth up on those cards
04:23 mithro: Yeah
04:23 mithro: karolherbst: either works for me
04:23 RSpliet: and that's an optimistic assumption
04:24 karolherbst: mhh
04:24 karolherbst: only thing I see is a quadro K1200
04:24 karolherbst: GM107
04:25 karolherbst: but as I said: somewhere else might be other gpus
04:25 karolherbst: I just look at this site because I would also buy from there, cause I live in germany
04:28 mithro: I currently have a GK107GL in this machine apparently
04:31 mithro: karolherbst: so, it seems like I have nouveau running here on that machine with 2x4k monitors - but just the window redraw seems terrible?
04:32 karolherbst: well
04:32 karolherbst: you could try to upclock the card
04:32 karolherbst: and see if that's better
04:32 karolherbst: mithro: what does lspci tell you about the gpu?
04:33 mithro: 05:00.0 VGA compatible controller: NVIDIA Corporation GK107GL [Quadro K2000] (rev a1)
04:33 karolherbst: k2000 it is
04:33 karolherbst: gddr5
04:33 karolherbst: nice
04:34 karolherbst: mithro: which kernel have you running?
04:34 mithro: 3.19 is seems -- 3.19.0-51-generic #58~14.04.1-Ubuntu SMP Fri Feb 26 22:02:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
04:34 karolherbst: uhhh
04:34 karolherbst: that*s bad
04:35 karolherbst: gddr5 reclocking was fixed in 4.4
04:35 RSpliet: karolherbst: and GK107 with GDDR5 was fixed two days ago in your tree :-P
04:35 karolherbst: nope :p
04:35 karolherbst: a few GK107
04:36 karolherbst: there are also gk106 with the same issues
04:36 karolherbst: but only a few
04:36 RSpliet: I wasn't being exact
04:36 karolherbst: :p
04:36 karolherbst: k
04:36 karolherbst: mithro: anyway
04:36 karolherbst: for the best nouveau experience you want a newer kernel
04:36 karolherbst: but tell you waht
04:37 karolherbst: mithro: boot with nouveau.pstate=1
04:37 mithro: and newer xorg too?
04:37 karolherbst: and we could check if you can clock to a stable state
04:37 karolherbst: mithro: doesn't matter
04:37 karolherbst: kernel is what is important
04:37 karolherbst: and mesa
04:38 mithro: I can give linux-image-generic-lts-wily a go which seems to be linux-image-4.2.0-30-generic
04:38 karolherbst: ohh yeah
04:38 karolherbst: that would be better actually
04:38 mithro: It's been a good 10 years since I ran a kernel compiled myself :P
04:38 karolherbst: but also boot with nouveau.pstate=1
04:41 mithro: karolherbst: doing now
04:48 mithro: karolherbst: done, now running 4.2.0-30-generic #36~14.04.1-Ubuntu SMP Fri Feb 26 18:49:23 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
04:48 karolherbst: mithro: nice
04:48 karolherbst: you should have a pstate file in /sys/class/drm/card0/device
04:48 mithro: glxgears gives me 10fps :-P
04:48 karolherbst: uhhh
04:48 karolherbst: that sounds bad
04:49 mithro: yeah...
04:49 karolherbst: k
04:49 karolherbst: lets take a look at the pstate file
04:50 mithro: karolherbst: http://paste.ubuntu.com/15407192/
04:50 karolherbst: ahh good
04:50 karolherbst: echo a > pstate
04:50 karolherbst: I hope your gpu doesn't crash, but it shouldn't
04:51 karolherbst: or maybe it does...
04:51 mithro: [ 414.463066] nouveau E[ CLK][0000:05:00.0] failed to raise voltage: -22
04:51 mithro: [ 414.463075] nouveau E[ CLK][0000:05:00.0] error setting pstate 1: -22
04:51 karolherbst: fun
04:52 karolherbst: yeah, well then you need a even newer nouveau
04:52 karolherbst: let me try something
04:52 mithro: glxgears does give 243 frames in 5.0 seconds = 48.512 FPS now...
04:52 karolherbst: yeah
04:52 karolherbst: memory was clocked up
04:52 karolherbst: if you cat pstate you see higher memory clock
04:52 karolherbst: the voltage error is only core related
04:53 karolherbst: well actually this should be good enough for you
04:53 mithro: if I echo 7 into the pstate, it goes back to 10fps
04:53 karolherbst: yeah
04:53 karolherbst: I hope the desktop feels smoother with a?
04:54 mithro: It seems like f would be what I want :P
04:54 karolherbst: nope
04:54 karolherbst: it will crash your machine
04:54 karolherbst: you need 4.4 for f
04:54 karolherbst: or might crash it
04:54 karolherbst: at some random point
04:54 mithro: yeah a does seem much better
04:55 karolherbst: well if you want really good reclocking you should use 4.5 and a branch I have where I fixed most of the important reclocking stuff for kepler
04:56 karolherbst: but without any effort, that is the best you can do for now
04:59 mithro: karolherbst: should I follow something like https://wiki.ubuntu.com/KernelTeam/GitKernelBuild with your kernel tree?
04:59 karolherbst: nah I don't have a nouveua kernel tree, I just use it out of tree
04:59 karolherbst: this is ubuntu 15.10 or 16.04?
05:00 karolherbst: ohh 14.04.1
05:00 mupuf: what the heck? How can glxgears be sooooo slow?
05:01 mithro: mupuf: It is painting 4k pixels
05:01 karolherbst: mupuf: 2x 4K displays
05:01 karolherbst: mithro: ohh full screen?
05:01 karolherbst: :O
05:01 karolherbst: insane
05:01 mupuf: oh, right
05:01 mupuf: :D
05:01 mithro: Yeah, glxgears almost full screen on one 4k monitor
05:01 karolherbst: yeah okay
05:01 karolherbst: that explains
05:01 RSpliet: mupuf: it's faster than Bob Ross was
05:01 mupuf: Well, you are lucky you still get the display working :D
05:01 mupuf: Bob Ross ?
05:01 karolherbst: mithro: can you use linux-image-generic-lts-xenial?
05:02 karolherbst: it should be there for trusty
05:02 karolherbst: and then you can even use f
05:02 RSpliet: mupuf: http://www.wired.com/images_blogs/photos/uncategorized/rosswii_1.jpg
05:02 mupuf: 2 4k displays is ... mithro, where do you live? I need to pay you a corteous visit :D
05:02 RSpliet: can paint a frame in half an hour
05:02 karolherbst: mupuf: you don't know bob ross :O
05:02 mupuf: RSpliet: LOOOOOL
05:02 mithro: that is a funny package name - linux-image-generic lts, you're in xenial about being out of date :P
05:02 karolherbst: shame on you
05:03 mithro: mupuf: I actually have 3 of them, but this graphics card only has 2 DP outputs
05:03 mithro: and I just don't do 4k@30fps :P
05:03 karolherbst: mithro: http://packages.ubuntu.com/trusty/linux-image-generic-lts-xenial
05:03 mupuf: oh well, good to hear is works for you at least
05:04 mithro: I wonder why I can't apt-get that...
05:04 karolherbst: mithro: might be new
05:04 mithro: Fri, 11 Mar 2016 13:14:24
05:05 karolherbst: well let me check on my other machine
05:06 mupuf: Cheapest 4k screen I found in Helsinki is 440e. I will wait a little longer :D
05:06 karolherbst: mithro: odd, I also don't see any 4.4 kernels here
05:07 mithro: I'm downloading the packages manually and will give them a spin...
05:07 karolherbst: but I don't use trusty here
05:07 karolherbst: mupuf: 440?
05:08 karolherbst: mupuf: found one for 330 here :p
05:08 mithro: I highly recommend *not* getting a 4k monitor, because once you do you don't want to go back
05:08 mupuf: mithro: I know...
05:08 mupuf: one of my colleague has one
05:08 mupuf: this. is. too. tempting...
05:08 karolherbst: ohh I am fine with my 140dpi :)
05:09 mupuf: and my desktop screen is so old that the backlight control is set to 100% and still too dim
05:09 mupuf: I had to change the color profile to see anything
05:09 karolherbst: uhh
05:10 mupuf: so, it is about time I change it ... but I don't want to replace it with my second screen which is really bad quality and only good for my reverse engineering machine
05:10 mupuf: so, a 4K screen would be nice :)
05:10 mupuf: karolherbst: https://www.verkkokauppa.com/fi/product/14583/fqtrs/Samsung-U28E590D-4K-naytto
05:10 mithro: mupuf: I have the "australian variant" of that exact monitor
05:11 mupuf: any good?
05:11 karolherbst: ohh is it upside down?
05:11 mithro: mupuf: They seem really sensitive to the cable quality you use
05:12 mithro: mupuf: the PIP stuff felt like it was going to be more useful then it has been (IE I was thinking I would PIP my laptop)
05:12 mithro: karolherbst: rebooting with that kernel now
05:12 karolherbst: k :)
05:13 karolherbst: mupuf: any experience with networking?
05:13 mithro: karolherbst: so, would something like the 980 / 960 be too new?
05:14 karolherbst: yeah
05:14 mithro: do I still need the pstate thing?
05:14 karolherbst: mithro: yes
05:14 karolherbst: you really want memory reclocking with those displays I assume
05:14 karolherbst: and we really don't know when nouveau will be able to do that on maxwell2
05:14 karolherbst: it is up to nvidia
05:16 karolherbst: mupuf: for REing the speedo stuff we might have to mod some mmio reads :/
05:17 karolherbst: on tegra those values are read out some FUSE registers
05:17 karolherbst: of the host and passed to nouveau
05:17 karolherbst: and there are like a lot of fuse regs we have no clue about
05:18 mithro: Looking at 3 x DP problem, the K1200 might be a option, but it seems like it wouldn't have enough grunt?
05:19 mupuf: karolherbst: we know almost none of them
05:19 mithro: karolherbst: that seems to be NV117 (GM107) ?
05:19 karolherbst: mithro: yeah
05:19 karolherbst: mupuf: I know
05:19 mupuf: karolherbst: why do you want to fake the fuse values?
05:19 karolherbst: mupuf: to see if any of them affects the set voltage
05:19 RSpliet: karolherbst, mithro: the honest answer is "we can't sort out memory reclocking until we have a PMU firmware that lets us touch stuff. This may take indefinite time"
05:19 RSpliet: as far as GM2xx is concerned
05:20 mithro: well the machine boots with that 4.4 kernel
05:20 mupuf: karolherbst: you mean they are read at the begining and then kept in memory?
05:20 mupuf: but hey, the fuses should be the same for tegra
05:21 mupuf: so, let's check them out first
05:21 karolherbst: mupuf: on tegra it works like that: at nouveau loading time, those speedo values are copied out of the tegra context and saved in memory
05:21 karolherbst: mithro: k, the try to reclock to f
05:21 karolherbst: mupuf: they do tegra_fuse_read_early(FUSE_CPU_SPEEDO_2)
05:22 karolherbst: this this is 0x100 + 0x30
05:22 karolherbst: *and
05:22 karolherbst: I think, not sure
05:22 mupuf: karolherbst: I did my PhD in a networking team. That does not mean I am good but I have some knowledge
05:23 karolherbst: mupuf: well I try to RE the wol stuff on the nforce ethernet thing I have and well there is some pattern matching going on
05:23 mupuf: well, sorry, but this is not in pfuse
05:23 mupuf: so... the offset is likely not to be the same..
05:23 karolherbst: right
05:23 karolherbst: this was my first thought too
05:23 mupuf: but hey, do they just read the value and use it directly?
05:24 karolherbst: well
05:24 mupuf: if so, we can find the difference between speedo = 1 and the actual one
05:24 karolherbst: the throw it into their volt formula
05:24 mithro: karolherbst: [ 517.578826] nouveau 0000:05:00.0: clk: failed to raise voltage: -22
05:24 mithro: [ 517.578835] nouveau 0000:05:00.0: clk: error setting pstate 2: -22
05:24 mupuf: and fish the right value out of pfuse
05:24 karolherbst: mithro: yeah, I know
05:24 karolherbst: mithro: memory is important
05:24 karolherbst: mupuf: yeah well, I thought this reg might be read only
05:25 karolherbst: so my idea was to have a list of possible regs, and modify them so nvidia sees something else
05:25 mithro: well, I get 60fps now - how goes one get glxgears to go as fast as possible?
05:25 karolherbst: vblank_mode=1 or some other number
05:25 karolherbst: I found documentation about the value ones
05:25 karolherbst: but I use 1
05:26 mupuf: vblank_mode=0
05:27 mupuf: karolherbst: you know what a fuse is, right?
05:27 mithro: 61fps
05:27 karolherbst: mupuf: yeah
05:27 mithro: so, it looks like it is _just_ keeping up
05:28 karolherbst: yeah well
05:28 karolherbst: the cores are still slow
05:29 karolherbst: the memory is now insanly fast
05:29 mithro: guess I'll see what chrome is like
05:29 mithro: karolherbst: should I try your out of tree thing?
05:29 mupuf: karolherbst: you managed to reclock memory on GM2xx?
05:29 karolherbst: yeah wait, I will patch a branch up for you
05:29 karolherbst: mupuf: no
05:29 karolherbst: mupuf: this is gk107
05:29 mupuf: ah
05:29 karolherbst: I already tried though
05:29 karolherbst: :D
05:34 mithro: Well, Chrome seems to be working okay. It's about as laggy as it was on the proprietary drivers.
05:34 karolherbst: ohh k :)
05:37 karolherbst: mithro: https://github.com/karolherbst/nouveau.git
05:37 karolherbst: mithro: branch mithro
05:37 karolherbst: cd drm
05:37 karolherbst: make
05:38 mithro: cd nouveau/drm or just cd nouveau?
05:39 mithro: Using 4.4 is nice, I no longer need to use an out of tree keyboard driver! \o/
05:39 karolherbst: nouveau/drm
05:39 karolherbst: :D
05:40 mithro: made....
05:40 karolherbst: mhh now the complicated part
05:41 karolherbst: mithro: in /lib/modules/
05:41 karolherbst: there is a folder for 4.4
05:41 karolherbst: in there is a nouveau.ko(.xz) file
05:41 karolherbst: remove that and copy the drm/nouveau/nouveau.ko file where it was
05:41 karolherbst: regenerated initramfs
05:41 karolherbst: and reboot
05:41 mithro: Okay
05:42 mithro: qq before I do that - once I have set my displays up using xrandr and everything, is there an quick way to "bake" that into an xorg.conf?
05:43 karolherbst: use your desktop environment
05:43 karolherbst: are you using kde or gnome?
05:43 karolherbst: or something else?
05:43 karolherbst: with nouveau you most likely need no xorg.conf
05:43 karolherbst: and let the desktop environment handle that stuff
05:44 mithro: karolherbst: Once I login, things seem fine - but at the lightdm stage its not really working (I have rotated monitors)
05:44 karolherbst: k, yeah makes sense
05:44 karolherbst: mhh
05:45 karolherbst: I would ask the lightdm guy if they can do something like that automatically
05:45 mithro: I can Google it, just wondering if you knew :)
05:45 karolherbst: well you could hack up a xorg.conf, but usually a user shouldn't bother with it
05:46 karolherbst: and if lightdm can't do it, it is a bug within lightdm
05:46 karolherbst: I wouldn't even consider this being a future request, it is a simple bug, that a user can't get the screen right within lightdm
05:50 mithro: rebuilding initramfs now
06:01 karolherbst: mithro: after a reboot please paste "dmesg | grep nouveau" somewhere
06:01 karolherbst: just to check if everything went alright
06:04 mithro: karolherbst: pstate parameter seems to have disappears?
06:05 karolherbst: mithro: yeah, it is in debugfs now
06:06 karolherbst: in /sys/kernel/debug/dri/0
06:08 mithro: https://www.irccloud.com/pastebin/SBqbRmFP/
06:11 mithro: karolherbst: anything interesting in there?
06:11 karolherbst: mhh the errors are a bit odd
06:11 karolherbst: did you get them with an older kernel too?
06:14 mithro: The FB_FLUSH ones?
06:14 karolherbst: yeah
06:14 mithro: I don't think so...
06:14 mithro: but not entirely sure
06:15 karolherbst: yeah well
06:15 karolherbst: as long as it runs it is fine
06:15 karolherbst: try to reclock to f then
06:17 mithro: karolherbst: appears not
06:17 mithro: (just checked the logs)
06:17 mithro: karolherbst: already did that before sending the logs
06:17 karolherbst: ahh okay
06:17 karolherbst: and how is the performance?
06:18 karolherbst: well it could be that those errors were always there but nouveau never reported them
06:18 karolherbst: in the branch is all the stuff fro 4.5 and 4.6 already
06:18 mithro: performance seems to be the same
06:19 karolherbst: yeah well glxgears doesn't use the clock that much
06:19 karolherbst: but if you cat pstate again, the core clock changed, right?
06:20 mithro: This is what I get now
06:20 mithro: https://www.irccloud.com/pastebin/Z2aU5G6Y/
06:20 karolherbst: looks good
06:20 mithro: What is DC?
06:21 karolherbst: dc as in power
06:21 karolherbst: it means you are not running on battery
06:24 mithro: karolherbst: I mean the last line in the pstate file?
06:24 karolherbst: yeah
06:25 mithro: Chrome does feel "snappier" but I don't know if that is just because it is 12:30 at night here :P
06:25 karolherbst: :D
06:25 karolherbst: as long as it is better it is good
06:25 karolherbst: I just hope I get all those changes merged for 4.7 or 4.8
06:25 mithro: karolherbst: yeah, is there a way to just make it always use pstate f from boot?
06:25 karolherbst: mhh
06:25 karolherbst: yeah
06:25 karolherbst: mithro: https://nouveau.freedesktop.org/wiki/KernelModuleParameters/
06:26 mithro: karolherbst: well, I don't know if it is better than the 4.4 version though....
06:26 karolherbst: config=NvClkMode=15 I think
06:26 mithro: yeah looks like it
06:26 karolherbst: mithro: well the cores are now clocked at 950 MHz and not 324MHz
06:26 karolherbst: but sometimes memory is just more important than clocks
06:26 karolherbst: especially with 2 4K dispalys memory is a big bottleneck
06:27 mithro: yeah
06:28 mithro: Just pushing 4k pixels is surprisingly taxing
06:28 mithro: karolherbst: How does the K1200 compare to my current graphics card?
06:29 karolherbst: hard to say
06:30 mithro: karolherbst: I've also been assuming that I can't really run multiple cards?
06:30 karolherbst: I would expect the k1200 to be a bit faster
06:30 karolherbst: maybe like 30% faster
06:30 karolherbst: but
06:30 karolherbst: mesa isn't as good optimised to maywell as kepler
06:31 karolherbst: so you might still get better performance with nouveau with your current one
06:31 karolherbst: but it should be pretty close
06:31 mithro: karolherbst: the problem is I'm adding an extra 4k pixels
06:32 mithro: This is a random question, but this feels much better than the closed source drivers
06:33 mithro: I would have expected it to be worse?
06:33 karolherbst: X integration is usually better with the open drivers
06:33 karolherbst: you will get worse perf in most benchmarks/games though
06:34 mithro: Yeah, open drivers are awesome, KMS is *sooooo* much nicer
06:34 karolherbst: and this too :)
06:38 mithro: karolherbst: I've also been assuming that with nouveau) I can't really run multiple cards to get 3 monitors (I want to be able to drag opengl windows between them, but don't care about having something cross it)?
06:39 karolherbst: mhh
06:39 karolherbst: you can actually do that with reverse prime
06:39 mithro: What is reverse prime?
06:39 karolherbst: you render one card and display on another one
06:39 karolherbst: basically
06:40 karolherbst: mithro: https://nouveau.freedesktop.org/wiki/Optimus/
06:40 karolherbst: "Using outputs on discrete GPU"
06:40 karolherbst: but
06:40 karolherbst: I haven't done this with two nouveau driver cards yet
06:40 karolherbst: but it should work
06:41 karolherbst: somehow
06:45 karolherbst: mithro: but by any chance, does your cpu have a intel gpu?
06:45 karolherbst: ohh well it would only make sense if your motherboard has a DP connector
06:47 mithro: Seems like I might be able to get the Quadro K4200 with two DP connectors and leave the K2000 for the third monitor?
06:50 mithro: The K4200 seems to have 3 times the memory bandwidth of the K2000?
06:52 karolherbst: well
06:52 karolherbst: the biggest issue here is pcie though
06:52 karolherbst: the pcie bus might be actually too slow to trasnfer a 4k display
06:53 karolherbst: it is pretty slow for fullhd stuff already
06:53 mithro: Hrm, yeah
06:56 mithro: The other option is I just bite the bullet and run my third monitor at 30fps
06:56 karolherbst: hdmi?
06:56 mithro: Yeah
06:56 karolherbst: well
06:56 karolherbst: you could put stuff on it which doesn't need 60fps
06:57 karolherbst: anyway
06:57 karolherbst: it would be awesome if you would try that out nethertheless
06:57 karolherbst: just so that we know that in theory nouveau can drive 2x 4K@60fps + 1x4K@30fps
06:58 karolherbst: ohh
06:58 karolherbst: Hz
06:58 karolherbst: but doesn't matter
06:58 mithro: pretty easy for me to try
06:58 karolherbst: hdmi 2.0 got 4K@60 right?
06:58 mithro: Yes
06:59 mithro: IIRC these monitors support 4k@60, but nothing under the sun seems to be able to produce that
06:59 mithro: http://www.techpowerup.com/gpudb/2772/nvs-810.html <- That has 8 mDP connectors!?
07:00 karolherbst: of course :)
07:00 karolherbst: sometimes you need 8
07:00 mithro: I'm pretty sure that you can't do 8x4k :P
07:00 karolherbst: maxwell has HDMI 2.0 by the way
07:00 karolherbst: ohh sure you can :p
07:00 mithro: It only has 2gb of memory onboard
07:01 karolherbst: for the raw data I think 512MB is plenty
07:02 karolherbst: 32MB could do full had already
07:02 karolherbst: you really don't need so much vram actually
07:02 karolherbst: even more
07:02 karolherbst: I think there were 32MB cards which could drive 2560x1880
07:03 mithro: Hrm, looks like you are right 3840.0 * 2160 * 4 / 1024 / 1024 == 31.64
07:03 mithro: karolherbst: connecting 3 monitor now :P
07:05 mithro: welp, it didn't seem to like that...
07:05 karolherbst: yeah, most likely the pixel clocks are wrongly configured
07:06 mithro: It doesn't seem to like the EDID very much
07:06 karolherbst: ohh
07:06 karolherbst: yeah well, this happens quite a lot for whatever reasons
07:12 mithro: well, I guess I'm rebooting now....
07:18 mithro: karolherbst: after reboot it seems to be working fine
07:18 karolherbst: mhhh
07:18 karolherbst: well that is interessting
07:19 karolherbst: so 2 displays at 4k@60 and one at 4k@30?
07:27 mithro: yes
07:29 karolherbst: k awesome
07:29 karolherbst: we still need to stablize all that at some point
07:29 karolherbst: but good to know that it works
08:47 mithro: https://www.irccloud.com/pastebin/NYZc31Lq/
08:47 mithro: karolherbst: ^
08:49 karolherbst: insane :D
08:49 karolherbst: is 30Hz good enough by the way?
08:49 mithro: karolherbst: it feels a bit "off"
08:49 karolherbst: but I would expect it to be better than unreclocked?
08:50 karolherbst: allthough reclocking while multiple displays are attached is a risk in itself
08:51 mithro: unreclocked?
08:51 karolherbst: well I meant on the lowest pstate
08:51 karolherbst: mupuf: seems like the most insane setup really works if the user is lucky :D
08:51 mithro: It was pretty unusable at the lowest pstate with just 2 monitors
08:52 karolherbst: k :)
08:53 mithro: This setup wasn't usable with the nvidia proprietary drivers (version 340)
08:54 karolherbst: :D
08:54 karolherbst: well I would expect that this works
10:09 Tom^: karolherbst: huh i was changing pstates all the time with two monitors attached
10:09 karolherbst: yeah, but it might be unstable on some systems
10:09 karolherbst: and you got some flickering
10:09 Tom^: mhm
10:30 karolherbst: those ethernet cards are so much simplier
10:30 karolherbst: only 0x1000 of address space in the mmio area
10:39 karolherbst: mupuf: yay, I got it to work :)
10:39 karolherbst: the wake on lan thing I mean
12:01 dcomp: decided to compile your branch karolherbst with the latest kernel (available on rawhide)
12:01 dcomp: nvc0_screen_create:725 - Error allocating PGRAPH context for M2MF: -16
12:01 dcomp: [ 1474.100043] nouveau 0000:07:00.0: timeout at /home/asad/code/nv/nouveau/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1352/gf100_grctx_generate()!
12:34 karolherbst: dcomp: which gpu again?
12:41 dcomp: karolherbst: 840M
12:42 karolherbst: odd
12:43 karolherbst: dcomp: which branch did you build?
12:58 dcomp: karolherbst: master
12:59 dcomp: after adding case 0x118
13:00 karolherbst: ohh okay
13:00 karolherbst: yeah something went wrong
13:01 karolherbst: dcomp: sure you put it at the right position?
13:39 freeman: Hello
13:43 buhman: hi
13:45 dcomp: karolherbst: just confirmed it was in the right position
13:47 freeman: Can someone look at this issue https://github.com/godotengine/godot/issues/4079 short conversation with developers of Godot Engine?
13:47 freeman: I would like to know if I should file a bug with nouveau or should not bother.
13:49 karolherbst: freeman: find out why it crashes
13:51 karolherbst: and this crash is an application issue
13:51 freeman: karolherbst: I was trying to, but I am rather new at that. One of Godot's devs say what you could read there.
13:51 karolherbst: yeah, but the crash is the fault of the application
13:52 karolherbst: we can't prevent applications from segfaulting
13:52 freeman: karolherbst: ok, thx I understand. I will talk to them about that.
13:52 karolherbst: it could be that context creation fails
13:52 karolherbst: but then they should check for errors
13:53 dcomp: further down ... after whilst iwlwifi is freaking out;
13:53 dcomp: [ 4797.957728] nouveau 0000:07:00.0: gr: failed to construct context
13:53 dcomp: [ 4797.957733] nouveau 0000:07:00.0: gr: init failed, -16
13:53 karolherbst: dcomp: yeah well, can you say where you added the 0x118 case?
13:53 pmoreau: I have never really played with extensions, but aren't you getting function pointers or kinda similar stuff?
13:53 karolherbst: pmoreau: yeah
13:54 karolherbst: pmoreau: I think they just call a NULL function pointer
13:54 karolherbst: if nothing changes this line crashes: https://github.com/godotengine/godot/blob/master/drivers/gles2/rasterizer_gles2.cpp#L10855
13:54 pmoreau: Could be that Nouveau advertises an extension, but fails to provide it
13:54 karolherbst: this is a 3.0 function
13:54 karolherbst: if they use 3.0, they should request 3.0
13:54 karolherbst: and check for it
13:54 karolherbst: but I think they use gles anyway
13:55 karolherbst: ohh wait
13:55 karolherbst: they don't wrap it?
13:55 dcomp: karolherbst: nouveau/nvkm/engine/device/base.c:525
13:56 karolherbst: pmoreau: do you think glGenerateMipmap is part of the ABI?
13:56 karolherbst: I think not
13:56 dcomp: and branch is master_4.5
13:57 pmoreau: glGenerateMipmap is part of GLES2
13:57 pmoreau: Which is being advertised by Nouveau
13:58 karolherbst: yeah, but is it part of the ABI or do you need to get the pointer?
13:58 karolherbst: because I think they just call the stuff
13:58 pmoreau: Probably part of the ABI
13:58 pmoreau: It doesn't look like an extension
13:58 karolherbst: still doesn't mean it is part of the ABI
13:59 pmoreau: If it's in the reference pages, it should be in the ABI, shouldn't it?
13:59 karolherbst: no
14:00 karolherbst: it was a mistake to put anything in the ABI in the first place
14:00 karolherbst: this was later somewhat fixed
14:00 karolherbst: you should get the function pointer through glx and use this
14:00 karolherbst: never call the functions directly
14:01 karolherbst: yep
14:01 karolherbst: glGenerateMipmap isn't in the ABI
14:02 imirkin: freeman: fyi, i replied with my opinion
14:02 karolherbst: imirkin: they use GLES2
14:02 karolherbst: we just discuss if glGenerateMipmap is part of the GLES2 ABI or not
14:04 imirkin: ABI? i don't think anything in GLES2 is part of the libGL.so ABI... (except things that happen to overlap with core GL)
14:04 airlied: it's why we havef libGLES :)
14:04 karolherbst: ohh wait
14:04 karolherbst: libGLESv2.so exports glGenerateMipmap
14:04 imirkin: airlied: duh, of course. i didn't get much sleep on my redeye... i blame tiredness.
14:04 karolherbst: k, then this should be fine
14:04 karolherbst: maybe the call something else
14:04 karolherbst: and the source moved
14:05 imirkin: karolherbst: also the mesa libGL/libGLES export a ton more than they ought to
14:05 karolherbst: I know
14:05 imirkin: in large part to make up for mistakes of the past
14:05 karolherbst: but they call a NULL function pointer
14:05 karolherbst: just wondering where it comes from
14:05 karolherbst: freeman: did you build the thing yourself?
14:06 karolherbst: ohh 2.0.1
14:07 karolherbst: those debug stuff
14:07 karolherbst: now I am here: "use_rgba_shadowmaps=!read_depth_supported;"
14:07 freeman: karolherbst: at fist I tried official builds but then I compiled Godot myself as well.
14:07 karolherbst: how can that even segfault
14:07 karolherbst: freeman: ahh okay
14:07 karolherbst: freeman: run it inside gdb please
14:07 karolherbst: and when it segfaults give me the output of bt
14:08 freeman: karolherbst: I did try to run it in gdb. The output is in the issue report - the link I gave.
14:08 karolherbst: I need the code of frame #1
14:08 karolherbst: what is called
14:09 freeman: karolherbst: #1 0x0000000000555efe in RasterizerGLES2::init (this=0x23e3020) at drivers/gles2/rasterizer_gles2.cpp:10855
14:09 karolherbst: yeah well
14:09 karolherbst: but what is this with your sources you have
14:10 freeman: karolherbst: what do you mean?
14:10 karolherbst: the code
14:10 karolherbst: in the file you have
14:10 karolherbst: at the line
14:10 freeman: karolherbst: ah, ok ... give me a moment... have to check.
14:10 Akien: freeman: you built the 2.0 branch I believe?
14:11 karolherbst: Akien: currently checking if it's your fault or ours :p
14:11 karolherbst: well "fault"
14:11 freeman: Akien: yes, master from github. few hours ago.
14:11 Akien: karolherbst: It's probably ours :D
14:11 karolherbst: yeah
14:11 karolherbst: maybe nouveau doesn't support something
14:11 karolherbst: but you should error check :p
14:12 Akien: But we'd welcome any help to improve it. We direly need a nice way to error out with a nice error message before segfaulting :D
14:12 karolherbst: well
14:12 karolherbst: you use gles2, right?
14:12 Akien: Just check the number of duplicates on https://github.com/godotengine/godot/issues/1162 hehe
14:12 karolherbst: usually you should get function pointers to the gl functions
14:12 karolherbst: and check if those are NULL or not
14:12 karolherbst: if for example glSomeStupidFunction is called directly
14:13 Akien: I'm not really familiar with the rendering stuff myself, but from what I understand we use gles2, and somehow I guess it gets translated to GL 2.1 compatible stuff for desktop?
14:13 karolherbst: chances are, it's _not_ int he ABI
14:13 karolherbst: and not exported
14:13 karolherbst: so the function doesn't exist
14:13 karolherbst: and you call against an invalid function reference
14:13 karolherbst: if you use some wrappers like GLEW
14:13 karolherbst: they leave those function pointers NULL if for example context creation fails
14:13 freeman: the line says glGenerateMipmap(GL_TEXTURE_2D);
14:13 karolherbst: or the extension isn't there
14:13 karolherbst: k, then it is glGenerateMipmap
14:14 karolherbst: Akien: what wrapper library are you using for the gl functions?
14:14 airlied: GLESv2 library has glGenerateMipmap here
14:14 karolherbst: yeah here too
14:14 karolherbst: ...
14:14 karolherbst: that's why I think they use a wrapper which leaves that NULL
14:15 karolherbst: freeman: can you in gdb do this when it segfaults: frame 1, x glGenerateMipmap
14:16 Akien: karolherbst: I can't tell for sure, that's a part of the engine I'm not familiar with at all; but from what I can see in the code their is (opt-out) usage of GLEW
14:16 karolherbst: k
14:16 freeman: karolherbst: Give me a moment I have to reinstall drives from propreitary and that was my final check if it's drivers thing or not.
14:16 karolherbst: freeman: well you should check against mesa, otherwise it is pointless
14:17 karolherbst: Akien: k, so most likely glew
14:17 imirkin: i can totally see mipmap generation breaking
14:17 freeman: karolherbst: well... I am a noob.
14:17 imirkin: but i can similarly see it expecting mipmap generation to work where it's not guaranteed to do so.
14:17 freeman: karolherbst: be gentile ;)
14:17 karolherbst: freeman: yeah, when running nouveau
14:18 karolherbst: start it with gdb until it crashes
14:18 karolherbst: then do this:
14:18 karolherbst: frame 1
14:18 karolherbst: x glGenerateMipmap
14:18 freeman: karolherbst: it crashes at the very start.
14:18 karolherbst: yeah, until it crashes ;)
14:19 freeman: karolherbst: ok notes taken, I have to reinstall drivers here now and then we will see.
14:22 karolherbst: ahh
14:22 karolherbst: it gets set inside _glewInit_GL_ARB_framebuffer_object
14:22 imirkin: ok, well we def don't support ARB_framebuffer_object
14:22 imirkin: and i'd be surprised if nvidia blob did... at least in a conformant fashion
14:22 karolherbst: :)
14:22 karolherbst: Akien: check if the driver supports GL_ARB_framebuffer_object
14:22 imirkin: maybe it does and just falls off the performance cliff if you do something funny
14:23 karolherbst: well they export that extension
14:24 Akien: karlmag: Based on http://feedback.wildfiregames.com/report/opengl/device/Gallium%200.4%20on%20NV46 it looks like it doesn't, though it's not for the very latest mesa
14:24 Akien: Sorry meant to ping karolherbst
14:24 imirkin: Akien: yeah, nouveau doesn't
14:24 imirkin: it actually did a long time ago, but i turned it off
14:24 imirkin: coz it couldn't support the ext fully
14:25 imirkin: EXT_framebuffer_object is supported on nouveau though
14:25 imirkin: not quite the same of course
14:29 karlmag: :-)
14:34 Akien: Thanks for the input about this Godot issue, it's very helpful. I'll make sure to hand out the logs to reduz (Godot's main dev) so that he can have a look at it and hopefully prevent those crashes.
14:37 freeman: karolherbst: ok I am back. Here is an gdb output: https://justpaste.it/sct4
14:38 karolherbst: ohhhh
14:39 karolherbst: yeah that's the mesa on alright I think
14:42 karolherbst: freeman: can you do x 'drivers/gles2/rasterizer_gles2.cpp'::glGenerateMipmap
14:42 freeman: karolherbst: in gdb running godot?
14:43 karolherbst: gdb
14:43 karolherbst: yeah
14:43 freeman: karolherbst: 0x7ffff6394f00 <glGenerateMipmapEXT>: 0xe1058b48
14:43 freeman: shoudl be 0x7ffff6394f00 <glGenerateMipmapEXT>: 0xe1058b48
14:44 freeman: hmmm there should be no 'I' before 0xe105...
14:44 karolherbst: well I will investigate this locally
14:44 karolherbst: something is odd
14:45 freeman: karolherbst: if I could help, let me know, please.
14:55 karolherbst: imirkin: it seems like ARB_framebuffer_object is exported
14:56 karolherbst: ohh on this hw
14:56 karolherbst: ahh okay
14:56 karolherbst: yep
14:56 karolherbst: when I disable ARB_framebuffer_object it crashes
15:10 pmoreau: I received my Reator like computer. Maybe I'll try to set it up during the week-end
15:11 karolherbst: :)
15:11 karolherbst: pmoreau: what gpus do you have?
15:12 pmoreau: Mostly Tesla ones, but I also have a GF100 and a GM206.
15:12 karolherbst: cool :)
15:14 karolherbst: in a few minutes I will send a rather big series to the ML, anybody want to look at it? :)
15:14 pmoreau: Definitely not tonight! :-D
15:14 karolherbst: meh :D
15:15 pmoreau: Depends what it is about as well, but maybe tomorrow or during the week-end
15:15 karolherbst: kepler reclocking
15:15 karolherbst: well
15:15 karolherbst: it also affects fermi, but that doesn't matter yet
15:15 pmoreau: Maybe I will *look* at it, but do not expect much more from me. Apart testing maybe :-)
15:16 pmoreau: Since I have a Kepler GPU at hand (in a laptop)
15:16 karolherbst: :)
15:17 jayhost`: imirkin had mimicked perl script in python to get nvadis version http://hastebin.com/vegumasudo.avrasm
15:48 karolherbst: I should document the GPU boosting stuff...
16:04 karolherbst: out :)
16:04 karolherbst: I want to speed things up a little, otherwise I won't finish it this year
16:33 pmoreau: imirkin: Is the new commit message for "[PATCH v2] nv50/ir: Check for valid insn instead of def size" better?
16:36 hakzsam: I think it is
16:37 hakzsam: pmoreau, btw, what about your fix for c++11 and this isinf() func?
16:38 hakzsam: I'm pretty sure that you have something which fixes this
16:38 hakzsam: coz you force c++11 with your spirv thing
16:38 pmoreau: I have no fix, I just added the `std::` prefix to `isinf()`.
16:39 hakzsam: maybe we should definitely fix this because nouveau+swr still fails at compilation
16:39 hakzsam: that's not a big issue though, but should be easy to fix
16:39 pmoreau: Ah, ok
16:40 pmoreau: I would go for a ifdef thing. Not sure what else could work
16:40 karolherbst: what is the issue?
16:40 hakzsam: pmoreau, ifdef for what?
16:40 hakzsam: pmoreau, for using namespace std?
16:41 pmoreau: Well, `isinf()` isn't part of std in pre C++11
16:41 hakzsam: I know
16:41 pmoreau: Oh, you would go with a `using namespace std;`? Hum… That's a bit extreme I would say, but…
16:42 hakzsam: nop, I just ask what you want to do :)
16:43 pmoreau: karolherbst: `isinf()` is part of the std namespace in C++11, but wasn't previously. So compilation of nv50_ir_ra.cpp fails if you have C++11 on
16:43 karolherbst: in which namespace was it before?
16:43 karolherbst: or just not there
16:43 hakzsam: no namespace before
16:43 karolherbst: ahh
16:43 pmoreau: hakzsam: I would have something like `#ifdef __cplusplus < 2011 if (isinf() #else if (std::isinf()) #endif`
16:43 karolherbst: isinf is new in cmath with c++11
16:43 pmoreau: global
16:44 hakzsam: pmoreau, sounds good
16:44 pmoreau: I'll write the patch and send it
16:45 hakzsam: pmoreau, please mention that this fixes compilation when swr is enabled because it forces c++11
16:46 karolherbst: mhh
16:46 karolherbst: I can hardly imagine why this should cause any compilation issues
16:46 karolherbst: the current code uses isinf?
16:46 karolherbst: isinf is part of math.h in any case
16:48 karolherbst: #include <math.h> should also be a valid fix
16:49 karolherbst: or maybe some wrapper mesa uses
16:49 pmoreau: I think I tried to include math.h, and it didn't helped
16:50 karolherbst: odd
16:51 karolherbst: I don't see why it shouldn't help
16:51 pmoreau: Yep, GCC still complains and fail
16:51 karolherbst: isinf is directly defined inside math.h
16:51 karolherbst: mhh
16:52 karolherbst: I wrote a simple c++ test
16:52 karolherbst: and it works with c++11 enabled
16:52 pmoreau: Which version of GCC?
16:52 karolherbst: 5.3
16:53 pmoreau: Cause it worked for me as well, until I used 5.3
16:53 karolherbst: try this: "#include <math.h> int main() { float f; isInf(f); }"
16:53 karolherbst: this compiles fine
16:54 karolherbst: even with #include <cmath> it works
16:55 pmoreau: Right, if I have math.h only, it works. If I add cmath, it fails
16:55 karolherbst: odd
16:55 karolherbst: ahh both?
16:55 karolherbst: odd
16:56 karolherbst: it works for me either way
16:56 pmoreau: And well, only cmath fails as well, which is expected
16:56 karolherbst: what is your non working code?
16:56 pmoreau: `#include <cmath> int main() { return static_cast<int>(isinf(30.0f)); }`
16:57 karolherbst: this works for me
16:57 karolherbst: but it even works with -std=c++98
16:57 karolherbst: and c++11
16:58 hakzsam: it fails in mesa because cmath is probably included before by swr
16:58 hakzsam: so, including math.h won't help
16:58 pmoreau: That's what I'm thinking as well
16:58 karolherbst: pmoreau: version of glibc?
16:58 pmoreau: 2.23.1
16:58 karolherbst: mhh
16:58 karolherbst: I am on 2.22
16:58 pmoreau: 2.23
16:59 karolherbst: could be an glibc issue then...
16:59 karolherbst: ohhh
16:59 pmoreau: I don't think it is a bug
16:59 karolherbst: it sure is
17:00 hakzsam: pmoreau, anyway, make use of the builtin from std is probably better than the isinf() from the glibc
17:00 karolherbst: isinf is part of the C stuff
17:00 karolherbst: why should enabling c++11 hide any C functions?
17:02 pmoreau: It is not a function, it is a macro
17:02 karolherbst: yeah okay, it is an macro
17:02 karolherbst: but why should it disappear?
17:02 pmoreau: And have a look at cmath, it undef them all
17:03 hakzsam: coz you include cmath lib from c++ first
17:03 karolherbst: not always
17:03 karolherbst: #if !_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC
17:03 karolherbst: but still
17:03 karolherbst: why does it work for me then
17:03 hakzsam: in mesa it's probably the case when swr is enabled
17:04 karolherbst: no idea then
17:04 karolherbst: it works for me for whatever reasons
17:04 karolherbst: and I would consider this a bug in any case
17:05 karolherbst: if it doesn't work with a simple g++ -std=c++11 file.cc invocation
17:08 karolherbst: k
17:08 karolherbst: for me isinf is not a macro
17:09 hakzsam: so it's glibc 2.22 related
17:09 hakzsam: this thing has changed since 2.23
17:09 karolherbst: yeah
17:10 karolherbst: I did &isinf
17:10 karolherbst: invalid conversion from ‘int (*)(double) throw ()’ to ‘int’ [-fpermissive]
17:10 karolherbst: got htis
17:10 karolherbst: &std::isinf complaints about overloads
17:10 karolherbst: source: int b = &isinf;
17:10 karolherbst: so yeah, it is no macro for me
17:11 hakzsam: that explains why it doesn't fail for you, coz it does for me with 2.23
17:11 karolherbst: or maybe some compiler options is different?
17:11 hakzsam: probably not
17:12 hakzsam: pmoreau, so yeah, it probably only fails with 2.23+ because isinf is now a macro
17:12 karolherbst: well I have also a isinf macro in math.h
17:12 pmoreau: Weird…
17:12 karolherbst: it uses some internal stuff though
17:13 karolherbst: __isinf, __isinff or __isinfl
17:13 hakzsam: pmoreau, anyway the best fix is your ifdef thing
17:13 karolherbst: something like this is always messy ...
17:15 pmoreau: hakzsam: I saw that we have similar ifdef in nv50_ir_ra.cpp, to use C++11 unordered map, and some other stuff
17:17 pmoreau: Sent
17:18 pmoreau: karolherbst: I'll make sure to at least try your serie before the end of the week-end. It looks like I had some issues changing the voltage on my GK107. (Using 4.5 though)
17:18 karolherbst: :)
17:19 karolherbst: vbios uploaded?
17:19 pmoreau: Haven't done that
17:19 karolherbst: ahh okay
17:19 hakzsam: pmoreau, I saw them too
17:19 karolherbst: hakzsam: which gpu?
17:19 pmoreau: But for now, I'm off to bed :-)
17:20 karolherbst: pmoreau: good night
17:20 pmoreau: 'Night!
17:20 hakzsam: karolherbst, that was for the c++11 stuff
17:20 karolherbst: ohh okay
17:20 pmoreau: karolherbst: I also thought he was talking about reclocking :-D
17:21 karolherbst: I really need to document the GPU Boosting thing though
17:21 karolherbst: gpuboost actually
17:21 karolherbst: and no idea what 2.0 added
17:23 karolherbst: ohh mhh k temperature stuff
17:23 karolherbst: ohhhh
17:23 karolherbst: now I know
17:23 karolherbst: k
17:24 karolherbst: they changed the max volting entries to be temperature depending and lower voltage on higher temps, which lowers clocks
17:24 karolherbst: ...