03:33imirkin: librin: i put a patch for civ6 - let me know if that lets you run shaders with optimizations (and without artifacts)
03:33imirkin: i'm not 100% sure that my patch is correct
03:33imirkin: this stuff is subtle :(
03:44nyef: Optimizing compilers are subtle, and quick to anger?
03:48imirkin: yes, much like wizards
03:49nyef: Clearly, then, optimizing compiler wizards are even worse. (-:
03:51imirkin: the worst!
04:01librin: imirkin: good morning, I'm going to test in a bit
06:06librin: imirkin: testing that patch wasn't easy for a few reasons
06:06librin: but it still fails, just in a different spot now
06:07librin: gonna post info on the report Real Soon Now™
06:16librin: imirkin: and done
10:16kattana_: does nouveau play nice with efifb?
10:16kattana_: how can I have initramfs pre-nouveau boot console?
10:17karolherbst: kattana_: it should work
10:18karolherbst: but efifb got screwed over in recent kernel versions
10:18kattana_: wait, yes or no? 4.9 here.
10:18karolherbst: if it doesn't work, it's not nouveaus fault
10:18kattana_: is the switch to nouveaufb automagic or does it require some special hacks+
10:19karolherbst: there was some rework for those fb drivers (vesa, efifb, simplefb....) and with certain configs, you broke those
10:19kattana_: karolherbst: but does nouveau take over regardless of efifb's shape?
10:19kattana_: karolherbst: I think I need efifb, because I am booting off efi.
10:20karolherbst: you don't need efifb, but it helps if nouveau messes up
10:20karolherbst: having no efifb just means, that you have no display until nouveau gets loaded
10:21kattana_: karolherbst: exactly, I want pre-nouveau display, and the efi boot I think it needs its own.
10:22karolherbst: yeah, you would need efifb in this case
10:22kattana_: thanks, I'll try how it goes.
10:22karolherbst: efifb is a pretty solid fb by the way, it's no low res crap like the older fbs were
10:25kattana_: karolherbst: last question, can I set efifb as built-in and nouveau as module?
10:25mwk: don't confuse high-res with solid :)
10:27kattana_: mwk: well, I just need efifb to print text, I am not expecting to run voxel-based 3D gaming at 4k.
10:27kattana_: I am happy with 1080p 32bit color.
10:28pq: kattana_, yes, that is what he meant.
10:28karolherbst: mwk: it's solid, I can run plasma5 on top of efifb :p
10:28karolherbst: that's solid enough for an unaccelerated fb
10:29pq: I would say that stresses the fb driver much at all
10:29pq: *would not
10:29karolherbst: well kwin uses GL 3.x
10:29pq: and fb has nothing to do with that at all
10:29karolherbst: but I think it falls back to xrender when on efifb
10:30pq: that also has nothing to cause work for an fb driver
10:30karolherbst: cause it is all done in software then
10:30karolherbst: I guess
10:31karolherbst: can we do prime offloading onto efifb?
10:31pq: if you actually switched video modes or something, that would stress the fb driver. But fb drivers don't tend to support that nowadays.
10:31karolherbst: I see
10:31pq: karolherbst, you've never heard how an fb drivers works, have you?
10:31karolherbst: not really
10:32pq: It sets up one framebuffer, allows the user space to map it, and that's it.
10:32karolherbst: isn't it just like a big buffer in some kind of ram, sys ram in case of efifb?
10:33kattana_: bad news :( --> "if the EFI firmware can't support your preferred resolution, efifb also can't use it"
10:33pq: kattana_, yes, that's the point of efifb: to use what the EFI firmware offers, nothing more.
10:34kattana_: wow, so even if I get a 4k display i'll get a shitty 800x600 boot display??
10:34kattana_: something's wrong with technology.
10:34pq: karolherbst, there is no buffer allocations going on, no page flipping (unless the initial buffer is actually bigger than the resolution and you switch the scanout offset), they usually don't support changing video modes at all, probably no hotplug, multi-head is limited to crappy clone mode, etc.
10:35kattana_: lazy ass programmers not to add option for higher res to the UEFI firmware.
10:35pq: karolherbst, so once the fb driver has started, practically the only thing it does anymore is allow userspace to map a fixed buffer that can never be even moved.
10:36karolherbst: pq: okay, but we could put the offloaded stuff into that buffer, even if we miss all the synchronisation and everything in theory
10:37karolherbst: kattana_: maybe you can change the resolution inside your uefi menu
10:37karolherbst: some uefi firmwares are not as bad as others, and some can be even called "not terrible"
10:40pq: karolherbst, I suppose, assuming you can direct the something to draw into it. But I'm not sure efifb actually implies sysram, it might be VRAM too. But, it definitely is mappable to CPU access, even if terribly slow.
10:40karolherbst: well, as long as we can keep up 60 fps @ fullHD, it's not too slow :D
10:41pq: I wouldn't know if you can
10:41karolherbst: why not?
10:41karolherbst: my desktop on top of efifb is pretty smooth
10:41pq: because it depends on the gfx hw, the cpu and motherboard hw, and the firmware?
10:41karolherbst: not saying that it is for _all_ firmwares
10:42karolherbst: well, some systems are more shitty than others, nothing new
10:42pq: I wasn't aware we were talking about your system specifically
10:43pq: let's just say I'm very pessimistic about all firmware :-P
10:43pq: that said, I think EFI interface offered some ways to change the video mode, maybe optionally...?
10:44pq: or maybe not, I forget. It's been more than a year since I set up my only EFI system.
10:44pq: actually it was rEFInd where I has to mess with modes
10:45pq: *had to
10:46kattana_: karolherbst: are running X only with efifb??
10:46pq: I would not be at all surprised if EFI had a video mode interface but efifb did not expose it. After all, efifb is only the bridge on the way to loading a proper driver.
10:48karolherbst: kattana_: your entire desktop should run on efifb
10:48karolherbst: pq: well sure, but it's better to debug a broken system with fullHD than with 800x600
10:48pq: karolherbst, you mean "with any kind of display", sure :-)
10:49karolherbst: no, I mean an efifb, which could only do 800x600 for silly reasons, is something silly, because efi can do more
10:49karolherbst: like using the reasoning "efifb is just a bridge to proper fb, that's why we only support crappy resolutions" is silly
10:50pq: I think you missed something: efifb is just to keep the same mode the firmware or the bootloader already set up, I believe
10:51karolherbst: yeah, I think it does exactly this
10:52karolherbst: I just meant, that only because it is a bridge, is not a valid reason to say "we won't implement this"
10:53karolherbst: because some of those features might make sense even in a fallback driver
10:53karolherbst: saying the feature is useless is fine
10:53pq: firmware can set modes, bootloader can set modes, efifb???, the proper driver can set modes - you'd really need a fourth one?
10:54karolherbst: it was meant more generally
10:54pq: missed we changed subject
10:55karolherbst: I mean sure, changing the resolution in efifb might make sense, if the bootloader messed up and the firmware defaults to something silly, but then we could fix the bootloader instead or so
10:55pq: this is all just speculation anyway, I don't *know* it doesn't support it
10:55karolherbst: but I think it can't
10:55karolherbst: at least I couldn't through xrandr
10:56karolherbst: or maybe I never checked
10:56karolherbst: but I think I remember that I could only keep the current one
10:56pq: but given that any kind of video programming through fbdev is pain from the medieval ages, and most important kernel devs just hate the guts of it, it should be pretty safe assumption.
10:57pq: for non-DRM drivers
10:57pq: and also for fbdev emulation on DRM drivers
10:59pq: the fbdev API is the fundamental culprit
11:00karolherbst: I see
11:05pq: The tendency for the last... half a decade? has been to deprecate fbdev and support only the bare minimum on it for bootsplash etc. until handover to a DRM driver.
11:05pq: and doing the bare minimum, e.g. not doing any mode sets, also helps on boot times
11:07pq: I haven't followed too closely but there has been development for simple fb-hw DRM drivers, which would make the fb drivers redundant while offering a usable user ABI.
11:48kattana_: just rebooted int efifb+nouveau, really no benefit, the efifb boot display is very short, then still turns black when the switch to nouveau happens
11:49kattana_: I doubt it has to do with nouveau being module as it's in the initramfs.
11:50kattana_: and the efifb is low res, therefore a smooth seamlees continuous boot is not possible.
12:11librin: kattana_: what's Your bootloader?
12:23kattana_: librin: efi
12:39karolherbst: kattana_: the point is though, that you have a display. Like you could blacklist nouveau and boot into the system
12:43kattana_: karolherbst: no really a benefit if I'll have a low res display. oh well, trade offs
12:43karolherbst: well, better than a black screen I suppose
12:43karolherbst: efifb is a fallback fb.
12:44karolherbst: pq: do you think nouveau could unregister it's fb so that the kernel drops again to efifb to display errors?
12:50librin: kattana_: booting directly from efi? No wonder You've got a low-res fb
13:35gnurou: GP10x firmware and its suppotr *finally* available!
13:36gnurou: https://github.com/Gnurou/nouveau/tree/secboot for driver code and https://github.com/Gnurou/linux-firmware/tree/staging for firmware files
13:36gnurou: (I know, 53 patches - sorry about that)
13:37gnurou: skeggsb: I need to check for bisect break and maybe fix a few more things, but I hope you will be able to pull it into drm-next? wanted to give you a preview before sending the series formally
13:37gnurou: well if can work off github this may be just as good, I don't want to flood the list
13:38gnurou: the set of features is still disappointing (nothing beyond GR init), but at least GR should now be up
13:38gnurou: skeggsb: mmm even if you review on Github I should at least send a cover letter to explain the sequence of patches... will do that tomorrow morning first thing
14:03pmoreau: gnurou: Yeah! \o/
14:03pmoreau: Which firmware are we taking about BTW? Only gr, or is there some PMU lurking behind it as well? :-)
14:04pmoreau: Oh wait, I missed some of your messages. So no PMU for now
14:04pq: karolherbst, I doubt it'd work, but I don't know. I believe it's a one-way street: once you hand over from EFI firmware to OS drivers (nouveau), the firmware is out until next reboot. That's my assumption.
14:06pq: karolherbst, certainly I would not trust the firmware, even if it could execute, to be able to unwedge the nvidia chip enough to scanout again in case of a crash.
14:06pq: karolherbst, not without a reboot
14:06karolherbst: librin: I boot directly from efi and I always got full display res, it's just the firmware being crappy most of the time
14:07karolherbst: pq: I mean in case where nouveau fails to initiliaze the display and we would end up with a black screen
14:08pq: karolherbst, oh, I would know even less about that case.
14:09karolherbst: gnurou: three different ACR versions :D... seriously though
14:11whompy: just curious, what other firmware is needed for full capability? Just PMU?
14:17gnurou: karolherbst: five, actually - if you could the two that are already merged
14:17karolherbst: I meant three new ones
14:18gnurou: but of the 3 new, 2 are not actively used and are submitted to illustrate the mess that this is and why we will need these abstractions
14:18gnurou: ... and also preventely in case we release firmware from these versions
14:18karolherbst: fair point
14:18gnurou: I won't mind if they are not merged, as long as the interface remains as-is :)
14:18karolherbst: I don't mind as well
14:18gnurou: karolherbst: have also a look at the different msgqueues interfaces...
14:19karolherbst: having support more versions might come in handy
14:19gnurou: ... and also the fact that on GP10x the ACR load must run on SEC but ACR unload on PMU...
14:19karolherbst: at least there _is_ a SEC falcon
14:20karolherbst: I couldn't care less about unloading, but at least the PMU isn't occupied doing secboot stuff
14:20gnurou: I promise, I did my best to get things straighter, but this (firmware) is an area where I cannot even build the code
14:20gnurou: no, in GP10x case the PMU is completely free, everything happens on SEC
14:20gnurou: of course, if we had PM support, the PMU would have stuff to do, but that's the world we currently live in
14:20karolherbst: we can't reclock those pascals anyway :D
14:21karolherbst: this will be tons of work
14:21karolherbst: and super messy
14:21karolherbst: and suppy shitty
14:21karolherbst: and not because everything is like different than to fermi+
14:21karolherbst: but because we can't really RE that shit
14:22gnurou: well you can watch what happens on the CPU side at least, and which commands are sent to the PMU
14:22gnurou: but without the proper FW, it is difficult to emulate it :/
14:22karolherbst: how much can you tell about how somebody could get a modded vbios loaded for a maxwell2+ gpu?
14:22karolherbst: best if this doesn't involve flashing
14:22karolherbst: but if flashing is the only way, we buy like 10 super cheap maxwells2 and break them :p
14:22gnurou: I am not aware of any way to do that
14:23karolherbst: gnurou: not even with manufacturer tools or stuff like this?
14:23gnurou: vbios is not an area I am looking at closely, being mainly a Tegra guy
14:23karolherbst: I am aware
14:23gnurou: well if you have debug boards and the like, I would bet you can do something, but these are obviously not available
14:23karolherbst: changing the vbios is like super critical
14:24karolherbst: we were just lucky with maxwell, that not much changed
14:24karolherbst: but with pascal it's a totally different story
14:24gnurou: I think your best shot is to get proper documentation from NVIDIA
14:24gnarface:cries a little bit about h264 decoding on G92
14:24gnurou: but we know how well this has been going so far
14:24karolherbst: if we get some, then please not bs docs like this vpstate doc
14:24gnurou: this one was embarrassing
14:24karolherbst: this is like super.... you know. useless
14:25gnurou: sad thing is, the people who produced it were certain it would help a great deal >_<
14:25gnurou: that's how aware NVIDIA is of Nouveau's status
14:25karolherbst: maybe I should fix it and send a proper version of the vpstate thing :D
14:26karolherbst: because we REed that table by ~95% by now
14:26karolherbst: only one header byte is missing and unimportant part of the entries, which are set to 0x0 for like 95% of all gpus
14:27gnurou: there will be a window of opportunity to get information, and this will be XDC which takes place at Google
14:27gnurou: veeeery close from NVIDIA's offices
14:27karolherbst: in the US I suppose?
14:27karolherbst: I am sure I won't go to the US anymore
14:27karolherbst: at least not now
14:28gnurou: if you guys can prepare a list of things you want to discuss, and sync properly with e.g. Andy, you can probably get good results
14:28karolherbst: and for sure not if there is a chance they want my passwords for social media sites
14:28gnurou: as long as they don't ask for your nickserv password... :P
14:29karolherbst: you know and suddenly IRC is "social networking stuff"
14:29gnurou: it certainly qualifies
14:30karolherbst: or maybe I will come, but I really have no nerv for all this kind of bs just to travel somewhere, seriously
14:30pmoreau: gnurou: Are you planning on going to XDC? :-)
14:30gnurou: pmoreau: I hope to be there this time, yeah
14:30pmoreau: That would be nice!
14:32gnurou: pmoreau: if my employer lets me travel, and the immigration services don't lock me up for not having a Facebook account
14:32pmoreau: Neither do I have a Facebook account…
14:33gnurou: we should write a Facebook bot that performs random activity on FB so we have a plausible account to show
14:33pmoreau: Maybe I could give them the password from my old, and now deleted, account?
14:33karolherbst: I used my account like two years ago the last time....
14:33pmoreau: Everytime you push a commit, it creates an entry? :-D
14:33karolherbst: ohh wait
14:34karolherbst: change your password to : "1h3_u5_b0rd3r_c0ntr01_5uckz"
14:34pmoreau: Ah ah
14:34gnurou: anyway, gonna catch some Zs, plenty of stuff to do tomorrow!
14:35pmoreau: gnurou: ’Night!
14:35karolherbst: gnurou: nighty
14:35gnurou: see you tomorrow for more exciting firmware adventures! </sarcasm>
15:23Tom^: no sane person uses or have a facebook
17:28mart193: echo echo
17:31kim0: Howdy folks .. Is there any way to use the NVENC encoder chip through the nouveau driver (without the crazy stupid limitations nvidia added like the limit of 2 encode sessions per all cards!!) ?
17:34mlankhorst: kim0: well if you're willing to write it ;)
17:34kim0: sigh :) I wish I could honestly
17:35kim0: I had some hopes see'ing https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/nouveau/nvkm/engine/nvenc
17:35kim0: Although the link seems empty indeed :)
17:37imirkin_: kim0: not currently.
17:38kim0: imirkin_: Thanks for letting me know
17:39kim0: If anyone knows any way around their crippling of perfectly fine hardware .. let me know (or twitter @ak_kim0 )
19:38AeroNotix: so mesa-17 is available for my distro now. I'm using kernel 4.10, I've echo'd into pstate some options for my gfx card but still getting terrible performance on games and with benchmarking tools. What else can I try?
19:38imirkin_: that's it.
19:38AeroNotix: so nouveau is just that bad?
19:39imirkin_: you should be getting about 60-80% of blob perf
19:39AeroNotix: On a benchmarking tool I get 30%.
19:39imirkin_: if you're not, chances are there's something wrong with your config
19:39imirkin_: mmm... that seems low.
19:39AeroNotix: What config? I've just installed nouveau, use DRI_PRIME, echo'd pstate to a higher option.
19:39imirkin_: did it succeed? pastebin the contents of the pstate file
19:40imirkin_: if your gpu suspends again, i think your setting gets lost
19:40AeroNotix: I'm no longer on that kernel but it had the asterisk next to the option I set
19:40AeroNotix: I set the option while the game was running
19:40imirkin_: don't read the asterisk
19:40imirkin_: read the AC line
19:40AeroNotix: still, I set the option while the game/benchmark was running. Don't think the card went to sleep then
19:41imirkin_: anyways, i guess the answer then is "yes, nouveau is that bad"
19:41imirkin_: amazing what documentation and manpower can do.
19:41AeroNotix: What do you mean?
19:41imirkin_: (nouveau has neither)
19:42AeroNotix: Well what are the alternatives? Nouveau is the only option for open source nvidia drivers afaict
19:42imirkin_: there are hundreds of full time engineers working on the nvidia drivers
19:42AeroNotix: Not for the linux ones
19:42imirkin_: it's a shared core
19:43AeroNotix: so with glmark2 I'm getting 3000+ fps with intel, but ~800-1200fps with nouveau
19:48AeroNotix: so trying nvidia one more time....
22:50karolherbst: hihi: https://googleprojectzero.blogspot.de/2017/02/attacking-windows-nvidia-driver.html
22:52imirkin_: see above :p
22:52karolherbst: you already posted it
22:52imirkin_: AeroNotix: note that hitting crazy FPS, you tend to be doing more a measurement of bus bandwidth than gpu performance.
22:53karolherbst: or CPU
22:54karolherbst: imirkin_: ohh and he has a prime setup
22:54AeroNotix: imirkin_: Games still are crap
22:54karolherbst: AeroNotix: you have to set the pstate after the gpu suspended again
22:54AeroNotix: karolherbst: I've tried pretty much all setups with this chip. Everything works like shit
22:54AeroNotix: karolherbst: I set the pstate while the game was running.
22:54imirkin_: AeroNotix: that may well be, but don't look at the diff between 1000fps on a remote gpu and 3000fps on a local gpu.
22:55karolherbst: AeroNotix: which game runs like shit?
22:55AeroNotix: karolherbst: Shadow Tactics
22:55AeroNotix: imirkin_: I'm just using it as a sort of smoke test
22:55imirkin_: i understand - it's just not testing what you think it is.
22:56imirkin_: you think it's testing gpu perf. it's actually testing pcie bus bandwidth.
22:56AeroNotix: karolherbst: there's a demo for free fwiw
22:56karolherbst: testing then
22:57karolherbst: also maxwell is pretty much unpotimized for now
22:57karolherbst: allthough it is better with mesa-17
22:57AeroNotix: I have mesa17
22:57karolherbst: yeah well "better"
22:57karolherbst: it's still bad
22:58AeroNotix: karolherbst: for someone uninitiated. Does nouveau's codebase deal with optimization/performance?
22:58imirkin_: that's ... an odd question
22:59AeroNotix: why is it? Some schmuck on reddit is telling me that nouveau has nothing to do with graphics performance
22:59AeroNotix: and that the performance comes directly from signed drivers nvidia passes down
23:00karolherbst: nouveau has a compiler which does optimizations
23:00karolherbst: nouveau doesn't replace game shaders by handly written ones, which nvidia tends to do on windows (no idea about linux)
23:01karolherbst: AeroNotix: but you can believe that most written about nouveau is bs most of the time especially on reddit
23:01karolherbst: most nouveau devs lack time, so we can't spend like a lot of time on optimizing the driver
23:02karolherbst: if something works without crashes and we get near 80% perf compared to nvidia, we are happy already
23:02karolherbst: and we lack the documentation
23:04karolherbst: but everybody is free to spend some time to improve the compiler we have or do figure out why certain games run bad or so
23:04AeroNotix: I'm a dev myself but graphics has always been a black box. There's so many libraries and platform abstractions and it moves incredibly quickly. One day this package is what people use, then next another.
23:04karolherbst: yeah, but it ain't this way for gl
23:04karolherbst: because you usually only check what the hardware does
23:04AeroNotix: "everyone is free to ..." - yes if you have the time to understand wtf you need to do to improve a graphics driver.
23:05karolherbst: most of the nouveau devs do all the work in their spare time
23:06AeroNotix: for sure, but drivers like this aren't something where you can just stick the code up on github and have "drive by" submissions. Even just getting a simple commit merged requires a lot of background knowledge and potentially week's worth of work
23:06karolherbst: uhm... no
23:06AeroNotix: I'm not saying you guys do shit. I'm saying I totally understand why you don't have more help
23:06karolherbst: before I wrote my first patch, I didn't even wrote C
23:07karolherbst: and had no clue how GPUs work
23:07AeroNotix: What was your first patch?
23:07karolherbst: fixiing gddr5 reclocking on kepler
23:08karolherbst: you just need to be motiviated enough to actually fix issues and learn everything on the way
23:08AeroNotix: as a minimum. Nvidia comes out with a new gpu tomorrow. How much work is involved to make it work with nouveau
23:08karolherbst: could be a month
23:08karolherbst: could be a week
23:08karolherbst: could be half a year
23:09karolherbst: it mainly depends on how much the architecture differes
23:09karolherbst: for example: reclocking is the same for kepler and maxwell GPUs, with only a handful not important changes
23:09karolherbst: so we can just reuse the entire reclocking code for maxwell we had for kepler
23:09karolherbst: sometimes the display engine is so different, we can't just reuse the display code
23:09karolherbst: and then it takes a while
23:10AeroNotix: and reclocking is where I, as a user, echo $shit > pstate?
23:10karolherbst: allthough I already have some WIP patches to make that automatic and so
23:10AeroNotix: should I make a bug if a pstate option makes my system unstable?
23:10karolherbst: needs cleaning, polishing and fixes for new issues
23:11AeroNotix: I have three options when I cat the pstate file, when I use the highest one, my system freezes quite often
23:11karolherbst: AeroNotix: yes
23:11karolherbst: AeroNotix: are you on 4.10?
23:11AeroNotix: karolherbst: not at this second, but I was when I was testing the reclocking
23:11karolherbst: I see
23:12karolherbst: would need a bit of time of figuring out exactly what goes wrong, but yeah, we would try to fix it
23:13AeroNotix: cool, bit late for me right now but definitely tomorrow I will look into it more and get the reproduction steps.
23:13karolherbst: if you create the bug, it would be already helpful to get the entire output of dmesg after the crash/freeze
23:13karolherbst: and your vbios.rom file
23:13karolherbst: it's located in /sys/kernel/debug/dri/1/vbios.rom most likely
23:14karolherbst: the number may differ
23:14karolherbst: mupuf: pls.. "@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @" ;)
23:15AeroNotix: karolherbst: will do!
23:16karolherbst: mupuf: and you even overwrote one of my commits :O
23:16karolherbst: three actually
23:17karolherbst: or did something happen
23:18mupuf: karolherbst: hey
23:18mupuf: the HDD died
23:18mupuf: I just pushed what I had
23:18mupuf: feel free to push --force
23:19karolherbst: I rebased
23:20karolherbst: AeroNotix: so I guess you didn't compared 0f pstate nouveau vs nvidia?
23:20karolherbst: mupuf: I see
23:22AeroNotix: karolherbst: no, just with nouveau
23:22AeroNotix: and I didn't get nvidia working
23:22AeroNotix: at lal
23:22karolherbst: AeroNotix: so stock clocks?
23:23AeroNotix: karolherbst: what do you mean? I tried with the higest clock setting available on nouveau in the pstate file
23:23karolherbst: shadow tactits has really high requiernments as it seems
23:24karolherbst: or well
23:24karolherbst: medi high
23:24karolherbst: well, let me test a bit
23:25karolherbst: a crash... very nice
23:26karolherbst: and no crash when running outside steam
23:27karolherbst: AeroNotix: where did you had the perf issues=
23:30AeroNotix: karolherbst: just running a level on the lowest settings
23:30AeroNotix: very choppy, will not run unless everything is turned down
23:31karolherbst: I get 30 fps on max settings under nouveau
23:33karolherbst: AeroNotix: the game uses 350% CPU though
23:33AeroNotix: Which chip do you have?
23:33AeroNotix: DRI_PRIME=1 glxinfo | grep "OpenGL renderer string"
23:33AeroNotix: OpenGL renderer string: Gallium 0.4 on NV117
23:34karolherbst: AeroNotix: you know which model?
23:34karolherbst: gm107 ain't that bad
23:34AeroNotix: GM107M [GeForce GTX 850M]
23:34karolherbst: it's like roughly 30% slower than mine
23:35karolherbst: AeroNotix: what cpu do you have?
23:35karolherbst: okay, so the 2nd haswell
23:36karolherbst: I have a i7-4700MQ
23:36karolherbst: AeroNotix: can you launch the game with DRI_PRIME=1 GALLIUM_HUD=fps from cli?
23:37karolherbst: AeroNotix: but I noticed that I get only ~45 fps on low settings
23:37AeroNotix: ok let me try that
23:37karolherbst: so changing the settings doesn't do very much
23:37AeroNotix: will need to reboot into 4.10
23:37karolherbst: AeroNotix: well on 4.10 and max clock
23:37karolherbst: otherwise it's useless :D
23:38karolherbst: looks like a fun game though
23:38karolherbst: thanks for the pointer at least :D
23:40sinatosk: Hi, my laptop has a Quadro K4000M. NVE0 family, code name NVE4 (GK104). Using multi-screen setup I have an DP to HDMI adapter which is connected to a HDMI display ( GPU port is DP ). If I turn the display off and back on again, the screen gets no signal but when I switch to any random TTY and back to the original TTY or I put my laptop to sleep and then wake , the HDMI display turns on. This happens with mesa 13.0.4, 17.0.0 with X server 1.19.1,
23:40sinatosk: using kernel 4.9.10 but happended with 4.9.9 too and there are no errors or warnings from dmesg or X server
23:41karolherbst: AeroNotix: I get ~45 fps on nvidia on highest settings
23:41karolherbst: so nouveau is at aroun 66% speed
23:42karolherbst: on kepler
23:42karolherbst: no clue about maxwell
23:46AeroNotix: give me a sec, DRI_PRIME isn't kicking in for some reason now. Let me look into that
23:49karolherbst: anyway, gotta sleep