03:21karolherbst: can't this be optimized somehow? https://gist.github.com/karolherbst/2c7ab3d082244a36430a
03:22karolherbst: maybe into this? 63: set ftz u8 $p0 lt f32 0x3d23d709 $r66 (8)
04:01karolherbst: what about stuff like this? https://gist.github.com/karolherbst/5bb1c748d7a1f2c12d00
04:06RSpliet: karolherbst: for NV50 I don't think that's possible at least
04:06karolherbst: mhh the latter one?
04:07karolherbst: currently checking if the blob does that
04:07RSpliet: one of the source operands (the first iirc) must be a register
04:07karolherbst: c and value might not work
04:07karolherbst: ohh I see
04:07RSpliet: might be different for Fermi/Kepler though!
04:08karolherbst: but its a register there "set ftz u8 $p0 lt f32 0x3d23d709 $r66"
04:08karolherbst: the last one
04:08RSpliet: as far as the first one goes, not sure if set has an immediate format at all, check the decompiler for the most up-to-date specifications
04:08karolherbst: see a lot of stuff like that "set ftz $p0 0x1 lt f32 $r43 0x3f000000" int eh blob output
04:08karolherbst: maybe the last one has to be the immediate
04:09karolherbst: yeah, seems like its always the last
04:09karolherbst: then its even simplier
04:09RSpliet: possibly you might get away with flipping the test to "ge" if that's possible
04:10karolherbst: the latter optimization might be "more" general
04:10karolherbst: its strange that there is a fixed one in between
04:10RSpliet: I don't know what you mean with that statement
04:11karolherbst: there is a joinat between the instructions
04:13RSpliet: I can't tell you much about that, sorry
04:13karolherbst: seems not that important though, because the set depends on that mov directly
04:14RSpliet: but if that means it's a branch end-point, then you should be careful that the particular register isn't set to a different value in a different codepath
04:17karolherbst: the reg isn't used before the joinat and directly after the joinat is the set
04:17karolherbst: so even if it would be overwritten in another branch, the set could be eliminated
04:17karolherbst: *the mov
04:19karolherbst: RSpliet: but what do you think about this? https://gist.github.com/karolherbst/5bb1c748d7a1f2c12d00
04:19karolherbst: this would save one reg at no cost?
04:20karolherbst: mhh, but I think there has to be a reg source :/
05:00RSpliet: karolherbst: movs are cheap, too
05:01RSpliet: I can't tell what the pipeline looks like, but probably no more than 3 cycles
05:02karolherbst: I know, but I was thinking that reduce the amount of regs used is generally a good idea
05:02karolherbst: especially if you only have 62 of them
05:02RSpliet: mmm yes
05:04karolherbst: also there is another thing I found. the blob seems to never dual issue the last istruction of a "instruction block"
05:05karolherbst: at least if I don't dual issue the last one, there is no performance change
09:47pmoreau: RSpliet: I am available this week-end for some distant RE'ing/testing on the G96 if you have time. :-)
10:01ebrasca: how to make work GM107 [GeForce GTX 750 Ti] ?
10:01pmoreau: You need a recent kernel at least
10:02pmoreau: 4.1 will give you acceleration on GM107.
10:05ebrasca: pmoreau: i have 4.1.6 but it start with intel
10:06pmoreau: Optimus laptop? Could you paste your dmesg please?
10:09ebrasca: pmoreau: here https://dpaste.de/VUWC
10:12pmoreau: ebrasca: You should have a look at DRI_PRIME in http://nouveau.freedesktop.org/wiki/Optimus/
10:14ebrasca: pmoreau: ne-pc% xrandr --listproviders
10:14ebrasca: Providers: number : 1
10:14ebrasca: Provider 0: id: 0x45 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 3 associated providers: 0 name:Intel
10:14ebrasca: pmoreau: why don't give some nouveau out?
10:15pmoreau: I don't know...
10:15marcosps1: imirkin: around?
10:16pmoreau: ebrasca: One thought would have been that Nouveau auto-suspended and went to sleep, but can't see anything implying that in the dmesg.
10:17pmoreau: ebrasca: Could you paste your Xorg.0.log as well please?
10:21ebrasca: pmoreau: here https://dpaste.de/Pvsu
10:23pmoreau: Hum... No mention of Nouveau.
10:27pmoreau: ebrasca: Do you have xf86-nouveau or xf86-modesetting installed? (or similarly named packages)
10:27ebrasca: pmoreau: xf86-video-nouveau ?
10:29ebrasca: pmoreau: i don't know why but now give me to
10:29ebrasca: Provider 1: id: 0x57 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 4 associated providers: 1 name:nouveau
10:30pmoreau: Eh?! Well...
10:30pmoreau: By just waiting and without installing anything?
10:31ebrasca: pmoreau: i have make nothing pc go off
10:32pmoreau: You can have a try at DRI_PRIME now then
10:34ebrasca: pmoreau: command not found: glxinfo
10:34pmoreau: You need package mesa-demos
10:44ebrasca: pmoreau: reboot and test
10:53ebrasca: I broke something again.Thx for help
12:24shining: I have a "new" card, GF119 [GeForce GT 610], no reclocking for these ?
12:25mupuf: shining: well, you can always test it
12:25shining: I can read /sys/class/drm/card0/device/pstate and see two modes, but I cannot change it
12:25mupuf: what does it say?
12:25shining: echo: write error: Function not implemented
12:25shining: echo 0f > /sys/class/drm/card0/device/pstate
12:30shining: well 2d support is good, and it's a fanless card so perfect for working. I was just curious to see if teeworlds was running, it does but it's a bit slow. and there is a good difference between the two modes
12:30shining: 07: core 270 MHz memory 405 MHz / 0f: core 810 MHz memory 600 MHz
12:59karolherbst: I don't think reclocking works for fermi in general
12:59karolherbst: I have the same issue on my fermi card here
12:59karolherbst: I planned to look into this after finishing other stuff first
13:01Yoshimo: which would be?
13:02imirkin: karolherbst: most instructions can only take an immediate in the second source
13:02karolherbst: pcie and kepler/gddr5 stuff
13:02karolherbst: imirkin: yeah I know, but I have a blob mmt trace here for some programs
13:04karolherbst: imirkin: but I think this one is valid: https://gist.github.com/karolherbst/2c7ab3d082244a36430a
13:04karolherbst: I see a lot of "set ftz $p0 0x1 lt f32 $r43 0x3fc00000" in the mmt
13:18shining: karolherbst: but on http://nouveau.freedesktop.org/wiki/PowerManagement/ engine recloking is marked as mostly for nvc0, just like nv50 and nv30, where it seemed to work. though memory reclocking is only marked as wip.
13:20karolherbst: shining: I don't know the exact state of fermi there
13:21karolherbst: afaik kepler is more mature there
13:23ebrasca: now work my nouveau but work evil
13:26pmoreau: ebrasca: How evil is it working?
13:26shining: well if someone knows better what's the current state and if anything can be tested, let me know. see ya
13:27ebrasca: pmoreau: letters disappear
13:27pmoreau: I think there is an open bug report about it, let me find it
13:28pmoreau: ebrasca: https://bugs.freedesktop.org/show_bug.cgi?id=90932
13:30ebrasca: x11 break
13:31pmoreau: Doesn't seem to be really stable :/
13:31ebrasca: pmoreau: how i can fix it?
13:32pmoreau: The crash or the disappearing letters?
13:32ebrasca: pmoreau: both
13:33pmoreau: Well, tbh I don't know for both cases.
13:33pmoreau: You could follow the bug report I linked, so you'll know if a fix is found for the letters.
13:34pmoreau: As for X, if you could paste the Xorg.log from the crash session, maybe there'll be some helpful information in it.
13:34ebrasca: pmoreau: Sori i have lost link because x11 break
13:35pmoreau: Here it is again: https://bugs.freedesktop.org/show_bug.cgi?id=90932
13:56karolherbst: anybody have any idea if the X server shall load the modesetting driver for any new GPU, even if the gpu is set to dummy through xorg.conf?
14:06airlied: karolherbst: xorg.conf should override all
14:07karolherbst: I see
14:07karolherbst: airlied: I have this nasty bug though: https://bugs.freedesktop.org/show_bug.cgi?id=91388
14:08karolherbst: basically xorg-server loads the modesetting driver whenever I power on the gpu and load nvidia/nouveau afterwards
14:08karolherbst: while X is running
14:08karolherbst: only for nouveau, X crashes/restarts
14:10airlied: karolherbst: Option "AutoAddGPU" "FALSE"
14:11karolherbst: have that already
14:11karolherbst: airlied: that's my config: https://gist.github.com/karolherbst/640ae2b42f2ba19911c8
14:12karolherbst: airlied: it works though when nvidia/nouveau was loaded before X was started
14:12karolherbst: modesetting is only loaded when the nouveau/nvidia is loaded after X started
14:12airlied: those logs seem to suggest the opposite, though I've just woken up
14:12karolherbst: so as a workaround I just load nvidia and restart X
14:13karolherbst: then I can unload/load nouveau as I see fit
14:13airlied: maybe AutoAddGPU needs mor ework
14:13karolherbst: airlied: the second log has no modesetting driver load and the module was loaded before
14:14airlied: oh actually should probably extend autoAddGPU to turn off hotplug
14:15karolherbst: or is there aothe option?
14:15karolherbst: I am using the dummy driver, because I have a full DRI3 setup, so that I can remove the nouveau kernel module ;)
14:16airlied: karolherbst: http://paste.fedoraproject.org/266569/92546144/
14:16karolherbst: DRI2 seems to work worse here, so I don't care that much :D
14:16airlied: should fix it
14:16karolherbst: okay, will try that out later, thanks
14:27pmoreau: \o/ I managed to get a binary out of my nouveau_codegen_spirv!
14:27pmoreau: Well, it does nothing interesting and is weights only 8 bytes, but still, I'm happy! :D
14:33RSpliet:gives pmoreau a high five
14:33pmoreau: RSpliet: ;-)
14:34pmoreau: pmoreau: Did you see my message for the G96 btw?
14:34pmoreau: RSpliet: ^
14:34pmoreau: (Getting late...)
14:34RSpliet: yes, but I doubt I'll have time this weekend though, sorry
14:34pmoreau: Ok, no problem