00:53 NullTheSecond: Hello. I recently uninstalled Nvidia's drivers, but now I cannot set my monitor's resolution
00:54 NullTheSecond: Any ideas?
00:55 Sveta: what distribution are you using and what nouveau driver and what hardware (what graphics card)?
00:55 Sveta: "what nouveau driver" meaning "what nouveau driver version"
00:56 NullTheSecond: I'm using Fedora 27 (KDE Plasma spin)
00:56 NullTheSecond: How do I check for the driver version?
00:57 Sveta: in your package manager find the nouveau package and check its version, I think that would be fairly accurate
01:01 NullTheSecond: rpm -q xorg-x11-drv-nouveau.x86_64
01:01 NullTheSecond: xorg-x11-drv-nouveau-1.0.15-3.fc27.x86_64
01:02 Sveta: great, and i think you mentioned it is GTX 1070
01:02 Sveta: so you go to system settings and try to increase your display resolution, and what happens? it is not listed there, or?
01:04 Sveta: and a second question... could you please pastebin your 'lsmod' output
01:05 NullTheSecond: When I go to increase my display resolution, it only shows '1024x768'
01:05 NullTheSecond: I'll upload a paste
01:05 Sveta: '1024x768' is too small, right?
01:05 NullTheSecond: Yeah, 1920x1080 is my monitor
01:05 Sveta: how is it connected?
01:07 NullTheSecond: https://pastebin.com/L3RpBCFR
01:07 NullTheSecond: Via my GPU
01:09 Sveta: great
01:10 Sveta: this doesn't have nvidia listed (which i think is a plus), but it doesn't have nouveau listed either, at least not under this name
01:11 Sveta: looking at https://nouveau.freedesktop.org/wiki/TroubleShooting/, it suggests to "reinstall Xorg (libglx.so) and Mesa (GL libraries) "
01:12 Sveta: so you could do that to make sure there's no traces of nvidia left
01:12 Sveta: and if that still doesn't work, check your xorg log file for lines which say nouveau
01:13 Sveta: and if that STILL does not work, remove your Xorg config file and check, then replace it with a short version suggested in step 5 and check again
01:13 Sveta: pastebinning your xorg.log file could perhaps also be a bit handy
01:14 NullTheSecond: I did `sudo dnf erase \*nvidia\*`
01:14 NullTheSecond: Also, `cat /var/log/Xorg.0.log | grep "nouveau"` shows
01:14 NullTheSecond: `Kernel command line: BOOT_IMAGE=/vmlinuz-4.15.17-300.fc27.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_AU.UTF-8 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1`
01:15 Sveta: why'd you blacklist nouveau in the kernel?
01:15 NullTheSecond: I tried removing `rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1` but it keeps showing?
01:15 NullTheSecond: And when I edit it in the grub menu
01:15 NullTheSecond: e
01:15 NullTheSecond: it still doesn't work :c
01:15 NullTheSecond: (accidental enter)
01:15 Sveta: hmm, i'm not sure why it is there in the first place, i'll try to figure out how to remove it in a bit
01:17 Sveta: can you pastebin /boot/grub/menu.lst ?
01:18 NullTheSecond: `no such file or directory: /boot/grub/menu.lst`
01:18 NullTheSecond: I'm using Grub2
01:19 Sveta: what about /etc/default/grub ?
01:20 NullTheSecond: https://www.irccloud.com/pastebin/UuIDZbWY/
01:20 Sveta: ok, it's not there
01:20 Sveta: the blacklist lines are added by something else
01:21 Sveta: obviously i'm a newbie in this, sorry for going through so many hoops to get there...
01:21 NullTheSecond: I'm a newbie too
01:22 Sveta: perhaps run "grub2-mkconfig" and see if it helps
01:23 NullTheSecond: I've done that. I'll try using RPMFusion to install the drivers
01:23 NullTheSecond: `dnf install xorg-x11-drv-nvidia akmod-nvidia`
01:24 Sveta: is rpmfusion the official fedora's package manager?
01:24 NullTheSecond: It's trusted
01:24 NullTheSecond: Not official, but I've used it a lot
01:24 Sveta: you need to follow the same install process as you did when you installed nouveau the first time
01:25 NullTheSecond: It was pre-installed for me
01:25 Sveta: by whom?
01:25 NullTheSecond: I just ran `sudo dnf update`
01:25 NullTheSecond: Fresh install
01:25 NullTheSecond: It all just worked
01:26 Sveta: i'd suggest running "grub2-mkconfig -o /boot/grub2/grub.cfg" as root, and then rebooting, to see whether the nouveau driver is still blacklisted
01:26 Sveta: https://ask.fedoraproject.org/en/question/43026/nouveau-seems-not-enabled-after-removing-nvidia-driver/ sounds like your problem
01:26 NullTheSecond: I ran that command as root and rebooted, but when I still did that cat command, it displayed the same results
01:27 Sveta: what do you have in the /etc/grub.d/ directory?
01:27 NullTheSecond: Yeah, I followed that when doing it
01:27 NullTheSecond: I'll check
01:27 NullTheSecond: `00_header 10_linux 20_ppc_terminfo 40_custom README
01:27 NullTheSecond: 01_users 20_linux_xen 30_os-prober 41_custom`
01:28 Sveta: i'd pastebin all of that
01:28 Sveta: or
01:28 Sveta: grep nouveau /etc/grub.d/*
01:28 Sveta: that'd probably work better :P
01:29 NullTheSecond: `no matches found: /etc/grub.d/*`
01:30 NullTheSecond: `ls /usr/lib/modprobe.d` shows `nvidia-installer-disable-nouveau.conf`
01:30 Sveta: also i suspect that "/var/log/Xorg.0.log " might be an old file, perhaps nouveau isn't blacklisted right now. it'd be nice to check that somehow. try this:
01:30 Sveta: cat /proc/cmdline
01:30 Sveta: or this:
01:30 Sveta: dmesg | grep "Command line"
01:30 NullTheSecond: `Command line: BOOT_IMAGE=/vmlinuz-4.15.17-300.fc27.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_AU.UTF-8 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1`
01:30 Sveta: oi
01:31 NullTheSecond: Keeps coming back
01:31 Sveta: let's remove /usr/lib/modprobe.d/nvidia-installer-disable-nouveau.conf and reboot and see what happens
01:31 Sveta: 1) rm /usr/lib/modprobe.d/nvidia-installer-disable-nouveau.conf
01:31 Sveta: 2) grub2-mkconfig -o /boot/grub2/grub.cfg
01:31 Sveta: 3) reboot
01:32 Sveta: 4) kill nvidia with fire
01:32 Sveta: 5) ???
01:32 Sveta: 6) profit
01:33 NullTheSecond: Didn't work ;c
01:33 Sveta: did you actually reboot?
01:34 NullTheSecond: Yeah
01:34 Sveta: if so, i'll bring fire to you: grep -r nvidia /
01:34 Sveta: or...
01:34 Sveta: find -name *nvidia* /
01:35 NullTheSecond: `no matches found: *nvidia*`
01:35 NullTheSecond: Also, the Comand line still shows rd.driver...
01:36 Sveta: no matches found -- is that a result of the grep?
01:36 NullTheSecond: `grep -r nvidia /` spams a list of stuff
01:36 Sveta: pastebinning that could be a bit handy
01:36 Sveta: (since you want to remove nvidia, some of these files may be unnecessary)
01:38 NullTheSecond: https://www.irccloud.com/pastebin/XYlwho7v/
01:38 NullTheSecond: It's frozen here
01:39 Sveta: it's still searching give it time
01:40 Sveta:joins #nvidia and looks for 'halp it is not gone completely' links in topic
01:41 Sveta: your /etc/default/grub is only 7 lines long, correct?
01:43 Sveta: pastebin /etc/modprobe.d/nouveau_blacklist.conf
01:43 Sveta: pastebin /usr/lib/modprobe.d/nvidia.conf
01:44 Sveta: wait ignore the last one
01:44 Sveta: look for the relevant file in /etc/modprobe.d/ please :)
01:49 NullTheSecond: Hmm, I booted back removed the rd.driver etc/ by pressing 'e' again, waited a bit and now I've got my full resolution back
01:49 NullTheSecond: https://www.irccloud.com/pastebin/shwfGoMF/
01:49 NullTheSecond: But this is only temp
01:50 NullTheSecond: I booted back into the grub2 menu*
01:50 NullTheSecond: "your /etc/default/grub is only 7 lines long, correct?" correct
01:50 NullTheSecond: Wait a second
01:51 NullTheSecond: `GRUB_CMDLINE_LINUX="rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1 rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet"` I am so blind
01:53 NullTheSecond: *Facepalm*
01:54 NullTheSecond: Well, removing `rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1` fixed it
01:54 NullTheSecond: I can't believe I didn't see it there
02:03 NullTheSecond: Running `cat /proc/cmdline` still gives `BOOT_IMAGE=/vmlinuz-4.15.17-300.fc27.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_AU.UTF-8 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1`
02:03 NullTheSecond: https://www.irccloud.com/pastebin/DAcKh0tM/
02:51 imirkin: NullTheSecond: what are you trying to achieve?
02:52 NullTheSecond: Enable nouveau
02:52 NullTheSecond: I removed `rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1` from `/etc/default/grub` and updated my grub, but when I reboot and press 'e', it's still there
02:53 imirkin: figure out what distro you're using, and find a support channel for that distro that will help you properly operate it
02:54 NullTheSecond: I've spent two hours in #fefora and #linux
02:54 imirkin: chances are just editing that file does nothing
02:54 imirkin: you probably have to run some command so that things get updated
02:54 imirkin: by default, fedora has a very convoluted boot process
02:55 imirkin: which is very flexible, but incomprehensible to mere mortals
04:18 rhyskidd: OhGodAGirl: did you end up releasing that vbios tool you mentioned here over the weekend? would be interesting if you've found something
04:26 Sveta: yay NullTheSecond
11:14 OhGodAGirl: rhyskidd: Kind of. We released ETHlargement instead (but it is closed source). Because I couldn't miss up on the chance at shitposting.
11:14 OhGodAGirl: https://www.youtube.com/watch?v=8Tal2dzSfiQ
11:23 pmoreau: juri_: Most nva* executables have some documentation: https://github.com/envytools/envytools/blob/master/nva/README
12:16 juri_: pmoreau: found that last night. I'll probably use tearing apart that and the code to update the docs/
13:03 karolherbst: interesting
13:03 karolherbst: nvidia uses VABSDIFF.U32.U32.ACC do implement abs_diff
13:10 imirkin: SAD is gone
13:23 karolherbst: imirkin: sad wouldn't help here
13:23 karolherbst: I think
13:23 imirkin: sad == abs diff
13:23 karolherbst: really?
13:24 imirkin: iirc yeah
13:24 karolherbst: mhh, abs_diff has some weirdo semantics
13:24 karolherbst: needs 33 bit precision and so on
13:25 imirkin: SAD(a,b,c) = |a-b| + |b-c| or ... something like that.
13:25 karolherbst: yeah, that's not what abs_diff does though
13:25 imirkin: ah.
13:26 karolherbst: |x-y| without modulo overflow.
13:26 karolherbst: can't use sub to implement on u32
13:26 imirkin: ah. hence the .ACC in VABSDIFF
13:26 imirkin: sure you can
13:26 karolherbst: no
13:26 imirkin: with the overflow bit :)
13:26 karolherbst: and then?
13:26 imirkin: i'd have to think about it, but you have all the info
13:27 karolherbst: well conditional neg might fix it
13:27 karolherbst: if flag set -> neg result
13:27 karolherbst: or something
13:27 imirkin: like i said - would have to think about it ;)
13:27 karolherbst: abs_diff(0x1, 0x100) == abs_diff(0x100, 0x1) ;)
13:27 imirkin: that's how abs diff's work.
13:28 karolherbst: yeah
13:28 imirkin: i.e. |a-b|
13:28 karolherbst: right
13:28 karolherbst: but you need that conditional abs in the u32 case
13:28 karolherbst: which makes it a bit annoying to implement abs_diff
13:29 karolherbst: but mhh
13:30 karolherbst: no, that won't work as well
13:30 karolherbst: or maybe it does
13:30 andreycizov: Hey - I am trying to set up 1080ti with nouveau in 18.04. It's connected to 3 4K monitors (not sure if that could be an issue) and works fine under proprietary drivers. On the other hand I get a black screen with a flash of mouse cursor followed by a segfault of gnome-shell in nouveau_dri if I use nouveau; switching to lightdm gives me the greeter, but when entering gnome session it fails the same way. Should I
13:30 andreycizov: submit a bug report or are there any other things I should try?
13:30 karolherbst: if b > a -> abs(res)
13:31 karolherbst: for u32
13:31 karolherbst: andreycizov: uhh 3 X 4K won't work
13:31 karolherbst: most likely
13:31 karolherbst: well, but maybe you encounter different issues
13:32 karolherbst: it shouldn't crash, just basically only displaying trash in the worst case
13:32 karolherbst: thing is, we need to to be able to reclock in those szenarios which we can't due to missing signed firmware
13:33 andreycizov: karolherb: ah right. so even if I do - then I shouldn't expect 60hz at all at these settings?
13:33 andreycizov: karolherb: that's the line I am getting: "gnome-shell[3735]: segfault at 1a ip 00007f885f2f3e1e sp 00007ffe25879770 error 4 in nouveau_dri.so[7f885f0a9000+af7000]"
13:33 karolherbst: imirkin: on kepler1 they use sad
13:34 andreycizov: karolherb: it it worth setting up gdb to get the stack trace, etc?
13:34 karolherbst: imirkin: ISAD.U32 R0, R0, c[0x0][0x148], RZ;
13:34 karolherbst: andreycizov: I think it would be helpful to open a bug report
13:34 andreycizov: karolherb: does it go to nouveau or gnome-shell?
13:35 karolherbst: depends on the bug, but I guess nouveau might be the safe place here first
13:36 andreycizov: karolherb: thanks a lot!
13:39 karolherbst: imirkin: ohh actually on kepler2 they use sad as well, just not maxwell
13:42 karolherbst: *on
15:13 imirkin_: karolherbst: it's gone on maxwell. very sad.
15:14 karolherbst: imirkin_: yeah, especially because "sad.u32 %r5, %r2, %r3, %r4;" is literally in the ptx code
15:15 karolherbst: let me check what happens when %r4 isn't 0
15:15 HdkR: imirkin_: no no, no more sads :P
15:15 karolherbst: still "VABSDIFF.U32.U32.ACC R2, R2, R3, R4"
15:15 karolherbst: imirkin_: they even use it with O0
15:16 imirkin_: karolherbst: that's coz sad is gone on maxwell.
15:16 karolherbst: ahh
15:16 karolherbst: is vabsdiff a thing pre maxwell?
15:16 imirkin_: (didn't i say that above?)
15:16 HdkR: Only Happy on Maxwell
15:16 imirkin_: karolherbst: yeah
15:16 karolherbst: mhh, I see
15:21 imirkin_: or at least some variants of it
15:46 nikk_: Hello everyone! Any suggestions for resources to understand structure of drivers for Linux kernel(nouveau), how to write drivers etc?
15:47 imirkin_: rtfs and ask questions
15:47 jn__: and sometimes https://www.kernel.org/doc/html/latest/index.html helps
15:50 nikk_: imirkin: what is rtfs?
15:50 nikk_: Sorry if that is very basic.. But I am totally a beginner
15:50 HdkR: Read the source :)
15:51 imirkin_: http://bfy.tw/Hn5l
15:52 karolherbst: imirkin_: even lmgtfy becomes fancy now
15:52 karolherbst: I want the old school style :(
15:54 imirkin_: welcome to being old.
15:54 imirkin_: it doesn't get better from here.
15:54 karolherbst: I know
15:54 nikk_: One more question what services you’ll use for IRC communication? I installed hexchat on my Linux machine but even if I suspend my machine the session is lost..
15:55 imirkin_: TCP socket closes ...
15:55 imirkin_: some people use bouncers. i don't.
15:55 karolherbst: I use znc at work.. I think
15:55 karolherbst: uhm
15:55 karolherbst: was it called znc?
15:55 karolherbst: bnz?
15:55 HdkR: I use irssi through a VPS running in London as a "bouncer"
15:55 karolherbst: znc indeed
15:56 pmoreau: I use znc as well.
15:57 nikk_: Ok I’ll try it! :)
15:57 imirkin_: the point is ... you need some other machine
15:57 imirkin_: it's not about the software you use locally
15:58 karolherbst: some fake china raspy might do the trick as well
16:00 nikk_: Ya like a machine dedicated to this development.. I’ll try and set this up:)
16:11 pendingchaos: nikk_: You may also find hhttps://elixir.bootlin.com/linux/latest/source or http://lxr.linux.no/+trees useful
16:44 nikk_: So I am reading from a few references mentioned by all. But now alongside for development I need to install nouveau on my GPU right? I have a fermi card.. Referring to this currently : https://nouveau.freedesktop.org/wiki/InstallNouveau/
16:45 nikk_: Am I going right?
16:46 gnarface: well the debian one is ancient enough to be completely invalid
16:46 gnarface: can't speak for the rest
16:48 HdkR: You also don't install Nouveau on the GPU. You install Nouveau on your PC and Nouveau programs the GPU to do things :P
16:50 gnarface: whatever release debian unstable was tracking at the time that didn't have nouveau as the default, it has been obsolete since at least 2015 (probably actually since 2013 or so)
16:52 gnarface: `apt-get build-dep linux-image-2.6-amd64` suggests squeeze or maybe early wheezy
16:55 nikk__: Oh okay! Thanks guys!
17:01 Lyude: hm, well that's new
17:02 Lyude: got the GT710 in the mail today; it's actually listed solely as GK208B and nvagetbios thinks it's a nv00
17:02 imirkin_: nvagetbios is very old
17:02 imirkin_: load up nouveau, grab vbios.rom
17:03 Lyude: mm-but first i need to fix that so it will let me use pramin :)
17:03 imirkin_: (nvagetbios wasn't updated for extra bits)
17:03 imirkin_: anyways, don't you go breaking any speed limits with that gpu!
17:03 Lyude: hehe
17:05 HdkR: Oh, that reminds me that I have a GT 710 stuck in a box over here
17:08 imirkin_: they get handed out like candy with new machines
17:13 HdkR: I got told by IT that it was "a pretty good GPU"
17:13 imirkin_: it actually is :)
17:14 Lyude: it's very small and thin
17:14 imirkin_: it's fun to make fun of it, but i actually think GK208's are pretty great.
17:14 imirkin_: like 30W TDP
17:14 imirkin_: you get h264 decoding, 4 CRTC's, and "enough" gpu power for everything but aaa games.
17:17 Lyude:goes to update nva's card detection
18:22 RSpliet: misc.ktemkin.com/fusee_gelee_nvidia.pdf
18:22 RSpliet: ...
18:22 RSpliet:curses at FF
18:22 RSpliet: http://misc.ktemkin.com/fusee_gelee_nvidia.pdf
18:23 Lyude: yeah i've been wondering about that
18:25 RSpliet: Hehe, I suspect your wonderings didn't get to anything tangible, I don't think much of that code is shared...
18:31 Lyude: yeah
18:31 Lyude: but it was discovered by the switch people
18:31 Lyude: so i'd hope maybe we can get a copy of how they did it and play around with it :)
18:37 RSpliet: you mean the stuff in https://github.com/reswitched/fusee-launcher ?
18:39 Lyude: I supposee, like I said I haven't actually touched any of it
19:46 Lyude: Does anyone know in nouveau where we actually parse the pmc_id?
19:46 Lyude: e.g. what's at reg 0x0
19:46 Lyude: i'm having a surprisingly difficult time finding this
19:48 imirkin_: boot0
19:48 imirkin_: try searching for that
19:49 Lyude: ooooooh, ok, I think this is what I'm looking for :). thanks!
19:51 imirkin_: probably drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
19:52 imirkin_: (i dunno what you want, but it all begins there)
20:41 Subv: hey, in Fermi or Maxwell, what happens if a QUERY sync condition isn't met? it stalls the PGRAPH command processor until it is?
20:42 imirkin_: yep
20:43 imirkin_: well - stalls command processing
20:43 imirkin_: same idea though :)
20:43 imirkin_: [er, that's what you said. nevermind.]
20:47 Subv: how does it continue? can you execute another command list while that one is paused? (does this have anything to do with multiple channels?)
20:48 Subv: or must you write to the query address manually from the CPU to let it continue?
20:48 imirkin_: not sure, sorry
20:51 Subv: the query methods are quite interesting :)
21:08 pendingchaos_: imirkin_: Am I correct in thinking NV50_IR_SUBOP_PIXLD_OFFSET gets the current sample location (and is the pixld that you were talking about before)?
21:11 imirkin_: pendingchaos_: not 100% correct
21:11 imirkin_: pendingchaos_: it takes an argument, the sample id
21:12 imirkin_: and returns a packed offset for that sample
21:12 pendingchaos_: oops yeah
21:12 imirkin_: based on the current fb settings
21:12 pendingchaos_: forgot about the sample id thing when writing the message
21:12 imirkin_: now ... this packed offset is very convenient since it's *precisely* what the interp op needs
21:12 imirkin_: however it's not like float. so you'd have to multiply it out to get float.
21:13 imirkin_: (i forget what it is ... i think it's just the 0..15 value, and you have to multiply it by 1/16 and offset by 0.5)
21:13 imirkin_: check how interpolateAtOffset is implemented -- it has the inverse conversion of what you'd need to get the sample pos out :)
21:14 imirkin_: [since that takes a float which is converted to arguments appropriate for the interpolator]
21:16 imirkin_: pendingchaos_: btw, untested for the gm200+ variable offset situation
21:16 imirkin_: i've only used it in the context of interpolateAtSample()
21:28 pendingchaos_:nods
21:56 Lyude: no wonder no one updated nva for detecting the right ID on weird cards like GK208B
21:56 Lyude: i think I fixed it but figuring out which bits we could actually rely on for endianness took forever :S
21:57 Lyude: pmc_id & 0x80000000, except if pmc_id & 0x00000080 is also true in which case pmc_id & 0x00000F00
22:06 imirkin_: Lyude: do what nouveau does.
22:06 imirkin_: Lyude: also iirc demmio does it right
22:08 Lyude: imirkin_: that's what I did actually, but nouveau determines it using 0x4 which marks the endianness there. parse_pmc_id (specifically with demmio, actually) can get called in spots where we're reading a previous trace, so don't nessecarily have the value of that register (and additionally: it may not matter anyway, because we don't know the actual native endianness of the machine that the trace happened on)
22:09 Lyude: but: on cards where it's possible the old B31=1 B7=0 trick doesn't work due to B31=1 and B7=1, all of those cards are later generations where 8-11 are never used! (verified with the vbios repo)
22:10 Lyude: so, all we need to do is just use those bits when we can't do the old trick and we're golden
22:14 Lyude: (for reference, 0xb060b031 is the PMC id that tripped us up)
22:14 Lyude: it doesn't seem that any other cards I can find in the vbios repo have a foundary set to 0x5 like that
22:15 Lyude: i'm going to do a pull req for this though, just to make sure I'm not being silly and overcomplicating this
22:17 imirkin_: you know, this feels familiar
22:17 imirkin_: iirc this tripped something up before too
22:19 Lyude: it probably did; since there aren't actually any PMC.ID values that trigger this issue in the vbios repo there wasn't actually anything in there to make demmio trip up on this (and I think it would have; since it uses nva for parsing the PMC.ID for determining the generation as well)
22:21 imirkin_: https://github.com/envytools/envytools/commit/9cb00ac70a9c821c44cf6cf82fad6a4aa1526cad#diff-a6eddbcaf89dae9308698d7a080ce0a2
22:22 imirkin_: the endian stuff isn't really worth bothering too much with...
22:22 imirkin_: dunno
22:22 Lyude: ahhh, unfortunately that still wouldn't work though in this case since they're not actually dealing with a flipped value
22:22 Lyude: imirkin_: yeah that was mostly just to get envytools to work with this card
22:22 Lyude: since otherwise it gets confused, thinks the endianness is flipped, fails to unflip it then exits immediately
22:51 karolherbst: imirkin_: does CVT.TRUNC overwrite "empty" bits sign-extended?
22:52 karolherbst: like if you do f32->s16 bits 16-31 will be set to the sign?
22:52 imirkin_: karolherbst: hopefully.
22:53 karolherbst: well, not the issue I see though, but still
22:53 karolherbst: nvidia seems to set it quite often
22:53 karolherbst: ohh, wait
22:53 karolherbst: I have to set the rounding mode for the new ops
22:57 karolherbst: imirkin_: the annoying part is, that there is no f32->s8 conversion :(
22:57 imirkin_: yeah. check UP2H
22:57 karolherbst: well, not directly
22:57 imirkin_: (or PK2H or whatever)
22:57 imirkin_: er, not those
22:57 karolherbst: it uses f32 -> s16
22:57 imirkin_: there were others.
22:57 karolherbst: it = nvidia
22:58 karolherbst: for f64 -> s16/s8 nvidia does f64 -> s32 -> s16
22:59 Lyude: PDAEMON.PG_IDLEFILTH[0] <- lol, just noticed the name on this. where did that come from?
23:01 karolherbst: imirkin_: now the question, is this lowering of 64 bit ops or lowering of 8/16 bit ops?
23:02 skeggsb: Lyude: probably nvgpu
23:02 skeggsb: static inline u32 pwr_pmu_pg_idlefilth_r(u32 i)
23:02 skeggsb: { return 0x0010a6c0+(i)*4;
23:02 skeggsb: }
23:02 Lyude: ah, wonder what's so filthy
23:04 imirkin_: skeggsb: did my hwmon thing make sense?
23:05 imirkin_: skeggsb: i forgot to put you on the To: but hopefully you saw it anyways
23:05 skeggsb: yeah, i think so
23:06 imirkin_: ok cool
23:33 karolherbst: imirkin_: I2I.U16.U32.SAT is this OP_SAT?
23:33 imirkin_: kinda
23:33 imirkin_: it will do a min/max to the range
23:33 imirkin_: so like u32 -> u16, with anything out of bounds getting clamped
23:33 karolherbst: right
23:34 karolherbst: but can I just use OP_SAT for this?
23:34 imirkin_: yes, in theory
23:34 karolherbst: or can't OP_SAT handle 16 bit types?
23:34 imirkin_: in practice, you might hit emitter errors.
23:34 imirkin_: it should
23:34 karolherbst: okay
23:34 imirkin_: but it's not much tested.
23:34 imirkin_: it's used for clamping the array id for textures
23:34 imirkin_: (to 16-bit)
23:34 karolherbst: right
23:34 karolherbst: I see
23:35 karolherbst: "sat cvt s32 $r6 f64 $r6d" :)
23:35 karolherbst: wondering why nvidia doesn't do that
23:36 imirkin_: perhaps it doesn't work.
23:36 imirkin_: ;)
23:36 karolherbst: uhm....
23:36 karolherbst: huh
23:36 imirkin_: just coz it can be written doesn't make it so.
23:36 imirkin_: (maybe it does work fine, i have no clue)
23:36 karolherbst: bug in opts
23:36 karolherbst: cvt s32 %r93 f64 %r92d + sat s16 rz %r94 s32 %r93 => sat cvt s32 %r94 f64 %r92d
23:37 karolherbst: I have to fix up the rounding mode as well
23:37 imirkin_: hm, yeah, those types don't match up.
23:37 imirkin_: i don't think you can do that with OP_SAT
23:37 imirkin_: i think you have to use OP_CVT
23:37 imirkin_: with a sat modifier
23:37 imirkin_: or ... i dunno
23:37 imirkin_: check what the tex thing does
23:37 imirkin_: it all maps down to OP_CVT of course
23:39 karolherbst: huh
23:39 karolherbst: now it works (after fixing the rounding modes)
23:39 karolherbst: or maybe bld.mkCvt(OP_SAT) does something smart
23:40 karolherbst: mhhh
23:40 karolherbst: "sat cvt s32 rz $r6 f64 $r6d"
23:40 karolherbst: the CTS is happy, but...
23:43 karolherbst: but it is also happy with a "cvt s32 rz $r6 f64 $r6d"
23:44 karolherbst: maybe the CTS just doesn't generate good enough test data
23:44 karolherbst: ohh, I see
23:45 karolherbst: in OpenCL you can do explicit conversions
23:45 karolherbst: and convert_char_sat(double) needs the sat thing
23:48 karolherbst: "When converting from a floating-point type to integer type, the behavior is implementation- defined." ahh, nice
23:48 karolherbst: I guess we can always do a sat then
23:52 karolherbst: imirkin_: ->saturate = sat;
23:52 karolherbst: uhm
23:52 karolherbst: yeah