03:11antonanotna: I have been looking around, and cannot figure out how to tell if nouveau has attempted to load firmware for videoacceleration; would this show up in dmesg output, elsewhere, or not at all?
03:51imirkin: antonanotna: hmmm ... i don't think it prints anything on success
03:51imirkin: antonanotna: are you trying to figure something concrete out?
03:54antonanotna: I added the extracted firmware files to /lib/firmware/nouveau/, restarted, and tested with mplayer and vdpauinfo
03:55imirkin: what gpu do you have?
03:55antonanotna: vdpauinfo sounds like it was intended for the proprietary driver, so I am not too concerned when it reports:
03:55antonanotna: Failed to open VDPAU backend libvdpau_nvidia.so
03:56imirkin: no, that's bad
03:56imirkin: it should have figured out that it should use nouveau
03:56imirkin: you can try VDPAU_DRIVER=nouveau
03:56imirkin: and are you using xf86-video-nouveau or modesetting?
03:57antonanotna: nvaf according to the codenames
03:59antonanotna: wayland uses modesetting, right? most of the dmesg lines say nouveau <address> DRM: <something>
03:59imirkin: oh this is with wayland?
03:59imirkin: i don't think vdpau has been super-tested with wayland
03:59imirkin: try setting VDPAU_DRIVER=nouveau though
03:59imirkin: i.e. VDPAU_DRIVER=nouveau vdpauinfo
04:00antonanotna: same error with that
04:00imirkin: ultimately it's just DRI... just missing the dri driver name hint
04:00imirkin: that's bad.
04:00antonanotna: full three lines are:
04:00antonanotna: display: :0 screen: 0 Failed to open VDPAU backend libvdpau_nouveau.so: cannot open shared object file: No such file or directory Error creating VDPAU device: 1
04:00antonanotna: crud. let me reformat that
04:00imirkin: do you have a libvdpau_nouveau.so somewhere?
04:01antonanotna: display: :0 screen: 0
04:01antonanotna: Failed to open VDPAU backend libvdpau_nouveau.so: cannot open shared object file: No such file or directory
04:01antonanotna: Error creating VDPAU device: 1
04:02antonanotna: I don't think so, all I did was move the fw files to the directory
04:03imirkin: well ... you need it
04:03imirkin: otherwise no vdpau
04:03antonanotna: unless fedora has libvdpau_nouveau.so without adding a package
04:03imirkin: (presumably your goal is to get vdpau going)
04:03imirkin: oh, also there's a va-api backend, although i've never played with it myself
04:06antonanotna: libvdpau libva-vdpau-driver libvdpau-va-gl mesa-vdpau-drivers sound like the best candidates in the repos
04:07imirkin:doesn't know anything about binary distros
04:08antonanotna:is definitely a scrub
04:09antonanotna: I will gentoo someday, but not today
04:17antonanotna: well sounds like mesa-vdpau-drivers might have it, I'll be back in a restart
04:47antonanotna: well, I have libvdpau_nouveau.so.1.0.0, but I still get an error from vdpauinfo saying it can't find it
04:48antonanotna: how do you check if mesa was compiled with the vdpau state tracker enabled?
05:34imirkin: the output is libvdpau_nouveau.so
05:36imirkin: perhaps XWayland only works with DRI3 and you have an older version of mesa? dunno
05:36imirkin: you might be able to get more useful info in a wayland-related chan
05:36imirkin: i'm just not that familiar with it
05:37imirkin: i figure it's something i'll need to investigate in the 5-10 year horizon...
11:10karolherbst: I want to rework this patch https://github.com/karolherbst/nouveau/commit/5f269cdab3dd89c6e5f8a79c012b8322a1f1af35
11:10karolherbst: my current issue is: I want to rework the counter configuration to be chip specific
11:10karolherbst: and currently thinking about what would be a proper design
11:11karolherbst: just add a struct to the nvkm_pmu_func thing and be done with it?
11:11karolherbst: but this may lead to some duplicate stuff...
11:11karolherbst: but having methods is also kind of ugly
11:13karolherbst: but I also want to split up that gt215_setup_pmu_counters method seperating the information how the slots are configured and how the slots are set (to prepare for signed firmware PMU)
11:14karolherbst: ohh, I have an idea: nvkm_pmu_counters_setup, which is calling into nvkm_pmu_counters_set_slot, which can be implemented
11:38pmoreau: karolherbst: BTW, I haven’t forgotten about your series (yet); I’ll try to finish reviewing and testing it over the weekend.
12:03antonanotna:belatedly thanks imirkin for his/her help
12:11karolherbst: pmoreau: do you have some time in like two weeks?
12:34pmoreau: karolherbst: 2 weeks? That would be the last two weeks before the conference deadline, so not really. Free time will go towards having some sleep every day.
12:43karolherbst: pmoreau: okay, so next month?
12:43karolherbst: pmoreau: I am more refering to the compute stuff though
12:44karolherbst: not to the reviews
12:44pmoreau: That’s what I guessed :-)
12:45karolherbst: okay :)
12:45pmoreau: Past the 1st Dec., I’ll have time, definitely. I mean, we can still talk a bit before that: I won’t be completely off the grid either. :-D
12:46Aristar: (==) NOUVEAU(0): DPI set to (96, 96) <---- is this a hardcoded value or something? doesn't seem to take Option DPI or Option UseEdidDpi and short of manually setting the entire monitors modelines, DisplaySize and DPI didn't work either under Monitor
12:47Aristar: (yeah i read what manuals i could find, not sure why it's ignoring my displaysize or dpi values, and nouveau is also setting the displaysize to a different value, which this panel needs a quirk, though no one would care due to it being so old)
12:49pmoreau: Aristar: No clue; might want to have a look at the code.
12:49Aristar: yeah i figured i'd have to get my hands dirty
12:49Aristar: need coffee... 8am ugh
12:49pmoreau: Maybe imirkin knows, but he might not be awake yet and/or behind his computer.
12:50Aristar: from what i understand the xserver should compute the dpi based on the monitor size however monitor size is passed along from the drm driver i believe, in this case nouveau. but nouveau is also setting 96dpi before it even sets monitor size (in mm)
12:51Aristar: technically 108 is accurate for mine which nv binary drivers were doing
12:51Aristar: and using xsettings/xft isn't a solution since that's just font scaling
12:52Aristar: i'll dig around some more once i wake up some
12:54Aristar: (WW) NOUVEAU(0): Output LVDS-1: Strange aspect ratio (304/19000), consider adding a quirk
12:54Aristar: yeah it's reading the EDID wrong or the EDID is in some weird format, idk. it's technically like 304x190
12:55Aristar: (old LVDS panel)
12:57Aristar: also question if anyone knows, according to GLX_MESA_query_renderer Max core profile is 3.3 and Max compat profile is 3.0, does this mean 3.1 doesn't work? I was trying to OGL3.1 stuff yesterday which was falling back to xrender and such
12:59Aristar: (only 3.3 and 3.0 profiles are listed also though i assumed they were backwards compatible since OGL2.0 seems to work)
13:01pmoreau: Aristar: Not sure about your other questions, but regarding 3.1, what is returned is the *Max* core profile, so if 3.3 is supported, 3.1 should be as well.
13:02pmoreau: Not sure why it would have fall back to xrender when you tried it yesterday.
13:04Aristar: seemingly ignores this
13:07Aristar: no Screen section configured just Monitor, perhaps i need to try that instead of just Section "Monitor"
13:08Aristar: wish i'd dumped everything nv binary was setting before completely removing (hunted down stray files and yes i confirmed it was completely gone by comparing snapshots)
13:09Aristar: ..which snapshot is gone due to needing space for debug symbol packages >_>
13:15Aristar: also, no documented "debug" parameter as far as i can tell in nouveau module, and sysfs is readonly for that. kernel config shows CONFIG_NOUVEAU_DEBUG=5 and CONFIG_NOUVEAU_DEBUG_DEFAULT=3
13:15Aristar: perhaps that needs to be set on boot to a number
13:16Aristar: ...also unsure if drm ftrace would capture anything interesting when nouveau goes kaboom
13:17Aristar: only one way to find out i suppose. open ALL THE BROWSERS
13:28pmoreau: Aristar: There is a documented “debug” parameter for the Nouveau kernel module: https://nouveau.freedesktop.org/wiki/KernelModuleParameters/ For example, you can do “nouveau.debug="PDISP=debug,I2C=paranoia"”
13:28Aristar: Oh, thanks! must have missed that
13:29Aristar: lot of the docs there are old but i understand it's more important to work on code than docs most of the time
13:46Aristar: bleh, envytools needs to be compiled against current kernel? hrrm
13:48Aristar: 4.13.11 pushed to repos today anyhow, might as well try some of the envytools to get some more info
13:57karolherbst: is somebody with a pascal GPU here and wants to check something for me?
14:08pmoreau: karolherbst: Depends :-) What do you want?
14:08pmoreau: Should be good then
14:08pmoreau: On the blob?
14:08karolherbst: nvapeek 10a500 0x80
14:09pmoreau: karolherbst: https://hastebin.com/urihiwoqan.pl
14:10karolherbst: which pascal is that?
14:11pmoreau: (the NVIDIA Titan X: not the NVIDIA Titan Xp, nor the GeForce Titan X)
14:12karolherbst: I hoped that the new PCOPY engines would appear there somehow
14:12karolherbst: but no
14:13karolherbst: just 0-2
14:13karolherbst: there aren't more slots, are there? I mean nvapeek 10a580 0x10 is empty, isn't it?
14:14pmoreau: It is empty indeed
14:15karolherbst: now I am still wondering about gp108 because that one shouldn't have NVENC at all... not sure why, but I've read about it (tm)
14:16pmoreau: Get work to buy one? Or maybe Ben has one you could use?
14:26imirkin: Aristar: actually with recent kernels, the names of the engines have changed. but you can just do like nouveau.debug=debug to get it for all engines
14:26imirkin: (recent = 4.3)
14:27Aristar: also curious if drm.edid_fixup tunable might make nouveau detect panel size correctly
14:27imirkin: lets check where DPI comes from...
14:27Aristar: seems it's adding two extra zeros to it
14:28Aristar: or 3
14:28imirkin: not-from-nouveau is where it comes from
14:28imirkin: nothing in xf86-video-nouveau sets it one way or the other
14:40imirkin: my point is - it's all inside the generic portions of X
14:41imirkin: grep around for 'Dpi' to find it
14:41imirkin: my guess is it comes from EDID
14:41Aristar: yeah, though none of my edid or monitorsize options seemed to do anything, but thanks. i'll dig around in a little bit
14:42Aristar: (or option dpi)
14:42Aristar: must need a fully configured screen section
14:42imirkin: not sure offhand, sorry
14:42Aristar: np thanks for checking, appreciate it
14:43Aristar: Xorg.0.log flagged nouveau as setting the DPI and monitor physical size (in mm) so i figured it was something with nouveau
14:43imirkin: well, nouveau calls: xf86SetDpi(pScrn, 0, 0);
14:44Aristar: yet nouveau has no device option to override dpi or edid
14:46Aristar: gonna need to iron tihs stuff out if i switch permanently to nouveau which seem inevitable due to nvidia dropping support next year and also 340 series being buggy (though at least has extensive exception traps which doesn't crash the entire kernel)
14:47imirkin: Aristar: which gpu are you on?
14:47Aristar: like when a browser eats the gpu, binary driver is like... segfault, then browser falls back to non-gpu accel
14:47Aristar: G86 (8400m GS/128MB/DDR2)
14:47imirkin: well, you should realize that nouveau isn't exactly a beacon of perfection either
14:47Aristar: it's not a mxm either even though mxm modules are loaded, it's soldered onto the motherboard
14:48Aristar: i do understand that and i may contribute if no one else is doing much for legacy support
14:48Aristar: have quite a few old laptops i'd like to repurpose or give to charity
14:49imirkin: ok. just don't be surprised if you see hangs/etc esp if you start stressing it
14:49Aristar: particularly these older dell vostros, first gen i believe
14:49Aristar: back when nvidia had the lead-free soldering issue
14:49Aristar: lot of them ended up refurbished and such
14:51Aristar: mine never had an issue, only some did. but dell's stupid bios update ramped up the fans which can't be undone, and i8kfan gets overridden every 5 seconds unless manufacturer debug mode is used on the laptop
14:51imirkin: iirc a bunch of those also have disabled video decoding
14:51Aristar: stupid crap
14:51imirkin: (mobile G86's specifically)
14:51Aristar: yeah it's odd, they have a ghosted TV-1
14:51imirkin: iirc "NVS 140M"
14:51Aristar: and duplicate video
14:51Aristar: maybe due to vga port too
14:52imirkin: sometimes there's a dock
14:52Aristar: and like a hardware button to physically mirror screens to the vga
14:52Aristar: well, fn+f8
14:52Aristar: though gnome/kde seem to respond to it, or any key monitoring sort of daemon
14:52imirkin: hopefully that's just an ACPI call...
14:53imirkin: er, event
14:53Aristar: yeah mostly though doesn't work with nouveau, flickers screen. works on nvidia though
14:53Aristar: not entirely sure which it is
14:54Aristar: seems more hardware-ish, these have old smbios 2.4 with quirks
14:54Aristar: and the vga gart is only 32bit addressable
14:54Aristar: or w/e it is
14:55imirkin: that's common.
14:55Aristar: same with the expresscard slot if a external gpu is used
14:56Aristar: hmm, idk. my desktop rig can get fully addressable 12GB VRAM
14:56Aristar: though needs a bios option flipped on
14:56Aristar: i.e. not remapped and such
14:57imirkin: most bios's try to conserve precious 32-bit space
14:57Aristar: though these laptops did sihp with 32bit winvista so i guess moreso designed for 32bit. bios doesn't even support more than 4GB ram installed
14:58Aristar: 965 chipset and ICH8M
14:58Aristar: but dell does some weird stuff
14:59Aristar: though oddly the iTCO_wdt works
15:01Aristar: yeah i tihnk if tihs was configured with intel rather than nvidia it would be on the i810 driver which is awful
15:03imirkin: 965 = i915 drm driver
15:04imirkin: and a DX10-capable GPU
15:04imirkin: [with a LOT of workarounds]
15:06Aristar: hmm, would have been GM965 chipset if intel
15:08Aristar: either way, anything pre-sandybridge intel GPUs pretty much are bollocks
15:09Aristar: even one of my other ones with first gen intel HD gpu (the weird nehalem refresh based on westmere, before sandy)
15:10Aristar: ...did i use that term right? maybe i should just use "balls" :P
15:10Aristar: too much gaming with brits lately
15:16imirkin: GM965 was DX10-capable, believe it or not
15:17imirkin: but missing a few tiny little features... like MSAA
15:17imirkin: and i think TF was basically fubar on there
15:17Aristar: interesting, though "capable" is far from working or usable :P
15:17Aristar: and DX10 was kinda BS anyways
15:17imirkin: well - had DX10 drivers :)
15:17Aristar: should not have existed
15:18Aristar: originally DX10 was intended to be like vulkan
15:18imirkin: compared to DX9, it was.
15:18Aristar: but they thought it would be too complicated
15:18Aristar: so they neutered it a ton
15:18Aristar: i forget the story, maybe some devs were also concerned
15:19Aristar: vista was the largest change in windows since like the change to winNT so naturally it had a ton of bugs, but didn't help they threw in like ALL the stuff they wanted to test
15:20Aristar: kitchen sinks not withstanding
17:19karolherbst: I hope this makes the clk subdev code a bit easier to read: https://github.com/karolherbst/nouveau/commit/51eaee9bcab8e71427720e9e2b8af7449aa3af84
17:22imirkin_: karolherbst: you've got a rebase gone wrong
17:22karolherbst: not just one
17:22imirkin_: ok, well as long as you're aware of the situation :)
17:23karolherbst: but this commit should be fine?
17:23jolar2: karolherbst: new interesting info... if I switch to discrete graphics in BIOS I can use all three monitors with nouveau... but...
17:23karolherbst: imirkin_: yeah, currently cleaning up all that stuff
17:24imirkin_: karolherbst: i'm not sufficiently familiar to review
17:24karolherbst: and I even found mistakes I did after I renamed all that stuff
17:24jolar2: ... the default setup is then that the laptop screen is mirrored with one of the external monitors
17:24imirkin_: jolar2: that's up to your DE
17:24imirkin_: jolar2: you can probably achieve the same effect by making nvidia your primary in xorg config
17:24jolar2: and when trying to disable the laptop screen, everything goes black and then reverts to the original status
17:25jolar2: the nvidia driver is extremely unstable
17:25karolherbst: most likely not, because Nvidia always go with their crappy xorg.conf file
17:25imirkin_: i meant nvidia gpu
17:25karolherbst: but then there is no internal display
17:25karolherbst: allthough reverse prime von intel onto nouveau sounds fun
17:25imirkin_: why not?
17:25jolar2: I also get this INIT_GENERIC_CONDITON: unknown 0x07
17:26imirkin_: that's what i mean... reverse prime the intel
17:26imirkin_: jolar2: don't worry about that
17:26karolherbst: imirkin_: do you know something about it?
17:26imirkin_: iirc skeggsb looked into it
17:26karolherbst: I see
17:26imirkin_: didn't matter enough to really worry about it, according to him
17:26karolherbst: I doubt it is critical, but meh
17:27jolar2: well I am back to square one
17:27jolar2: I don't understand how it can work with the P50 though... it is so similar
17:28karolherbst: imirkin_: anyway, we kind of plan to get my clock patches merged for the next release... or at least I hope we will make it until then
17:28karolherbst: then finally no crappy prime system messups
17:28jolar2: since not nvidia, nor nouveau works properly with this dockign station setup, I am more and more inclined to believe it's Lenovo's fault altogether...
17:28karolherbst: who knows
17:28karolherbst: but most likely
17:29imirkin_: jolar2: can you describe *one* problem you're having?
17:30jolar2: imirkin_: Right: If we forget about docking stations, everything works fine.
17:30jolar2: imirkin_: with a docking station + external display connected to the docking station (and not the laptop), I get a kernel oops with nouveau
17:31imirkin_: did you file a bug about that?
17:31imirkin_: and does it happen on the latest kernels?
17:31jolar2: imirkin_: with the nvidia driver, I enter an unstable state where it cannot seem to decide which resolution is proper and then crashes X
17:31jolar2: imirkin_: yes
17:31jolar2: imirkin_: yes
17:31imirkin_: bug link?
17:31jolar2: imirkin_: or rather, I hijacked a bug
17:31imirkin_: bug link :p
17:32imirkin_: the thing with the new connector being registered and messing up
17:33jolar2: to sort things out properly, the problem with the nouveau driver is with hybdrid graphics set in bios, and the problem with nvidia is with discrete graphics in bios
17:33jolar2: with discrete graphics in bios, the nouveau driver can use the external displays of the docking station
17:33jolar2: imirkin_: yes
17:34imirkin_: ok, well we're not interested in sorting out any issues with the blob driver
17:34imirkin_: feel free to report that to /dev/null, er, i mean, their forums
17:34jolar2: I have filed a separate bug report @ nvidia
17:34jolar2: they stopped answering when I gave them debug information
17:34jolar2: I have not contacted lenovo yet though
17:39jolar2: this is perhaps interesting
17:39jolar2: "DisplayPort and Display on Dock share a single display output."
17:39jolar2: it is possible to select the priority in BIOS
17:40jolar2: between displayport and display on dock
17:44jolar2: hmm, seems to be the same for P50 so that is probably not it...
17:44imirkin_: that's the MST bit of it
17:45karolherbst: jolar2: I am sure I have the same dock
17:45jolar2: karolherbst: 40A5
17:45jolar2: currently display on dock is prioritized
17:45karolherbst: jolar2: exactly
17:45jolar2: I could switch that in BIOS though, but I doubt it will make any difference
17:46karolherbst: are you using the DP output directly on your laptop?
17:46jolar2: karolherbst: I never tried that (it is a mini-DP connector)
17:46karolherbst: then it won't make a difference I guess
17:46jolar2: karolherbst: I only tried HDMI on the laptop which works, while HDMI on the docking station causes the oops.
17:46karolherbst: I tried both
17:46karolherbst: it worked
17:47karolherbst: ohh right, I wanted to test an older kernel
17:47jolar2: well I did try 4.14-rd7
17:47karolherbst: I tried nouveau master
17:48jolar2: karolherbst: oh yeah, I messed things up in my head
17:48jolar2: karolherbst: I kept thinking nouveau master == linux master...
17:48karolherbst: anyhow, I am too tired now to do any serious work....
17:48jolar2: karolherbst: I diffed v4.14-rc7 vs linux master and concluded there were no diffs :D
17:49jolar2: karolherbst: Ok. I think it will work for you anyway... should have seen more P50 complaints otherwise I think
17:49jolar2: karolherbst: but I'll see if there is something interesting to grab from nouveau master
20:46tobijk: meh, against which version is skeggsb's nouveau repo right now? -rc8 is not the right one :/
20:49tobijk: ups, right
20:49pmoreau: tobijk: I think “drm-next 7a88cbd8d65d622c00bd76ba4ae1d893b292c91c”, https://github.com/skeggsb/nouveau/commit/71e57605dc05a1ae947142f8f2639bc64a4eeed8 is the newest commit mentioning drm-next/drm-fixes/v4.x-rcy
20:49tobijk: skeggsb: thanks
20:50tobijk: pmoreau: yeah right, i must be blind
21:21pmoreau: The GM107+ does not support emitting MADSP. Does anyone know whether it has not been RE’ed yet, or it is missing on GM107+?
21:22imirkin_: MADSP was just used for image stuff on kepler, right?
21:22imirkin_: GM107 has an XMAD which i think is related
21:22imirkin_: https://github.com/envytools/envytools/blob/master/envydis/gm107.c - has madsp
21:23imirkin_: so it shouldn't be difficult to add... but why do you need it?
21:23pmoreau: I have been using it to implement mad24 from OpenCL, dunno if it has been used for images as well.
21:23imirkin_: are you trying to add MS image read/write support?
21:23imirkin_: ah ok
21:24imirkin_: pmoreau: btw, in case you feel like it, figuring out wtf XMAD does (precisely) would be awesome
21:24imirkin_: it's a new op on maxwell
21:24imirkin_: it's a faster IMAD, but clearly there are some limitations
21:25pmoreau: OK, will put that on the to-do list.
21:27pmoreau: There seems to have been other people looking at that XMAD: https://devtalk.nvidia.com/default/topic/980740/xmad-meaning/
21:28imirkin_: oh nice
21:29imirkin_: is there a version that's just a*b+c?
21:29pmoreau: Dunno, haven’t read the whole thing
21:30imirkin_: anyways, should be a good start for investigation
21:58pmoreau: Is it me being to tired, or was someone else too tired when they modified “CodeEmitterGM107::emitIAD()”, which checks for FILE_IMMEDIATE right after having made sure it was different from FILE_IMMEDIATE? https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp#n1734
21:58pmoreau: s/to tired/too tired
21:59imirkin_: the other form is valid too
21:59imirkin_: with a short imm
21:59imirkin_: but we decided to just always use IADD32I with imms
22:00imirkin_: since it's a pain otherwise
22:00imirkin_: feel free to remove it there and IMUL
22:00tobijk: pmoreau: yeah well, just in case the processor is lazy today :)
22:01pmoreau: I guess the short imm does not have any benefits over the 32-bit one
22:01imirkin_: maybe extra flags? dunno
22:01imirkin_: the imm situation got confused
22:02imirkin_: and someone tried to "fix" it without properly understanding
22:02imirkin_: the end solution was to continue to not properly understand and just do the thing we know will work
22:09pmoreau: I’m not super happy about that modification to the emitIMMD function, but that’s the best I came up with. :-/ https://hastebin.com/jinosipezi.cpp
22:10pmoreau: (But at least it works; would need some more testing for sure.)
22:16tobijk: pmoreau: looks ok to me, just one thing: is the "applyNeg" thing common there? i havent looked into it and cant remember...
22:17pmoreau: tobijk: No idea: I added it because I needed it for emitIADD, it’s quite possible it would be it’s only user.
22:26tobijk: pmoreau: *new helper method for insn* ;-)
22:28imirkin_: pmoreau: well you def don't want to be modifying the storage.
22:28imirkin_: oh. but it's a copy. why not just do like
22:28imirkin_: val = -imm->reg.data.s32 ?
22:29imirkin_: pmoreau: i hate it because IMMD isn't just for s32
22:29imirkin_: pmoreau: tbh i'd rather we just got rid of OP_SUB