01:55 user_457788: I have an issue using nouveau driver with NVIDIA VGA
01:55 user_457788: I can not change the backlight:
01:55 user_457788: $ xbacklight -dec 10
01:55 user_457788: No outputs have backlight property
01:56 user_457788: dmesg shows a warning might be relevent
01:56 user_457788: [ 17.529225] ACPI Warning: \_SB_.PCI0.PEGP.DGFX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (201509 30/nsarguments-95)
01:57 user_457788: [ 17.529924] ACPI: \_SB_.PCI0.PEGP.DGFX: failed to evaluate _DSM
01:58 user_457788: [ 17.530187] nouveau 0000:01:00.0: NVIDIA GM107 (117330a2)
01:58 user_457788: [ 17.539533] nouveau 0000:01:00.0: bios: version 82.07.6d.00.1a
01:58 user_457788: [ 17.540355] nouveau 0000:01:00.0: mxm: BIOS version 3.0
01:58 user_457788: [ 17.543051] ACPI Warning: \_SB_.PCI0.PEGP.DGFX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (201509 30/nsarguments-95)
01:58 user_457788: [ 17.544048] nouveau 0000:01:00.0: fb: 2048 MiB GDDR5
01:59 user_457788: I used to use nvidia drivers on the same OS and the backlight was functioning without issues
02:01 user_457788: This is a fresh install of the OS on the same machine using the same OS, but now I'm using nnouveau driver
02:01 user_457788: lspci -v:
02:01 user_457788: 01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro K2200M] (rev a2) (prog-if 00 [VGA controller])
02:01 user_457788: Subsystem: Hewlett-Packard Company GM107GLM [Quadro K2200M]
02:02 user_457788: ....
02:02 user_457788: Kernel driver in use: nouveau
02:02 user_457788: Kernel modules: nvidiafb, nouveau
02:03 user_457788: ls /sys/class/backlight/
02:03 user_457788: acpi_video0
02:04 user_457788: kernel 4.4.8
02:04 tdaven: have you tried the brightness file under that acpi_video0?
02:04 tdaven: can usually read from it to get the range
02:05 user_457788: two files, I could write to one but nothing change and the other one (actual) access denied
02:05 user_457788: the range 0-20
02:06 tdaven: usually you can echo number > brightness to manually change...of course you'd need to be root...
02:07 user_457788: right, i'm root and i could wirte to brightness, however nothing change
02:08 user_457788: there's another file, actual_brightness, which denies writing by root
02:08 tdaven: have you tried something like "find /sys/ -type f -iname '*brightness*'" to see if there is another brightness file? otherwise you'd need someone probably more familiar with acpi to understand what is getting parsed wrong
02:08 tdaven: yeah...actual_brightness is read only I think
02:16 user_45889: find /sys/ -type f -iname '*brightness*':
02:17 user_45889: sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0/brightness
02:18 user_45889: /sys/devices/pci0000:00/0000:00:1c.6/0000:3c:00.0/0000:3d:01.0/0000:3e:00.0/leds/phy0-led/brightness
02:18 user_45889: /sys/devices/virtual/leds/hp::hddprotect/brightness
02:18 user_45889: /sys/devices/platform/i8042/serio0/input/input0/input0::capslock/brightness
02:18 user_45889: /sys/devices/platform/i8042/serio0/input/input0/input0::scrolllock/brightness
02:19 user_45889: /sys/devices/platform/i8042/serio0/input/input0/input0::numlock/brightness
02:19 user_45889: /sys/module/video/parameters/brightness_switch_enabled
02:25 user_45889: I will be around for a while in case additional info needed..
05:53 hussam: does nouveau not fully support cards identified as nvc1?
05:54 hussam: I tried nouveau on kernel 4.6 and trying to echo 0f to pstate said no implemented.
07:26 hussam: is there any way to not use the lowest frequency speed on a nvidia 630 GT? (nvc1)
08:50 RSpliet: imirkin: out of curiousity, did you observe a big change in gpr usage after 5c6b8cc... ("nv50/ir: treat addresses as local")?
08:54 mwk: karolherbst: btw, a funny thing about nv eth you may not know of...
08:54 mwk: I have no idea what it depends on
08:54 mwk: but sometimes it identifies as the "network device" class, and sometimes as the "bridge" class
08:55 karolherbst: ohh didn't know that
08:55 mwk: so I think we need to stuff a list of PCI IDs and ignore the class
08:58 mwk: luckily I do have a list :)
09:01 mwk: oh, and another little-known fact
09:01 mwk: the MCP2 chipset had two ethernet controllers
09:01 mwk: one of them is the usual nv eth one
09:01 mwk: the other... is a PCI core licensed from 3com
09:02 mwk: and the chipset contains a separate PCI bridge just for it
09:02 mwk: and yeah, it's built into the actual die of the MCP2
09:02 mwk: it's disabled on my motherboard, but I managed to enable it in the southbridge PCI config space
09:02 mwk: and it showed up in lspci...
09:02 karolherbst: :D
09:03 mwk: don't ask me why they have two different eths on a single chip
09:03 mwk: a licensed one, at that
09:03 mwk: I have no fucking clue
09:03 karolherbst: maybe
09:03 karolherbst: the put a hw wrapper around the chip they used
09:03 karolherbst: so they can just write a single driver
09:03 karolherbst: or something stupid like that :D
09:04 mwk: nah, there's reasonably good evidence on the internet that they are two separate chips
09:04 karolherbst: ahh okay
09:04 mwk: as in, if you get the right mobo, you actually get two NICs
09:05 mwk: oh, and the network device and bridge also have a different PCI id
09:05 karolherbst: fancy
09:05 pmoreau: user_45889: The ACPI warning should be irrelevant: it’s for detecting Optimus setups and auto-suspend in that case. And each time Nouveau does not find one of the Optimus methods, it outputs an error message, even if the method just does not exist, like on a desktop computer.
09:05 mwk: as opposed to GPUs, which keep their pci id when you switch the pci class
09:06 pmoreau: user_45889: Could you please paste the full dmesg somewhere? It looks like Nouveau did not register a backlight interface, otherwise you would have `/sys/class/backlight/nv_backlight`
09:14 mwk: matter of fact
09:14 mwk: I don't understand the numbering at all
09:14 mwk: the bottom few bits can be reprogrammed by a PCI config register
09:15 mwk: and, on MCP77/MCP79, there's a bit that changes the whole pci id to 0x57X instead of the usual
09:16 mwk: *and* that applies not just to the eth device, but also to SATA and HDA (although they have different alt pci id ranges)
09:17 mwk: the SATA controller has three ranges selected by IDE mode vs SATA mode vs RAID mode, but there are still 2 unexplained bits
09:17 karolherbst: mhh
09:18 karolherbst: mwk: I guess AHCI is too new for those chips?
09:18 karolherbst: or is SATA mode == AHCI?
09:18 mwk: "prepare an alternate identity in case we commit a horrible crime and everyone is looking for us"? :)
09:18 mwk: ah yes, I mean AHCI
09:18 mwk: http://envytools.readthedocs.io/en/latest/hw/pciid.html#motherboard-chipsets
09:18 mwk: here's the list of all crap I found on the chipsets
09:19 mwk: I also have a list of "nforce XXX" name mapping to the actual chips
09:19 karolherbst: what about the co processor?
09:19 mwk: you wouldn't believe how hard it was to get that one
09:20 mwk: you mean the SMU?
09:20 karolherbst: well it shows up as "co processor" in lspci
09:20 mwk: yep, it's the SMU
09:20 karolherbst: ahh okay
09:20 mwk: a funny beast
09:20 mwk: I still have no idea what it's supposed to be doing
09:20 karolherbst: :D
09:20 mwk: I could decompile the code for it, I suppose
09:21 karolherbst: well poke stuff in it and check if you get some network traffic via wireshark or something :D
09:21 mwk: but there's a little problem of messing with all these chipset PCI config register I don't understand
09:21 mwk: nah, it's too dumb for that
09:21 mwk: the code is quite small
09:21 mwk: as in, Falcon-scale, and one of the smaller Falcons
09:22 karolherbst: ahh okay
09:22 mwk: I'm still impressed how the took the intel 8051 MCU and hooked it up as a HyperTransport master
09:23 karolherbst: ohh right, wait. I think the SMU might be something like the ME thing or the SMU on those PPCs?
09:23 mwk: so, what does it do?
09:24 karolherbst: well on the macs it somehow stored some stuff between boots and also took care about some power management related things? not sure anymore
09:24 karolherbst: I had to reset it once and now idea what it did back then anymore
09:24 karolherbst: ohh it was called PMU, not SMU on powerpc
09:24 mwk: that thing is called PMU too
09:24 mwk: it seems they can't decide on a name
09:24 karolherbst: ahh k
09:25 karolherbst: well
09:25 karolherbst: well if your mac didn't boot, sometimes reseting the PMU helped
09:25 mwk: the pciid database has it as "co-processor" on some chipsets, "SMU" on others, "PMU on yet others"
09:25 tajjada: nouveau is quite unstable on my system; X server freezes somewhat frequently (mouse cursor still moves, and I can still hear my music playing, so I know the system is alive), and certain things like shadertoy.com (to be fair, I shouldn't even be trying to run that on a GPU as weak as mine) result in an instant crash/freeze
09:25 karolherbst: I think it stored the initial volume of the audio chip
09:26 tajjada: is it just that nouveau has poor support for my card (gt710, gk208 gpu), or is there something I could try to improve things
09:26 karolherbst: like the bootup tune volume was reseted after PMU reset
09:26 mwk: wow, that's an important task
09:26 karolherbst: :D
09:26 karolherbst: maybe it stored even the display brightness
09:26 karolherbst: I think the mb clock was also on the PMU
09:26 mwk: even more important!
09:26 karolherbst: no idea though
09:26 mwk: anyhow
09:27 mwk: probably some power management stuff
09:27 karolherbst: yeah
09:27 mwk: I blew it up a few times with no ill result
09:27 pmoreau: karolherbst: Aren’t you mixing up with https://support.apple.com/en-us/HT204063 ? Or is that SMU including the NVRAM?
09:28 pmoreau: tajjada: Do you have a dmesg from when your computer freezes? And which version of the kernel do you have?
09:28 tajjada: kernel 4.6, using xf86-video-modesetting with DRI3
09:29 mwk: also, here goes
09:29 karolherbst: pmoreau: ahh right, that was PRAM
09:29 pmoreau: I think you should use xf86-video-nouveau for Kepler (and below) cards. modesetting is needed for Maxwell
09:29 karolherbst: pmoreau: but the SMC page also isn't really interessting
09:29 karolherbst: pmoreau: https://support.apple.com/en-us/HT201295
09:29 pmoreau: Yeah, I saw it afterwards
09:30 tajjada: pmoreau: ok, I will try switching to xf86-video-nouveau for a while, see how that goes. if there are still issues, I will report back
09:31 tajjada: pmoreau: i was just left with the impression that nouveau devs are trying to phase out the nouveau ddx because modesetting is somehow better
09:31 pmoreau: tajjada: Pasting your dmesg and Xorg.log should still be helpful
09:31 karolherbst: huh "chromium-browser: relocation error: chromium-browser: symbol pci_init, version LIBPCI_3.0 not defined in file libpci.so.3 with link time reference" :/
09:32 tajjada: pmoreau: well, I don't have any of that at the moment, I will try to capture it when the issue happens again
09:32 pmoreau: gtg though, I'll be back later
09:32 karolherbst: stupid pciutils
09:33 pmoreau: tajjada: xf86-video-nouveau will give you 2d acceleration on Kepler (and below), but that support is broken for Maxwell, hence using modesetting for now.
09:34 pmoreau: (at least that one reason, but probably not the only one)
09:35 tajjada: pmoreau: i got this card recently (used radeonsi on an amd card before, which I gave to my sister), and, as I said, I was just left with the impression that modesetting was better, so I just used that
09:35 tajjada: from reading things online, on phoronix forums and other places, regarding nouveau vs modesetting
09:35 karolherbst: tajjada: well on maxwell cards that is true
09:35 tajjada: ok, i will switch to the nouveau DDX and see if things get better
09:37 tajjada: brb restarting Xorg
09:40 tajjada: ok i just ran one program that causes nouveau errors
09:40 tajjada: fortunately, this time, just the program crashed
09:40 tajjada: X didn't freeze
09:40 tajjada: here is dmesg:
09:40 tajjada: [ 144.294849] nouveau 0000:02:00.0: gr: ILLEGAL_CLASS ch 5 [003fb2d000 X[1712]] subc 0 class 0000 mthd 1b0c data 1000f010
09:40 tajjada: and lots and lots of that same message
09:41 tajjada: with different hexadecimal values at the end
09:57 karolherbst: tajjada: updating mesa/kernel might be worth a host
09:57 karolherbst: *shot
09:58 tajjada: karolherbst: i am running kernel 4.6, which just got released last weekend, and i am running mesa from git (and xorg server and drivers from git)
09:58 tajjada: last time i updated mesa was on monday
09:58 tajjada: i doubt that much has changed in git master since then
09:59 tajjada: but sure
10:02 karolherbst: mhh
10:02 karolherbst: well
10:02 karolherbst: then I think it won't change much
10:03 karolherbst: I am sure imirkin or somebody else might be able to help more here
10:04 tajjada: karolherbst: yeah, probably
10:09 tajjada: i already ordered a cheap AMD card to use instead of this one, for stability, it will arrive next week monday, but I'll still keep this card, and I'll be happy to help debug/troubleshoot the issues
10:09 tajjada: i like to see nouveau (and open-source drivers in general) improve
10:10 karolherbst: tajjada: well it might also be, that the gpu is just missconfigured and that with my reclocking patches and an initial reclock it will be better, but my stuff is currently based on 4.5
10:11 karolherbst: but
10:11 karolherbst: the X server doesn't freeze anymore
10:11 karolherbst: so maybe it is just an userspace issue
10:11 tajjada: BTW, i tried whatever reclocking is available in the mainline kernel
10:12 tajjada: it worked, and i played xonotic on it, but there were still occasional freezes
10:13 tajjada: initially, i suspected that maybe my CPU overclock is not as stable as i think it is, and might be causing problems, so I reset my CPU to stock settings, and freezes still happened
10:20 karolherbst: tajjada: well stock nouveau reclocking isn't really stable anyway on kepler
10:21 karolherbst: but there are also some random freezes we have to figure out besides that
10:22 tajjada: karolherbst: well, i'll be glad to help in whatever way i can
10:22 tajjada: i am very inexperienced in this driver stuff, though
10:31 tajjada: .... aaaand pc crashed again
10:54 pmoreau: karolherbst: Could it be the too low voltage problem? Or did it only occur while reclocking?
10:55 pmoreau: karolherbst RSpliet: BTW, in case you haven’t seen it yet, Ben rebased on 4.6 and created a 4.7 branch. :-)
11:01 pmoreau: tajjada: "Maybe" it is similar to the PGRAPH issues on GK106/GK107, so you could try the patches found here https://bugs.freedesktop.org/show_bug.cgi?id=93629 or using the blob firmware instead of Nouveau’s one (see the instructions https://nouveau.freedesktop.org/wiki/NVC0_Firmware/ )
11:02 tajjada: pmoreau: the stuff in that bug report sounds very familiar
11:03 tajjada: i'll give it a try
11:03 tajjada: i'm a bit busy now, for a couple of hours, so i'll play around with it later today, when i have time
11:07 pmoreau: Sure, whenever you have time
11:09 pmoreau: tajjada: What kind of VRAM does your card have?
11:09 tajjada: 1GB DDR3
11:10 tajjada: this is my card: https://www.msi.com/Graphics-card/GT-710-1GD3H-LP.html#hero-specification
11:12 karolherbst: pmoreau: I doubt that. Usually the stock config of the cards is pretty close, sometimes even overvolted
11:12 pmoreau: tajjada: Ok, thanks
11:12 pmoreau: karolherbst: Oh, ok :-D The graph firmware might be a better culprit then.
11:13 karolherbst: yeah
11:13 karolherbst: or something else
11:13 karolherbst: I think that maybe sometimes card have a real _bad_ production quality and that the driver can do some stuff to counter that? There are some more bits in PFUSE which might tell use stuff about that besides the speedo
11:14 pmoreau: GDDR5 is the problematic VRAM on Kepler for reclocking, isn’t it? Or am I mixing everything again…
11:14 pmoreau: Could be
11:14 karolherbst: why should it?
11:14 karolherbst: currently I would expect DDR3 being less stable
11:15 karolherbst: pmoreau: I think we should collect information about which cards are still crashing on my branch and see if we find anything in common
11:15 pmoreau: Dunno, I remember one type being not that supported for Kepler cards
11:15 pmoreau: Yup
11:16 karolherbst: pmoreau: yeah, and I fixed that :p and it was gddr5
11:16 pmoreau: Ah! My memory isn’t that bad then \o/
11:16 karolherbst: pmoreau: https://github.com/karolherbst/nouveau/commit/616ed151cd5bd6e92df10e281862a9cc37c96282
11:17 karolherbst: it might be that we also have PLL issues somewhere else
11:17 karolherbst: there are som implicit rules the nvidia driver follows
11:17 karolherbst: even on the cores
11:17 karolherbst: but it shouldn't matter, by accidence only though
11:17 pmoreau: I’ll retry your branch again on my GK107. Only the memory is being reclocked IIRC, which is not enough for playing Stellaris, but I made the mistake of updating to latest drm-next, and then I couldn’t build Nouveau against it.
11:17 karolherbst: pmoreau: ahh right
11:18 karolherbst: pmoreau: yeah, that's all fixed with my branch
11:18 karolherbst: pmoreau: in fact there shouldn't be any bugs within the reclocking process itself anymore
11:18 karolherbst: well
11:18 karolherbst: there might be some issue left, but generally it should work
11:19 pmoreau: Cool :-) I think I tried your branch while you were working on it, and it was indeed working. But since I didn’t needed the reclocking, I reverted to using the stock kernel
11:19 karolherbst: yeah, most likely
11:19 karolherbst: well I will update to 4.6 when I get nvidia running on 4.6
14:33 Tom^: nvidia runs on 4.6
14:33 Tom^: oh karol isnt here
15:02 user_45889: pmoreau: this is the full dmesg output: http://pastebin.com/raw/6UN8TtDU
15:04 pmoreau: user_45889: Thanks
15:06 pmoreau: Meh, I think I know why (or at least one possible reason)
15:06 pmoreau: It looks like the backlight code does no registration for Maxwell cards: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_backlight.c#L234
15:09 pmoreau: user_45889: You could try adding `case NV_DEVICE_INFO_V0_MAXWELL:` right after `case NV_DEVICE_INFO_V0_KEPLER:`, and see if that helps (you will need to compile Nouveau yourself)
15:11 user_45889: Ok. I will recompile and keep you posted
15:27 pmoreau: user_45889: I need to go, but I should be back in ~2 hours.
15:29 imirkin_: RSpliet: i assume the change is negligible/invisible. i just didn't like seeing that address in the main function's ins list.
15:30 imirkin_: RSpliet: i've gotta imagine it helps *some* times, but it should be very rare.
15:41 user_45889: pmoreau: recompiled the module and now I have /sys/class/nv_backlight
15:42 user_45889: Now I can take off my sunglasses because the backlight is functioning properly
15:43 imirkin_: send a patch :)
16:56 pmoreau: user_45889: Cool! :-)
17:00 user_45889: patch http://pastebin.com/raw/4RtqYUKm
17:33 user_45889: xbacklight reports no outputs have a backlight property
17:33 mjg59: Only Intel usually bother with that
17:33 user_45889: perheps something to do with this: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_backlight.c#L196
17:42 user_45889: After the patch i'm only able to change the backlight through /sys/class/backlight/nv_backlight/brightness
17:47 mjg59: user_45889: That sounds like everything's working, then
17:58 user_45889: mjg59: partially working and I'm not sure if it has anything to do with nouveau. Now I'm able to change the backlight through nv_backligh dir, but xbacklight still reports no outputs have a backlight property.
17:59 mjg59: user_45889: Yes, xbacklight only works on Intel
17:59 user_45889: uh, isee
18:00 user_45889: i think I had it working on the same machine when I had the proprietary diveres installed
18:00 mjg59: The nvidia drivers may well expose it
18:01 user_45889: then i will just map the keyboard keys to a script to modify the brightness file directly
19:02 pmoreau: user_45889: Do you want to send a patch to the ML?
20:37 FNTM-U3: I want to make a query on "BUG 84721".
20:37 FNTM-U3: would it be fixable?
20:37 imirkin_: yep
20:38 imirkin_: i believe mupuf was part-way to a solution
20:38 imirkin_: but afaik he hasn't worked on it in 6 months or so
23:10 tajjada: i want to try to use nouveau with the blob firmware, but i haven't really done this before. I found the instructions on how to do a mmiotrace and extract the firmware from the blob.
23:10 tajjada: but is there anything special i have to do in terms of options or configuration for nouveau
23:10 tajjada: to tell it to load the blob firmware rather than its own?
23:10 tajjada: or will it just autodetect it if i install it in the right path?
23:10 imirkin: nouveau.config=NvGrUseFW=1
23:10 tajjada: imirkin: thank you
23:11 imirkin: however chances are this is not what you want
23:11 tajjada: i want to test things
23:11 tajjada: because i get random freezes
23:11 tajjada: with nouveau
23:11 imirkin: also you can use a script to extract firmware for fermi/kepler gpu's
23:11 tajjada: and i found a bug report where people said that apparently it is firmware-related and goes away when using the blob's firmware
23:11 imirkin: "it"?
23:12 imirkin: anyways, feel free to try whatever
23:12 tajjada: it is not about my specific card, but i have similar symptoms as in this bug report https://bugs.freedesktop.org/show_bug.cgi?id=93629
23:13 tajjada: i just wanted to give it a try and see what happens
23:13 tajjada: you mentioned a "script" / better way to extract firmware than a mmiotrace?
23:14 imirkin: https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware
23:14 imirkin: it talks about video accel
23:14 imirkin: but if you follow the instructions to the letter
23:14 imirkin: then you'll also end up with pgraph firmware
23:15 tajjada: ok, i only care about the pgraph one
23:15 tajjada: thanks
23:16 tajjada: i sorta ignored that wiki page because i thought it was just for video accel
23:36 tajjada: imirkin_: apparently, i need to rename the pgraph firmware files, because nouveau now uses some new paths, correct?
23:36 imirkin: that's right
23:36 imirkin: starting with version ... not sure which version
23:37 imirkin: i believe i mention what the mapping between old name and new name is in some bug
23:37 imirkin: i can never remember which one is fecs and which one is gpccs
23:38 tajjada: yeah, i am not sure which file to rename to what ... it would be nice if you (or someone) could tell me
23:39 tajjada: my gpu is GK208B (saw in dmesg), or NV106 in nouveau terminology (saw in glxinfo)
23:42 imirkin: ah... i think there's been very little testing on such GPUs
23:43 tajjada: imirkin_: i still want to give it a try ... i am prepared for things to go wrong
23:44 tajjada: these are the files for my gpu (judging by the file name) as extracted from your script:
23:44 tajjada: nv106_fuc084 -> nve0_bsp
23:44 tajjada: nv106_fuc085 -> nve0_vp
23:44 tajjada: and nv106_fuc086 -> nvc0_ppp
23:44 tajjada: if only i knew which one to rename to what ...
23:45 imirkin: those are the video files
23:45 tajjada: well, that's what your script gave me
23:45 imirkin: you're looking for nv106_fuc41a[cd] and fuc409[cd]
23:46 imirkin: yeah, i don't remember if i even extract GK208 firmware from that 325.15 archive
23:46 tajjada: oh ... so if i am really keen on trying the firmware ... i have to do a mmiotrace then?
23:46 Leftmost: Is there documentation of the output format of demmt/the ISA used?
23:47 imirkin: Leftmost: you mean SM50?
23:47 imirkin: Leftmost: not really. you can glean some ideas from PTX ISA docs, but those are docs for a fake isa
23:48 imirkin: the names you see tend to be the ones used by nvdisasm... so it's a reasonable assumption that FADD is a floating point add :)
23:49 tajjada: imirkin: ok, sorry for bothering you with my silly firmware stuff ... i'll figure it out; thank you for the info you gave me
23:49 imirkin: tajjada: yeah, you might have to grab it from mmiotrace :(
23:50 tajjada: imirkin: i'll do that; i am just really curious to see how nouveau will behave with blob firmware
23:50 tajjada: on my card
23:50 Leftmost: Yeah, figured. Just wasn't sure of all of the behaviors of things like, say, vmad. Not that I think it's hugely relevant to what I'm working on, but I was curious.
23:50 imirkin: Leftmost: so for those, you should look at the PTX ISA docs
23:50 imirkin: vmad is a "vector" multiply-add
23:51 imirkin: except they call it "video"
23:51 imirkin: it can address u8's and u16's inside of the 32-bit registers
23:51 Leftmost: Ahh.
23:51 imirkin: envydis might not decode those 100% right btw
23:51 imirkin: when in doubt, try it with nvdisasm
23:52 imirkin: you might find the handlePFETCH in gm107 lowering instructive