08:27mlankhorst: skeggsb: why is NOUVEAU_GETPARAM_HAS_PAGEFLIP removed from nouveau_drm.h ?
08:28mlankhorst: it will break compiling the ddx
08:29mlankhorst: and the other stuff probably breaks compiling mesa
08:37mlankhorst: hm quite some more getparams will break like that
14:09RSpliet: pmoreau: interesting how integer add has a throughput of 160
14:12RSpliet: perhaps they have 160 ALUs and 32 SFUs, both capable of doing 32-bit fp ops, but only the former implement integer arith as well?
14:30karolherbst_work: RSpliet: I worked for tesla on something like that, but it was mad related
14:32pmoreau: RSpliet: SFUs are usually for sin, cos, (popc as well IIRC). Apart from that table, I think there is another one showing to which unit the instructions match
14:32karolherbst_work: "Improved Dual Issue"
14:33karolherbst_work: mad on the SP, and another mul on the sfu
14:33karolherbst_work: just to show one example of a bit of craziness ;)
14:34karolherbst_work: it works though
14:34karolherbst_work: I've tried it
14:35karolherbst_work: I could improve performance a bit on my tesla following this rule for dual issueing
14:38karolherbst_work: I think I will send out my dual issue stuff to the ML today, I think there is no issues left, but I might have forgotten something. Anybody wants to look into it?
14:39karolherbst_work: ohh right, the complexity issue is still left
14:40karolherbst_work: then I leave out the pass and just send out the fixes for TargetNVC0::canDualIssue
14:42RSpliet: karolherbst_work: sounds like a good plan for now
14:42karolherbst_work: both fixes are rather trivial
14:43karolherbst_work: "don't dual issue instructions which depend on each other" and "also dual issue two min/max instructions"
14:44RSpliet: sounds like a solid plan
14:44RSpliet: would be interesting to see if register allocation could keep this in mind to avoid false dependency issues
14:44karolherbst_work: ahh crap, I have to write my talk thing too :D
14:44karolherbst_work: maybe I should do that first
14:45karolherbst_work: RSpliet: mhh, don't think so. I have a post-RA pass to reorder stuff
14:45karolherbst_work: so it doesn't really matter
14:46RSpliet: karolherbst_work: no I mean R3 = R1 + R2; R1 = max(R4, R5) are not truly dependent. Can you dual-issue this example?
14:47RSpliet: or do you have to use a different target register for the second instruction to clarify there's no dependency between the two insn
14:47karolherbst_work: RSpliet: you can dual issue those afaik
14:47karolherbst_work: add $r3 $r1 $r2; max $r1 $r4 $r5
14:47karolherbst_work: mhh, should work, yes
14:48karolherbst_work: I just check that the second instruction doesn'T need the result of the first one
14:48RSpliet: does that guarantee that add fetches R1 before max writes to it?
14:49RSpliet: OoO processors would use register renaming to optimise this case, not entirely sure what the GPU pipeline requires in such cases :-)
14:50karolherbst_work: both instructions are pushed into the same issue slot afaik
14:50karolherbst_work: you can have actually more instructions issued, than the total issue slots amount
14:52RSpliet: what is the concept of an instruction slot?
14:52karolherbst_work: no idea
14:52karolherbst_work: it is just the names from the perf counters
14:52RSpliet: then I don't know what your claim means in practice :-P
14:52karolherbst_work: me neither
14:53karolherbst_work: well I was able to imrpove performance of pixmark_piano by ~5% through dual issue improvements
14:53karolherbst_work: I think dual issued instructions are issued at the same time
14:54karolherbst_work: and that inputs are resolved earlier than the results are written
14:54RSpliet: karolherbst_work: yes, presumably it works similar to an OoO core. But for reasons of pipelining there might be a fifo before each functional unit
14:55karolherbst_work: might be
14:55RSpliet: and under circumstances, the second of the dual-issued instruction might then actually not be executed in parallel with the first
14:55pmoreau: RSpliet: What fetching are you talking about in this case?
14:56karolherbst_work: one radeon guy told me once, that on older radeon chips, you were able to do a swap like this: mov $r1 $r2; mov $r2 $r1 by "dual issueing" both instructions at the same time
14:56karolherbst_work: RSpliet: yeah, if you tell the hardware do dual issue instructions, which can't be dual issued, you get a perf hit and the worst schedulable throughput
14:57RSpliet: pmoreau: I'd like to understand the concept of "dual issue" from an architectural pov, so that we can validate the dual issue constraints for common sense
14:57RSpliet: karolherbst_work: ah, so hardware does validation of this decision? interesting...
14:57karolherbst_work: RSpliet: don't forget, that on kepler we have to tell the hardware what can be dual issued
14:57karolherbst_work: it also affects the perf_counters
14:57karolherbst_work: inst_issued1 and inst_issued2
14:58karolherbst_work: if you just dual issue everything, those numbers still tell you the real deal
14:58RSpliet: karolherbst_work: yeah that makes sense
15:00pmoreau: RSpliet: Hum, I think I got what you meant: even though the load has been executed before, since it is non-blocking, the instruction won’t be executed until the data has been made available. But since the max insn doesn’t care about the value, it could be emitted while hte add is held until the data is available
15:00RSpliet: pmoreau: that roughly sounds like what I'm trying to say yes
15:01karolherbst_work: pmoreau: makes sense
15:01karolherbst_work: "issued" != executed
15:03RSpliet: karolherbst_work: correct! Imagine the pathological case (that doesn't talk about register dependencies) where, iirc on Kepler each SM has 4 warp schedulers, and 6 32-bit wide units capable of MAD. If you try and issue 8 MADs in one clock cycle (two for each warp), there should either be a stalling+priority mechanism, or a fifo in front of each 32-bit wide unit. Either way we can't assume there's a "fixed" delay between issue and retire
15:03RSpliet: or even issue and register fetch :-)
15:04karolherbst_work: thing is, the first intruction of a pair is dual issued
15:04karolherbst_work: the second gets the normal scheduling information
15:04RSpliet: so that's why I'm curious whether we should help the warp (dual-)issue logic by avoiding false sharing through clever register allocation
15:05karolherbst_work: I doubt it matters
15:05RSpliet: I think we need the insights of an NVIDIA engineer to be certain here :-P
15:06karolherbst_work: anyhow, we have to push instructions between source and def anyway
15:06karolherbst_work: so the issue will be resolved with proper scheduling anyway
15:07karolherbst_work: if you look at nvidia generated binaries, you see that nvidia tries really hard to push many instructions in between
15:07RSpliet: not sure what strategy would be more effective/cheaper to do
15:07karolherbst_work: sometimes even 20+
15:07RSpliet: perhaps a combination of both
15:07karolherbst_work: well, you have to reduce max gpr count somehow too
15:07karolherbst_work: or keep it in check at least
15:09pmoreau: The average latency between two instructions is about 20 cycles IIRC
15:09karolherbst_work: yeah, that would fit what I noticed
15:12pmoreau: (Time to go home and finish rebasing my clover patches…)
15:35ahmed751995: excuse me , does prime with nouveau switch between two card automatic or i have to type DRI_PRIME=1 "app" ?
15:39karolherbst_work: ahmed751995: you have to do that either manual or you could add application entries within .drirc
15:43ahmed751995: karolherbst_work: thanks alot
17:13ttr_ppix: can anyone shed light on "failed to idle channel" error messages? i lose control over mouse/keyboard/screen when attempting to play Steam games and that message is displayed
17:28urjaman:resists printing some out and using a flashlight on them ...
17:39ttr_ppix: i've tried several mesa/kernel combinations on my GK104 using mesa versions 11.2.0 and 12.1~git1608100730.3f100b, and kernel versions 4.4.0-34, mainline 4.6.5, mainline 4.7 and mainline 4.8-rc1, received crashed on all of them
17:40ttr_ppix: i would be happy to supply logs/crash reports/etc if that would be helpful
17:56pmoreau: ttr_ppix: Could you link one of the dmesg with that error message please?
18:06ttr_ppix: pmoreau, sorry for the noob question, but how can I grab a dmesg log from a previous session?
18:06pmoreau: Oh, that you can’t :-D
18:06pmoreau: But /var/log/messages or journalctl should have the same info
18:07pmoreau: (more or less)
18:16ttr_ppix: pmoreau, thanks for the tip, it looks like /var/log/kern.log will probably have the crash details, i'll head over here and post it when I get home
21:36Sophira: Hiya. :)
21:37Sophira: Just so my understanding is correct, am I right in believing based on the feature matrix at https://nouveau.freedesktop.org/wiki/FeatureMatrix/ that the NV124 chipset isn't supported yet?
21:38Sophira: (GTX970, etc)
21:38Sophira: (Not asking so I can complain about it! I'm just asking to make sure my understanding is correct.)
21:46Calinou: Sophira: Maxwell is in the works
21:46Calinou: there is almost no Pascal support right now
21:46Calinou: (3D acceleration is barely there)
21:53Sophira: Calinou: Thanks. Is there anything I can do to help?
21:53Sophira: (I've seen the FAQ, but most of the things there seem beyond me. I'm a coder but know nothing about graphics.)
21:53Calinou: well, use Nouveau and report bugs
21:54Calinou: hacking on Nouveau itself requires C but also assembly knowledge (IIRC)
21:54Sophira: I've coded in x86 before, but not much in amd64.
21:55Calinou: isn't x86 and x64 assembly pretty much the same thing?
21:56Sophira: (I'm running the Nouveau modesetting driver already, but Nouveau's X module doesn't load so I'm not sure how I would be able to test for bugs.
21:56Sophira: There are some definite gotchas you have to be aware about in my experience.
21:57Sophira: It's not as easy as you might think.
21:58karolherbst: assembly? where
21:58Calinou: karolherbst: I frequently see you talk about assembly
21:58Calinou: like, for optimization stuff
21:58karolherbst: gpu assembly
21:59karolherbst: but you also don't write assembly anyway
21:59karolherbst: just normal compiler development
22:01Sophira:has not yet written a real compiler. She wants to at some point.
22:02karolherbst: me neither
22:02karolherbst: I even didn't code C before working on nouveau, too
22:03Calinou:never did any real C/C++ projects
22:06Sophira: I only really started learning C maybe two years ago or so. Since then I have been able to write code that I've found useful; a Windows tool to dump memory, for example.
22:08karolherbst: well, I don't hink, that you really need to know much C to be able to develop anything for a kernel, because you usually have to follow different rules than writing userspace applications anyway
22:09karolherbst: one thing is, that you don't want null pointer derefernces in the kernel :D
22:10Sophira: (I do have a tiny patch in the kernel, actually. It's just a modification of a #define that suited my hardware at the time, but I'm still proud of it.)
22:10karolherbst: if you want to help out with the nouveau projects, there are a few task one could do to get into reverse engineering or compiler development quite easily
22:11Sophira: I do like reverse engineering, but typically I've done that by looking at binaries. Obviously that's not something that would work here.
22:11karolherbst: but it helps to work on an issue you have yourself ;) it can be trivial as it can gets. even stuff like "fan is faster compared to nvidia"
22:12karolherbst: it even leads to legal issues usually
22:12karolherbst: disassembling isn't legal in most countries, which is a big problem
22:12karolherbst: but it doesn't matter
22:13Calinou: relevant: https://github.com/rwengine/openrw
22:13karolherbst: black box REing is more fun anyway
22:13Calinou: GTA 3 on Linux :D
22:14karolherbst: the normal user would just use wine, but the bored one just reimplements the entire engine :D
22:14Sophira: "just" ;p
22:15Calinou: karolherbst: also open source
22:16Calinou: so, open source GTA 3 :p
22:16karolherbst: yeah well, that goes without saying usually
22:16karolherbst: are there any game engine reimplementations which are closed?
22:16Calinou: not that I know of
22:16Calinou: there are proprietary source ports (Doom, Duke Nukem 3D)
22:16Calinou: but no reimplementations that I know of
22:17Calinou: (btw there's also a reimplementation of GoldSrc out there)
22:18karolherbst: Sophira: well, if you have any problems with your gpu running nouveau, somebody here will gladly help out tracking down the issue or help with fixing stuff, but I think most of us are actually living in europe somewhere, so timing might be a problem
22:19karolherbst: in fact the 970 GTX should have quite advanced opengl support already, with 4.3 being worked on I think, or 4.1
22:20karolherbst: just reclocking won't work on those for really stupid reasons
22:20karolherbst: not our fault (tm) actually
22:20Sophira: I live in the UK myself. (I'm connected to IRC through my server in the US.)
22:21Sophira: I'm running kernel version 4.4.6. The previous kernel version I was using (4.1.12) had some sort of issue where I'd see a purple link down the left side of the screen.
22:21Sophira: A kernel update fixed that though. :)
22:22karolherbst: mhh, 4.4 is quite bad for maxwell2 as well I think
22:22Sophira: ^purple line
22:22karolherbst: let me check
22:22Sophira: (Thank you.)
22:23karolherbst: do you have opengl working on yours? I highly doubt it, but I rather ask
22:24Sophira: Like I said, the nouveau X driver doesn't even load since I use a GTX 970. It falls back to fbdev.
22:24karolherbst: with maxwell you will always get the modesetting ddx
22:24Sophira: I can pastebin the Xorg.0.log file if you want.
22:24karolherbst: with glamor...
22:24karolherbst: which won't work without opengl
22:24karolherbst: I think you need actually 4.6 + linux-firmware
22:25karolherbst: starting with maxwell2, the gpu requires firmware signed by nvidia otherwise we can't get hw acceleration
22:25urmet: ooh. I tried my 840M over some time. looks like it defaults to not-snail-speed now :)
22:26karolherbst: silly situation, but nothing we can do about
22:26urmet: and no compiling drivers from dev repos
22:26Sophira: (I'm using Gentoo and that kernel version branch still has a ~ keyword, indicating it's still in testing. I can override that though.)
22:26karolherbst: well, it is a gm108
22:27karolherbst: Sophira: mhh, honestly, just accept ~amd64 :p
22:27karolherbst: I do the same
22:27karolherbst: (but I also have USE=-* set for extra fun)
22:27urmet: Sophira: you want fancy graphics on a desktop. ~amd64 ftw
22:28karolherbst: you also need quite a more modern mesa
22:28karolherbst: like mesa-9999
22:28karolherbst: you have 11.0.6 right?
22:28Sophira: That just takes directly from git, doesn't it?
22:28Sophira: Yep, I have 11.0.6.
22:28karolherbst: won't be usefull with your gpu
22:28karolherbst: I think you need at least 11.2
22:29urmet: tip - if you start using git ebuilds, then install smart-live-rebuild too
22:29Sophira: Sounds like a number of people here use Gentoo ;p
22:29karolherbst: and the other half uses arch I think .D
22:31karolherbst: anyway, it is highly recommended to use an updated graphic stack with maxwell2 gpus, otherwise you will run into issues, we have already fixed
22:33Sophira: I added "media-libs/mesa ~amd64" and "=sys-kernel/gentoo-sources-4.6.5 ~amd64" to my /etc/portage/package.accept_keywords . Still not sure I want to go directly from git yet, but it sounds like these should be good enough. (And I already had "=x11-drivers/xf86-video-nouveau-1.0.12 ~amd64" in there.)
22:34urmet: xf86 driver is useless
22:34Sophira: Hmm. Okay.
22:34Sophira: How so?
22:35Sophira: (I mean, these are xorg drivers, I promise, not XFree86.)
22:35urmet: it uses modesetting xorg driver
22:35urmet: <karolherbst> with maxwell you will always get the modesetting ddx
22:36Tom^: karolherbst: still running dri3 ? because i sort of found a issue
22:36Sophira: Okay. What else should I do to be useful, then? Manually grab the git and recompile?
22:36karolherbst: Sophira: libdrm too
22:36Tom^: karolherbst: X completly locksup after a day or so, no errors or anything when i ssh in so uh yea :p
22:36Sophira: karolherbst: Yep, emerge told me that I'd need that.
22:37karolherbst: Tom^: always dri3
22:37karolherbst: what issues?
22:37Tom^: karolherbst: modesetting?
22:37karolherbst: I use an intel ddx
22:37Tom^: karolherbst: ah
22:37Tom^: oh right you are on one of those optimus laptops hehe
22:38urmet: hmm. what's the status on pascal?
22:38karolherbst: gp100 has support somewhat
22:38karolherbst: even opengl
22:41urmet: 1070 is gp104, this is covered too?
22:41loa: hello! what i can do if reclocking of my 660gtx gk106 is not stable?
22:41loa: is see artifacts and sometimes lockups.
22:41karolherbst: loa: compile nouveau from my branch
22:42karolherbst: or wait until 4.9 or 4.10
22:42karolherbst: or annoy skeggsb until he merges my stuff :p
22:42loa: i love speed with which you unswered. :D
22:42loa: thought here will be complete dead channel)
22:42loa: it will hard to merge by myself?
22:42loa: will be *
22:43loa: silent *
22:43karolherbst: this channel ain't dead :p
22:43loa: where i can find this branch? on kernel org?
22:43karolherbst: loa: well, you can build nouveau out of tree and use that
22:43loa: i am not into git so much.
22:44karolherbst: loa: https://github.com/karolherbst/nouveau
22:44karolherbst: branch: stable_reclocking_kepler_v5
22:44karolherbst: or stable_reclocking_kepler_v5_4.6
22:44karolherbst: depending on your kernel
22:44karolherbst: the former is for 4.7
22:44loa: former? can you rephrase?
22:46urmet: I wish I wasn't 300km away from my desktop right now. I could be compiling new kernels to try getting my pascal card to work :(
22:46karolherbst: urmet: yeah, because you bought that card for their fb functioanlities
22:47loa: you can this remote, no?)
22:47urmet: karolherbst: of course :D
22:47urmet: some functionality is way more than no functionality
22:48loa: How good nouveau support good with compositing? I have problem with propritary drivers that when i do compositing i have very low speed in different fullscreen games.
22:49loa: I have two monitors in twinview now. Things getting worse when i have vdpau enabled application on another monitor (I always have stream there, like twitch)
22:50urmet: loa: i could maybe remote in if i could find out how to change efi boot order from windows.
22:51urmet: ah, no
22:51urmet: not efi boot order, grub boot order
22:51urmet: probably way harder
22:54loa: karolherbst, i disabled nouveau module in my kernel, will this be enough?
23:00Sophira: I'm lost in make oldconfig. Send halp.
23:01loa: what is envyas? what do this thing?
23:01loa: i have error when i try compile nouveau
23:03karolherbst: Sophira: too many new things?
23:04Sophira: karolherbst: At the time I said that I was trying to work out what the heck NET_DEVLINK was for. "Network physical/parent device Netlink interface provides infrastructure to support access to physical chip-wide config and monitoring."
23:04Sophira: In the end I just said N.
23:04Sophira: Still have no clue what it's for.
23:06karolherbst: if you have no clue, the default is usually safe
23:06urmet: network configuration tools speakt to the kernel over netlink i think
23:07Sophira: Well, the default was N, so...
23:07karolherbst: I also have it set to N
23:07Sophira: (and I configure my network by editing /etc/conf.d/net, anyway)
23:08urmet: okay. i have it on M and it's not loaded - useless
23:09urmet: netlink and devlink are too similar looking words
23:09Sophira: loa: I can't help with your question, unfortunately. I'm new to all this myself.
23:09loa: karolherbst, what is wrong? http://pastebin.com/c1k8Pvek why it don't poroduce any modules?
23:10loa: or errors at least)
23:12karolherbst: you need nouveau set to M
23:13Sophira: (Ooo, a new kernel question regarding a piece of hardware I actually own! I feel special.)
23:16loa: karolherbst, i hope there will not be any problems that i run make from root folder of nouveau?
23:17loa: and it stops with error about envyas
23:19karolherbst: you need to compile within drm
23:21loa: i did this already.
23:21loa: and installed module.
23:21loa: will give a try)
23:21karolherbst: you also have to regenerate initramfs
23:22karolherbst: and make sure you use the right branch of my repository
23:22karolherbst: and make sure the kernel nouveau module won't be loaded instead
23:22Tom^: well that depends if he is loading nouveau in initramfs
23:22loa: karolherbst, i installed it over it, as i got.
23:22loa: i did make install
23:23loa: but i don't think i used right branch
23:23loa: just cloned you repository.
23:23loa: how i can switch to that branch?
23:24loa: i will try find this by my own.
23:26urmet: If you want to try out experimental software you will need to learn git sooner or later anyways :)
23:26loa: yeah, you are right.
23:36karolherbst: well, I am like super tired and head to bed now. If you still need something, bother me tomorrow with it :p
23:43loa: karlmag, i got system freeze when i tried open my hardware accelerated chromium.
23:43loa: it is ok?
23:43loa: i can live without it i think.
23:43loa: mouse was working, but could not change ttys or something.
23:52loa: looks like it is better with compositing then nvidia.
23:54loa: now it plays well, maybe compiz works better.
23:57loa: hmm, strange. what is wrong with copositing, and hardware accelarated video decoding?