00:31 imirkin: pendingchaos: hm, interesting. perhaps that's a legit (minor) gallium api change then.
03:45 ReinUsesLisp: I'm playing around with half floats, (afaik) this table defines how to unpack the register. F32 -> read it as a float32, H0_H0 -> take the lower half-float, H1_H1 -> high half-float. Question is: what does the None flag do?
03:45 ReinUsesLisp: https://github.com/envytools/envytools/blob/1934618b979b6eb3af28380db3b1745eb50e746d/envydis/gm107.c#L1120
03:52 imirkin: H0_H1, presumably
03:52 imirkin: i.e. "the thing you expect from a half-float operation"
03:53 HdkR: ^
03:53 imirkin: it's SIMD-style
03:53 imirkin: so x = HADD(a, b) is 2x half-float add ops
03:53 imirkin: each value stores 2 half floats
03:54 imirkin: except as flags indicate otherwise, e.g. if you do like HADD(a, b.F32), then it uses the value of b for both "sub-lanes" interpreted as an F32
03:54 ReinUsesLisp: something like:
03:54 ReinUsesLisp: f16vec2 result = fp16vec2(a) * fp16vec2(b)
03:54 ReinUsesLisp: ?
03:54 imirkin: yes.
03:55 imirkin: H0_H0 = a.xx, F32 = float(a), etc
03:55 imirkin: er, float(a) is a bit off
03:55 imirkin: but takes a longer example to illustrate
03:55 imirkin: i.e. where "a" is a plain float.
03:56 ReinUsesLisp: it'd mean that the value was already a float
03:56 ReinUsesLisp: ok
03:56 imirkin: and is used for both "lanes" of the other op
03:56 imirkin: of course presumably you could do HMUL(a.F32, b.F32)
03:56 imirkin: which would have the same value in both lanes of the result
03:57 imirkin: [why you'd do that is a separate question of course]
03:57 ReinUsesLisp: yes, that's what the blob emits for an attribute -> varying mul
03:57 ReinUsesLisp: at least with NV_gpu_shader5
03:57 imirkin: i guess it's faster than FMUL + CVT
03:58 imirkin: interpolated attributes are always f32
03:58 ReinUsesLisp: that'd do, thanks
03:58 HdkR: Nobody likes cvt :P
03:59 ReinUsesLisp: btw is this a corrupted output or just weird?
03:59 ReinUsesLisp: TEXS.F16.NODEP.INVALIDPHASE3 R1, R2, R15, R14, 0xa, 2D, RGBA
04:00 HdkR: :D
04:00 imirkin: not sure. could be a decoder error
04:01 imirkin: the registers seem fine... presumably with F16 it packs the outputs into R1 for rg and R2 for ba
04:01 imirkin: with regular TEXS, it'd pack them into consecutive regs, which wouldn't work here (they'd overlap)
04:03 imirkin: there are also a bunch of V* opcodes which perform SIMD-style ops on packed 8- or 16-bit integer values
04:04 imirkin: nominally the "video" opcode set
04:04 imirkin: but i don't think you'd get into trouble if you used them for other purposes
04:04 imirkin: they enable byte/word addressing of 32-bit regs, some amount of swizzling
04:12 HdkR: ReinUsesLisp: How did you manage to get an invalid phase encoding?
04:13 ReinUsesLisp: a game emitted this: 0xd03200a010e70f02
04:14 HdkR: Fun
04:15 ReinUsesLisp: it's a game that's already on PC, it's interesting that it's using half floats for Switch
04:15 HdkR: Free double throughput if you can afford it
04:22 imirkin: how does nouveau decode it? nothing good i imagine ...
04:22 imirkin: (wtf is phase?)
04:22 HdkR: Set phase to stun
04:23 imirkin: yeah, i was trying to work phaser into it somehow
04:24 imirkin: nothing good came up
04:24 imirkin: but it's past midnight...
04:24 HdkR: That's all I had
04:25 imirkin: :)
04:25 ReinUsesLisp: an empty output
04:25 imirkin: hehe
04:26 HdkR: Obviously nouveau needs to try harder at supporting half floats
04:26 imirkin: 00000000: 10e70f02 d03200a0 ??? [unknown: 10e70f02 d03200a0] [unknown instruction]
04:27 imirkin: HdkR: hey! i added all the H* stuff to envydis...
04:27 HdkR: half way there then :)
04:27 imirkin: no pun intended, i'm sure.
04:27 imirkin: or ... half intended?
04:27 HdkR: Hard to care about it when there wasn't a geforce card with it I guess
04:28 imirkin: hard to care when it's not supported by kepler
04:28 HdkR: Had to go Tegra or Quadro before Turing arrived
04:28 HdkR: :P
04:28 imirkin: past that, no firmware
04:28 imirkin: no firmware = hard to care
04:29 HdkR: yeah
04:58 rhyskidd: valgrind 3.14 is packaged and will be released tonight
04:58 rhyskidd: i've started the effort to forward port mmt to valgrind 3.14
04:58 rhyskidd: see here: https://github.com/envytools/valgrind/issues/6
04:59 rhyskidd: ^ mslusarz,imirkin,karolherbst,skeggsb
04:59 rhyskidd: preliminary WIP branch is compiling and appears to pass the tests
06:26 ping: hi
06:27 ping: is there a way to get nvidia 970 working nice with this driver?
06:27 ping: I mean with reclocking stuff
06:33 pmoreau: ping: Hello, if the card is in a laptop, there might be a way, otherwise no as Nouveau doesn’t have dynamic reclocking and cannot change the fan speed (which is set to low by default).
06:36 ping: pmoreau: but the problem is the fan speed or the GPU clock
06:39 pmoreau: IIRC, on Maxwell GM20x (most of the 900-series), this is due to not being able to change the fan speed but the GPU clock can be changed. On later cards, the GPU clock can no longer be changed without the needed firmwares.
06:42 ping: but, what if I had the GPU with an independen watercooling wich I can manage it with a physical control?
06:44 pmoreau: There was a discussion in the past of having a kernel option for Nouveau to enable reclocking on those cards, mainly for laptop users as the fans are not controlled by the GPU anyway. This could also apply to you, but I don’t think such a patch has been merged in yet.
06:44 pmoreau: karolherbst: ^
06:48 ping: I don't why nvidia insn't involved a little more in this project
06:48 ping: like AMD with the FOSS drivers
06:50 chithead: nvidia has its own foss driver, nvgpu https://www.phoronix.com/scan.php?page=news_item&px=Nouveau-XDC2017
06:51 pmoreau: But only for Tegra IIRC, I doubt it works with desktop GPUs.
06:52 pmoreau: Anyway, gtg. ping: karolherbst should be able to help you more, as he has worked a lot on reclocking and was the one behind the kernel option for allowing 900-series reclocking IIRC.
06:52 ping: oh nice ! :)
06:55 ping: My mistake was trust in nvidia only because when I buyed this PC 4 years ago I wanted a good gamming support for windows
06:55 Sarayan: hmmm, the firmware blobs are just copied to video ram, there are no sepcial registers?
10:08 RSpliet: pmoreau: I don't think we're capable of uploading SEQ scripts for memory reclocking either, are we?
10:45 karolherbst: RSpliet: on maxwell we are
10:46 karolherbst: it is really just controlling the fan
12:59 orbea: Uhh, kmscube is supposed to show a cube, right? Shows a bunch of lines instead, but I'm not sure how to trace it or take scrots...
13:00 orbea: llvmpipe ofc doesn't work either...
13:18 karolherbst: orbea: maybe a mesa regression?
13:20 orbea: i guess I can try older commits later
13:20 karolherbst: yeah, and if an older works, please bisect ;)
13:21 orbea: nod. :)
18:34 endrift: I'm speculating about something and I'm curious if Maxwell code would run on Pascal
18:34 endrift: and if so how compatible it'd be
18:35 HdkR: Partially compatible
18:36 karolherbst: like 99.9%
18:36 karolherbst: there are some additions
18:36 karolherbst: like sqrt only exists on maxwell2+
18:37 karolherbst: HdkR: I think we have like 2 or 3 differences documented inside envydis
18:37 karolherbst: allthough mhh, SM60 adds quite a bunch of stuff
18:37 karolherbst: but
18:38 karolherbst: running maxwell code on pascal should work for nearly all cases afaik
18:38 karolherbst: there is that 0x3e special reg which got a different meaning in pascal
18:38 karolherbst: ctxaddr -> barrieralloc
18:38 endrift: I'm mostly asking because I'm speculating about the T214
18:38 endrift: aka Mariko
18:39 endrift: wondering if there's any chance it's running a newer chipset
18:39 endrift: or possibly a die shrink
18:39 karolherbst: who knows
18:39 HdkR: Pascal changes some of the scheduling around some FP64 ops as well
18:39 karolherbst: HdkR: question is if you are fine with the maxwell scheds
18:40 karolherbst: HdkR: but... that's fixable
18:40 karolherbst: you could just patch binaries
18:40 HdkR: Sure, patch them to drains and not worry about the overhead
18:40 HdkR: It's already FP64 :P
18:40 karolherbst: :p
18:40 karolherbst: exactly
18:41 endrift: problem as I understand it is that the NVN API is linked into each binary, not a shared library
18:41 karolherbst: but I mean, you could fix up the incompatible stuff before uploading it. Normally you know what memory is shader code at some point
18:41 endrift: so you'd need to override that somehow
18:41 karolherbst: endrift: okay, but that's nothing we know about here
18:41 endrift: sure
18:42 endrift: I'm just thinking about how Nintendo would go about it
18:42 karolherbst: all I can say is, that the ISA is very compatible and fixing it up would be quite easy
18:42 endrift: nod
18:42 karolherbst: if you make the situation harder for you, that's your fault then :p
18:42 endrift: I don't work for Nintendo, I'm just speculating :P
18:42 karolherbst: sure
18:43 HdkR: Don't speculate too hard, might get hit by a spectre attack
18:44 karolherbst: always
18:44 endrift:baps HdkR
18:44 karolherbst: would be too late for that anyway :D
18:44 endrift: oh no your cache is leaking....
18:45 karolherbst: bummer
18:45 karolherbst: doesn't matter anyway
18:45 endrift: karolherbst: have you seen errors about an Nvidia card falling off the bus when trying to modprobe the blob?
18:45 karolherbst: okay sure, your CPU is owned, but most of the network hardware is already owned anyway....
18:45 HdkR: lol
18:45 karolherbst: endrift: plenty, I have many ways of crashing nvidia
18:46 endrift: I've been trying to figure out what's been going on there
18:46 endrift: working with bumblebee sucks
18:46 endrift: I added your power/config stuff to bumblebee's systemd unit
18:46 endrift: and now sometimes I stop being able to modprobe nvidia
18:46 karolherbst: nvidia handles one state correctly: if nothing touched the GPU since powering on
18:46 karolherbst: everything else is luck
18:46 endrift: sigh
18:47 karolherbst: mhhh
18:47 endrift: oh well, I can always reboot if I need to
18:47 karolherbst: might be that you should poweron the device manually
18:47 endrift: how do I do that?
18:47 karolherbst: write on instead of auto
18:47 endrift: I tried writing "on" to that file inst--
18:47 endrift: yeah that didn't help
18:47 karolherbst: mhh, weird
18:47 karolherbst: works for me
18:48 endrift: oh well
18:48 karolherbst: but then again, nvidia never tested this scenario
18:48 karolherbst: I also have some scripts to invoke the ACPI stuff directly
18:48 karolherbst: but that's basically the same thing
18:48 karolherbst: ohhh
18:48 endrift: meanwhile I had to hit the nvidia 410 package with a rock to get it to install on my 18.10 desktop
18:48 endrift: heh
18:48 karolherbst: but uhm.. no, wouldn't change anything
18:48 karolherbst: or maybe?
18:48 karolherbst: endrift: you could try to remove the device and rescan the bus
18:48 endrift: how do I do that?
18:48 karolherbst: I mean, remove it via sysfs
18:49 karolherbst: echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
18:49 HdkR: endrift: I'm still trying to figure out why the blob freaks out when my PC sleeps and wakes back up D:
18:49 karolherbst: echo 1 > /sys/bus/pci/rescan
18:49 endrift: and how do I rescan?
18:49 endrift: ah
18:49 endrift: cool thanks
18:49 karolherbst: HdkR: because nvidia is broken :p
18:49 karolherbst: and the firmware too
18:49 karolherbst: and the vbios
18:50 HdkR: I could see that
18:50 karolherbst: HdkR: also, there were some wirdo bug fixes
18:50 karolherbst: let me get the latest one
18:50 endrift: HdkR: I'm having fun with my RTX card on my desktop
18:50 endrift: I might try OCing it using Nvidia Scan or whatever it's called too :D
18:50 karolherbst: HdkR: https://bugzilla.kernel.org/show_bug.cgi?id=201069
18:51 endrift: too bad I didn't get the Ti version, MayImilae showed me some benchmarks
18:51 endrift: but: $400
18:51 karolherbst: HdkR: a fix is upstream inside 4.19
18:51 HdkR: endrift: OC scanner got the 2080ti to something like +200 and then the memory just works at +1000 :P
18:51 endrift: some of which I spent on FFXV
18:51 endrift: is that an official thing in GeForce Experience or whatever or do I need to download e.g. MSI Afterburner?
18:51 HdkR: karolherbst: Interesting. Wonder if it is related to what I'm having on my TR system though
18:52 HdkR: endrift: MSI afterburner or EVGA's precision thing
18:52 endrift: I have an old version of afterburner so I'll try that
18:52 endrift: oh hey the bus thing is happening right now
18:52 endrift: let me try that
18:54 endrift: that "worked"
18:54 endrift: but now I can't modprobe -r it
18:54 endrift: it keeps reinserting itself
18:55 endrift: ...and modprobe -r'ing itself too
18:56 endrift: I blame udev
19:00 HdkR: ...yep
19:00 endrift: confirmed: it's udev's fault
19:13 karolherbst: HdkR: try the patch :p
19:13 karolherbst: endrift: :D
19:13 karolherbst: I have all nvidia modules and nouveau blacklisted
19:13 karolherbst: no funny business on my system
19:13 endrift: I ended up tweaking some udev rules and reloading udev
19:13 endrift: and it stopped
19:18 HdkR: karolherbst: You said it was upstream now?
19:18 karolherbst: yeah in 4.19 afaik
19:20 HdkR: I'll just pull latest kernel source and rebuild it then :P
19:20 HdkR: rc7 or w/e
19:21 HdkR: I still don't have a consistent way to repro though. Usually have to fault the GPU first and then /maybe/ it'll not come back after sleeping
19:22 karolherbst: interesting
19:22 karolherbst: might be a different issue then
19:22 karolherbst: but all that suspend/resume stuff is more or less broken anyway
19:23 HdkR: I may just have to eat the idle power consumption cost
19:24 karolherbst: or just fix it :p
19:24 karolherbst: I am sure those are actually linux kernel bugs or vbios bugs
19:25 karolherbst: putting the GPU into some weirdo state the kernel isn't able to recover the device from
19:25 HdkR: My best bet is to get a consistent repro case and then I can throw it at people that actually work on the Linux team :P
19:26 karolherbst: ohh, I know how to break the GPU with the vbios and runtime suspend/resume alone :p
19:26 karolherbst: so that the GPU doesn't recover from that
19:26 HdkR: haha
19:27 karolherbst: HdkR: run devinit, runtime suspend -> GPU dies or falls off the bus
19:27 karolherbst: I have a workaround, which ... you will like, a lot
19:27 HdkR: hot unplug the GPU
19:27 HdkR: :D
19:27 karolherbst: better
19:27 karolherbst: HdkR: https://github.com/karolherbst/nouveau/commit/fee8604ea1f8f646dc701d6b9bf51e5dba086fb8#diff-461d1f940a4af1a65d5446e82e345de7
19:28 karolherbst: just think about it ;)
19:28 karolherbst: nvkm_pcie_fini is called before runtime suspending the GPU
19:29 karolherbst: and devinit puts the device into 2.5 mode (which booted at 8.0)
19:30 HdkR: Does that manage to effectively not take the GPU link down when suspend occurs
19:30 HdkR: ?
19:30 karolherbst: well
19:30 karolherbst: runtime suspend/resume is that _PR3 stuff
19:31 karolherbst: so those ACPI methods are invoked in either case
19:31 karolherbst: which should cut all power from the device
19:31 karolherbst: or well, most of it
19:31 karolherbst: Vaux is allowed to be still online
19:31 karolherbst: afaik
19:31 karolherbst: the bigger problem is, the GPU appears to be dead when turning the power back on
19:31 HdkR: lol
19:31 karolherbst: _but_ with a system suspend/resume you can revive the GPU
19:31 karolherbst: and with sysfs remove/rescan it is back again
19:32 HdkR: Interesting
19:32 karolherbst: very much so
19:32 karolherbst: anyway, my theory is, that if we set the PCI state back to the boot settings, it might actually fix that issue completly
19:32 karolherbst: question is: why
19:34 HdkR: Wonder if the firmware gets confused :P
19:34 karolherbst: what firmware?
19:34 karolherbst: or do you mean the UEFI?
19:35 HdkR: Does the firmware on the GPU get have to get pushed back on to the device after waking from suspend?
19:35 karolherbst: uhm... this is just the vbios PMU firmware for executing devinit
19:36 karolherbst: and if you post the card or run devinit, you have to load it again, yes
19:36 HdkR: Hm
19:36 karolherbst: but afaik there is no unload script
20:26 simonpatapon: hi
20:27 simonpatapon: just upgraded my Debian SID and i lost 2 screens out of 4 https://pastebin.com/L0uXsvaf
20:46 karolherbst: simonpatapon: ohh, so reverse prime doesn't work anymore? weird
20:46 karolherbst: anything in dmesg or the X log?
20:48 simonpatapon: here is my Xorg.lo : https://pastebin.com/RLkTh5Ku , lspci : https://pastebin.com/sP1ApK0H and xrandr error : https://pastebin.com/XavdLpqL
20:49 simonpatapon: i try to understand Xorg.log, i'm a newby but i think it uses fb instead of nouveau
20:49 simonpatapon: lsmod shows nouveau loaded
20:54 karolherbst: dmesg?
20:55 simonpatapon: i<ll have to reboot
20:56 simonpatapon: too many non related things
20:56 simonpatapon: please waitr
20:59 simonpatapon: https://pastebin.com/cfE5yafS here it is
21:02 karolherbst: mhh, weird
21:03 simonpatapon: I all mixed up i use to setsourceprovider
21:03 simonpatapon: Last year i think
21:03 simonpatapon: To activate the missing one
21:04 karolherbst: ahh, "modeset(0): eglGetDisplay() failed"
21:04 karolherbst: simonpatapon: does something like glxgears or glxinfo work?
21:04 karolherbst: I think your GLX setup might be completly broken
21:04 karolherbst: for unknown reasons
21:05 karolherbst: or well EGL
21:05 simonpatapon: Glegears does
21:05 karolherbst: mhh
21:06 simonpatapon: But i dont even know on wich card the system is running right now onboard intel or nvidia
21:08 gnarface: most of them default to intel
21:08 gnarface: some older generic drivers may work for either