02:41 RSpliet: imirkin_: sorry, wasn't awake
02:42 RSpliet: judging by the state of mesa upstream, you aren't waiting for any more feedback? :-) no, looks good; nice find
02:52 mupuf: karol is going to be very happy that the GM206 has its power usage exposed by the blob
02:52 mupuf: I made a trace and added the bios to the vbios repo
02:53 mupuf: I guess I will buy it soon-ish to be able to experiment
02:53 mupuf: that will be a better use of my time than trying to find the power usage in the RAM of pdaemon
02:56 RSpliet: tagr: What is the best communication channel for anything "NVIDIA proprietary" Tegra Linux related? contacting Terje directly sounds a bit rude, but are there public communication channels I can poll?
02:57 RSpliet: (gnurou: if you happen to know what I should do with feedback on that end, please let me know :-))
03:59 Walther: http://walther.guru/temp/xrandr.txt Hmm. On nouveau driver + intel, xrandr still thinks the nvidia card is Name:nomodesetting. Xrandr also thinks all my displays are *disconnected*, even if I have picture on my main display. This causes e.g. i3bar not to show up, because it thinks all outputs are disabled.
04:00 Walther: multimonitor would be a plus, but is not my current goal - my current goal is to get even one monitor *reliably* working and properly detected by xrandr and such :)
04:00 Walther: http://walther.guru/temp/Xorg.0.log.txt for the xorg log
04:12 pmoreau: Walther: [ 3.894] (EE) Unknown chipset: NV124
04:12 pmoreau: Could you upload your dmesg as well please?
04:13 Walther: pmoreau: I'm running Nvidia GTX970
04:14 Walther: http://walther.guru/temp/dmesg.txt
04:16 pmoreau: One thing: the NVIDIA driver is still trying to load, you should blacklist it (or remove it)
04:16 pmoreau: And you get:
04:16 pmoreau: [ 1.688881] nouveau E[ PFIFO][0000:01:00.0] unsupported engines 0x00000001
04:16 pmoreau: [ 1.688955] nouveau E[ DRM] failed to create kernel channel, -22
04:16 pmoreau: Maybe it's expected due to not having signed firmware?
04:17 Walther: hm, i've removed the nvidia driver because i couldn't get it working, I shouldn't have the modules anymore
04:17 pmoreau: Well, look at the end of the dmesg you just uploaded :-)
04:17 Walther: yeah, I did notice :)
04:18 Walther: pfft, nvidia-driver pulls nvidia-kernel-dkms etc as dependencies, but those don't get uninstalled if one uninstalls nvidia-driver - nor do they get flagged for autoremove-ability
04:18 pmoreau: Oh, you should remove xf86-video-nouveau and let the modesetting do the work
04:19 Walther: yeah, I'll remove the leftover nvidia things
04:23 Walther: purged nvidia-*, made sure xserver-xorg-video-nouveau is installed, rebooted, refresh the xorg log page
04:33 Walther: Further ideas on debugging? :)
04:33 pmoreau: Walther: You misunderstood my last comment
04:33 Walther: oh you meant remove nouveau and use the proprietary driver?
04:33 pmoreau: Turned differently, make sure xserver-xorg-video-nouveau is removed so that is uses modesetting :-D
04:34 Walther: if you look at the new xorg.log, it resorts to modesetting anyway because apparently gtx970 is too new for this nouveau
04:36 Walther: if I understand things correctly, that is. Also, now xrandr reports http://walther.guru/temp/xrandr.txt
04:36 pmoreau: Not exactly: support for Maxwell cards (at least for 2nd gen) has been removed from the Nouveau DDX because GLAMOR is broken on those cards whereas it works with modesetting. And I think there is no plan to bring back that support
04:37 Walther: ah, nod. Where was the blacklist file again so I'll add nouveau there
04:38 Walther: found it, echo blacklist nouveau > /etc/modprobe.d/blacklist-nouveau.conf
04:38 pmoreau: Hum…
04:39 pmoreau: Nouveau DDX == xserver-xorg-video-nouveau
04:39 pmoreau: Nothing to do with the Nouveau part found in the kernel
04:40 pmoreau: So if you want to use the blob, sure, blacklist Nouveau, otherwise, you should avoid blacklisting it
04:43 Walther: okay, removing the blacklist. I also apt purged xserver-xorg-video-nouveau as you said
04:44 Walther: now I'm back at X, xrandr reports back exactly the same
04:44 Walther: Provider 0: id: 0x92 cap: 0x2, Sink Output crtcs: 4 outputs: 4 associated providers: 0 name:modesetting
04:45 pmoreau: Could you upload the new Xorg.log please?
04:45 pmoreau: So name: modesetting seems reasonnable
04:46 Walther: yeah, that was there already when I hadn't explicitly removed xserver-xorg-video-nouceau
04:47 Walther: http://walther.guru/temp/Xorg.0.log.txt
04:49 pmoreau: Dunno if "(EE) modeset(0): glamor initialization failed" might be one of the problem cause
04:51 pmoreau: But it does say " (II) modeset(0): Output DVI-0 connected" somewhat later
04:51 Walther: indeed, and it finds the correct modes and all
04:51 Walther: but xrandr magically says all displays disconnected
04:52 Walther: and trying to enable any display results in loss of even the last display
04:53 pmoreau: Right now you only have one display connected, right?
04:53 Walther: I have all three connected physically, only main display (nvidia + dvi) lights up
04:54 Walther: (and they all provably work physically, I have pretty triplemonitor under windows)
04:54 Walther: anyway, multimonitor with nouveau + intel is probably a stretch, my first priority is to get at least one display properly detected and working
04:55 pmoreau: I had missed that DVI-0 is duplicated
04:55 Walther: xrandr reporting everything disconnected has weird side-effects, including i3bar status bar not showing up because it skips all outputs that xrandr reports as disconnected
04:55 pmoreau: With one of them getting a valid EDID, and the other one nothing
04:55 Walther: hah, it might be that there's dvi-0 of nvidia and dvi-0 of the motherboard/intel
04:56 pmoreau: Intel doesn't seem to have a DVI-0
04:57 pmoreau: Only VGA1, HDMI1, HDMI2, DP1, HDMI3, VIRTUAL1
04:58 Walther: the nvidia dvi-0 is connected via "dual link" cable because 144hz monitor (silly me plays games on windows side occasionally), but that probably shouldn't duplicate the entire port
04:58 Walther: probably unrelated
04:59 pmoreau: Right, but you end up with:
04:59 pmoreau: [ 4.164] (II) modeset(0): Output DVI-0 connected
04:59 pmoreau: [ 4.164] (II) modeset(0): Output DVI-0 disconnected
05:00 Walther: yet right after that it says:
05:00 Walther: [ 4.164] (II) modeset(0): Output DVI-0 using initial mode 1920x1080
05:00 Walther: :|
05:00 Walther: curious behavior
05:00 pmoreau: Why does it display modes for the DisplayPort-1 and not for DVI-0?
05:01 Walther: and I have nothing connected via DP
05:02 pmoreau: imirkin: -^ Help needed if you are around :-)
05:17 RSpliet: Walther: for dual-link display you need a kernel with, amongst some other patches, this: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=9a5157e12f64e582de6dd46a0f6908c1dd2a3dba
05:17 RSpliet: and this: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=edfb818155d35ada2eac0a79cc171b14a830630f
05:17 Walther: RSpliet: need as in required for functioning even in non-duallink modes?
05:18 Walther: or need as in only if I actually want to have 144hz support under linux as well
05:18 RSpliet: well, linux reads out the refresh rate from the EDID. and is likely to try and run it in a 144MHz refresh rate
05:19 RSpliet: I'll admit I only skimmed through the IRC log, but be advised that dual-link monitors could be problematic
05:20 Walther: sure.
05:20 Walther: Core problem is that xrandr thinks all my displays are disconnected
05:21 Walther: resulting in weird problems - if I try to enable further monitors with xrandr, i lose even my main monitor. If I try to enable the main monitor, I lose it.
05:21 Walther: and some software rely on xrandr information, like i3bar -> i get no statusbar on my desktop
05:22 Walther: getting all my monitors working under linux would be great, but my initial goal and priority #1 is to get at least my main display properly detected
05:26 Walther: Also that above patch seems to be for Fermi and Kepler, I'm running Maxwell. And the latter patch is for fixing HDMI, my only dual-link display is connected via dvi
05:27 RSpliet: the first patch does check for "newer than kepler", so should apply to Maxwell
05:27 RSpliet: or...
05:28 RSpliet: well, yes
05:31 Walther: either way, I dont' require duallink support on linux side
05:31 Walther: under linux side i do all the productive stuff i.e. programming and such, no need for 144hz :)
05:34 mupuf: karolherbst: hey, maxwell2 exposes the power usage using nvidia-smi!
05:37 karolherbst: :O
05:37 karolherbst: nice
05:38 karolherbst: mupuf: like for all cards or only a few choosen ones?
05:39 karolherbst: mupuf: but seems to be awesome to RE those power rails I suppose :D
05:39 mupuf: well, either it is the new version of the blob that exposes that (I doubt it) or it is on maxwell2 cards
05:39 mupuf: yes, exactly
05:39 mupuf: I added a mmiotrace + vbios in the vbios repo
05:40 mupuf: gm206/
05:41 mupuf: I will see if I get one tonight or in january, since I won't have time to work on it and the tk1 needs love
05:41 RSpliet: tk1 needs a lot of love
05:42 RSpliet: there's one purring on my desk, but NVIDIAs nvprof isn't playing nicely with nvgpu
05:45 Walther: http://walther.guru/temp/xrandr.txt On nouveau driver + intel, xrandr thinks all my displays are *disconnected*, even if I have picture on my main display. This causes e.g. i3bar not to show up, because it thinks all outputs are disabled. Multimonitor would be a plus, but is not priority - my current goal is to get even one monitor *reliably* working and properly detected by xrandr and such :)
05:47 RSpliet: Walther: also the dmesg I am staring at still has mentions of NVIDIA's proprietary KMS driver
05:47 RSpliet: plus errors like "[ 1.682830] nouveau E[ DRM] Pointer to flat panel table invalid"
05:48 RSpliet: (which, well... I don't know the result of that, but if it means it doesn't create connectors then all you have is the display initialised by your BIOS)
05:50 Walther: RSpliet: updated most recent dmesg, might've had old dmesg there, refresh
05:53 pmoreau: RSpliet: Any idea about that double DVI-0 in the Xorg.log?
05:53 RSpliet: pmoreau: not yet, I was looking at connector type 0x70
05:53 RSpliet: " 0x70 = Virtual connector for Wifi Display (WFD) "
05:53 pmoreau: Ok
05:53 Walther: intel WirelessDisplay
05:53 Walther: not using that, not necessary
05:54 Walther: http://www.intel.com/content/www/us/en/architecture-and-technology/intel-wireless-display.html
05:54 RSpliet: Walther: I know that
05:54 RSpliet: and I don't care that you don't need it, it causes nouveau to give warnings and errors, and it's a lead to analyse the nouveau error handling paths
05:56 RSpliet: also, your Xorg.0.log lists [ 3.909] (WW) Warning, couldn't open module nouveau
05:57 pmoreau: Right, Maxwell should use modesetting and not Nouveau
05:57 RSpliet: okay
05:57 pmoreau: Due to GLAMOR support being broken on Nouveau DDX
05:57 RSpliet: yeah, I did recall something like that
05:58 Walther: if you look at xrandr.txt, listproviders does show "name:modesetting" on Provider 0 (the nvidia card)
05:58 imirkin: oh dear... what's going on here...
05:58 RSpliet: yep
05:58 imirkin: let's clear a few things up
05:58 pmoreau: imirkin: Glad yo're here :-)
05:58 pmoreau: s/yo/you
05:58 imirkin: Walther: (a) no accel for your gpu. reasons don't matter, but even if you could use xf86-video-nouveau, it wouldn't help you. so using modesetting is the right thing
05:59 Walther: i'm fine with that, nod
05:59 imirkin: Walther: (b) that panel table error is not an issue
05:59 imirkin: Walther: lastly, what does nouveau think of your displays -- grep . /sys/class/drm/card*-*/status
06:00 Walther: http://walther.guru/temp/cardstatus.txt
06:00 imirkin: RSpliet: on the off chance you haven't had your fill of mad-related fun, it appears that the short encoding for imad isn't supported on nv50 :)
06:01 imirkin: Walther: and is that an accurate representation of reality?
06:01 RSpliet: heh, I'm beginning why they call that operation mad
06:01 RSpliet: +to understand
06:01 imirkin: RSpliet: i mean in nv50/ir -- there's an encoding in the hw but we're not using it
06:02 Walther: imirkin: main display on nvidia at DVI, one display on intel DVI and one display on intel hdmi with a dvi adapter
06:02 pmoreau: So the double DVI-0 is due to having a DVI-D-1 and a DVI-I-1 I guess
06:02 RSpliet: imirkin: envydis has an encoding but the code emitter doesn't?
06:02 imirkin: pmoreau: right, and that's fixed in more recent Xorg releases... in fact i sent a patch for precisely that issue
06:02 Walther: the nvidia card has two physical dvi ports, one D and one I
06:03 Walther: only the D is in use
06:03 pmoreau: imirkin: Awesome! :-)
06:03 imirkin: Walther: you need xorg 1.18 if you want both DVI-D-1 and DVI-I-1 plugged in on nvidia and using the modesetting driver
06:03 Walther: I have only one display plugged on nvidia card, on the DVI-D. The DVI-I port is empty
06:03 tagr: RSpliet: I guess it depends a little on the kind of feedback, can you be more specific?
06:04 RSpliet: tagr: sorry, had my question in #nvidia, but nobody there seems to actually be from NVIDIA :-P
06:04 imirkin: this is the commit: http://cgit.freedesktop.org/xorg/xserver/commit/?id=139e36dd5cbab80a9296129f3d25379dc01442b3
06:04 imirkin: Walther: ok, so what's the issue now?
06:04 tagr: RSpliet: try #tegra
06:04 RSpliet: long story short, I'm using nvprof to analyse performance of Cuda workloads, and it fills up my kernel log with [10780.163739] gk20a gk20a.0: gr_gk20a_ctx_patch_write: per-write ctx patch begin?
06:05 Walther: http://walther.guru/temp/xrandr.txt On nouveau driver + intel, xrandr thinks all my displays are *disconnected*, even if I have picture on my main display. This causes e.g. i3bar not to show up, because it thinks all outputs are disabled. Multimonitor would be a plus, but is not priority - my current goal is to get even one monitor *reliably* working and properly detected by xrandr and such :)
06:05 tagr: RSpliet: #tegra is kind of upstream-centric, but when you join you'll see an email in the topic that you can use for addressing questions related to L4T
06:05 RSpliet: tagr: thanks!
06:05 imirkin: Walther: ok, but from that grep it sounds like nouveau knows what's up, right?
06:05 imirkin: Walther: i.e. the status is reported as 'connected'
06:06 imirkin: ohhhh but you still have the problem of the two DVI ports mapping to 1 in modesetting
06:06 Walther: Nod, this might not be a nouveau issue but a xrandr issue :)
06:06 imirkin: so it's probably reporting on the wrong one
06:06 tagr: RSpliet: Nexton on #tegra is Arto Merilainen who might be able to help you out as well
06:06 Walther: Mmh.
06:06 imirkin: should fix itself if you either (a) update Xorg to 1.18 or (b) switch which DVI port you have plugged it into
06:07 imirkin: ftr, xrandr is just a passthrough of info supplied by X, so whatever it is, it's almost never an issue in xrandr :)
06:08 Walther: hm, newest version even in the experimental repos seems to be xserver-xorg 1:7.7+12
06:09 Walther: erm
06:09 towo^work: the package is xserver-xorg-core
06:09 Walther: yeah
06:09 Walther: upgrading :)
06:09 imirkin: not sure where 7.7 fits in on that numbering scheme
06:10 Walther: wrong package, that was xserver-xorg and not &-core like towo^work pointed out
06:10 imirkin: ah ok
06:10 Walther: hm, installing -core from experimental wants to remove xserver-xorg-input-all, -video-*, etc
06:10 towo^work: Walther, have fun with updatig, you will loose your input drivers
06:10 Walther: yeah, just noticed, that's not going to fly
06:11 imirkin: well, can't really help you with operating your distro
06:11 Walther: nod, that's not your issue to solve
06:11 imirkin: perhaps flipping DVI ports will be easier for now
06:13 imirkin: [assuming you can...]
06:15 Walther: Ha, that actually got me better xrandr output + the i3bar <3
06:16 Walther: and it does report 144 as a possibility for refresh rate, so I shouldn't lose my frames on windows side as well so i lost nothing
06:16 imirkin: yeah, we support dual-link dvi just fine
06:16 Walther: huge thanks! Any ideas why the DVI-D is causing problems but DVI-I isn't?
06:16 pmoreau: Ordering I guess
06:16 imirkin: that's not the issue
06:16 imirkin: the issue is that the modesetting ddx maps both connectors to the same X connector name
06:16 imirkin: so one of them happens to win
06:17 Walther: Ah. Should there be a bugreport or is that fixed in 1.18?
06:17 imirkin: that is fixed in 1.18, hence my suggestion to update to it
06:17 Walther: excellent, so everything is fine and dandy :)
06:17 imirkin: the fix is: http://cgit.freedesktop.org/xorg/xserver/commit/?id=139e36dd5cbab80a9296129f3d25379dc01442b3
06:17 Walther: now I got what I really wanted, and next I'll poke xrandr a bit and see if I can wake up the intel as well
06:18 imirkin: take a look at http://nouveau.freedesktop.org/wiki/Optimus/ -- you want output offloading
06:18 imirkin: "Using outputs on discrete GPU" -- except in this case, sounds like intel is your secondary gpu, so... flip all the instructions around
06:20 imirkin: you should, when possible, try to keep everything connected to a single gpu though. and in this case, using intel as primary might work out better
06:37 RSpliet: Walther: sorry btw if I was a bit unclear, I have a habit of thinking out very loudly
06:38 Walther: No worries :)
06:38 Walther: I have the same habit
06:39 RSpliet: (imirkin on the other hand has the habit of being right :-P)
06:46 Walther: imirkin: do you think that offloading should work now that I'm not running nouveau but modesetting?
06:46 Walther: the instructions seem to require "KMS drivers for both GPUs loaded.
06:49 Walther: see xrandr.txt
06:56 pmoreau: Walther: You are running Nouveau (the kernel driver) but you are using modesetting to get interaction between X and the kernel driver
06:57 Walther: https://bbs.archlinux.org/viewtopic.php?id=168427 this reflects my experiences
06:57 imirkin: Walther: should, but... things got fixed in Xorg 1.18, so perhaps didn't in 1.17? i've never personally tried it.
06:57 Walther: X Error of failed request: BadValue (integer parameter out of range for operation)
06:59 imirkin: something where you could only slave one screen sounds familiar... dunno when it was though
06:59 imirkin: unfortunately i have no concept of time, so it could have been a recent issue, or one solved a long time ago
06:59 Walther: hehe, no worries
07:00 Walther: I don't actually even require offloading, I would be fine with rendering one display on nvidia and two on intel, exactly as they're connected
07:04 imirkin: Walther: well, that's possible with xinerama. with PRIME, you end up offloading one way or the other...
07:04 Walther: iirc xinerama was obsolete?
07:04 Walther: I don't *mind* offloading either, I'm just wondering what is the easiest way to get this working under linux
07:04 imirkin: obsolete is a word used by people who come up with new technology that doesn't fully replace old technology but they want the old thing to disappear anyways
07:05 Walther: well, to rephrase my thought - wasn't xinerama considered legacy and unsupported and not recommended
07:05 imirkin: by plenty of people, sure. that doesn't stop it from working :)
07:06 imirkin: anyways, if you want to operate your setup optimally
07:06 imirkin: i'd recommend flipping things around -- using the intel gpu as the primary
07:06 imirkin: and then slaving the nvidia screen off that
07:06 imirkin: that will get you acceleration
07:06 RSpliet: imirkin: can you do GL accel that way? or is that unsupported
07:06 imirkin: which matters a lot more than you think
07:06 RSpliet: ah
07:06 RSpliet: great minds
07:07 imirkin: GL is the last of your concerns
07:07 imirkin: but assuming you're not on 320x200 screens... it's a lot of pixels to draw using the cpu
07:07 RSpliet: hehehe, right
07:07 imirkin: this is why DDX's exist -- to speed that up :)
07:08 Walther: Yeah, under linux I'm like 90% of the time deep in text editors, browsers, documentation, etc. GL won't matter, but some acceleration could be a bit kinder towards the cpu
07:09 Walther: Welp. If I do xrandr --setprovideroutputsource Intel 0, X crashes
07:09 imirkin: also, random applications now also like to use GL for totally random things and for no apparent reason
07:09 imirkin: other way
07:10 imirkin: er wait, no
07:10 imirkin: yeah, you probably want to update X
07:10 imirkin: like i said, a bunch of that stuff was fixed in 1.18
07:10 Walther: nod
07:11 Walther: asking in #debian-next if they have ideas of when 1.18 is coming to unstable from experimental or if they have workarounds in mind
07:12 imirkin: Walther: http://cgit.freedesktop.org/xorg/xserver/commit/?id=7328fb3f2b468048faf4ed4c29db720b5bf00b05
07:12 imirkin: looks like before that, reverse prime wasn't supported
07:23 Walther: nod, to which release version is that patch applied (i didn't find on a quick glance)
07:23 Walther: applied in June, so that could already be in 1.17?
07:39 imirkin: Walther: nope. 1.17 came out before that.
07:41 Walther: nod. I'll continue looking for how to update to 1.18 :)
07:44 imirkin: Walther: if that proves the most difficult piece, consider switching to intel as your primary
07:44 imirkin: the intel ddx supports all this stuff for a while
07:45 Walther: switching physically or the offloading part?
07:45 imirkin: well... virtually but it might require some careful config
07:45 imirkin: basically right now modesetting is the main "gpu". you want to make it so that intel is the main gpu
07:46 imirkin: tbh i'm not even sure how to do that while keeping the offloading stuff working... iirc it's pretty sensitive to what's in xorg.conf... i.e. any device sections break all the gpu stuff. however that might have been fixed at one point or another, i forget =/
07:47 Walther: hmm. I'll change primary gpu to intel in bios and let's see if that changes things
07:47 Walther: if i'm lucky, that will swap the enumerating order
07:48 Walther: if i'm unlucky, it'll disable nvidia and i can't game on windows on my off hours :P
07:54 Walther: YES! making igpu the primary boot gpu switched the enumerating orde
07:55 Walther: now I have two intel-provided displays on by default under linux, let's see if I can prettyplease xrandr into providing the main monitor from nvidia as well
07:56 Walther: gah, now xrandr only lists one provider :(
08:00 pmoreau: Maybe Nouveau went to sleep and isn't wake up by xrandr?
08:01 Walther: hehe, not sure if a joke or not :) If not, how can I prod nouveau awake?
08:02 pmoreau: You can disable power management by booting with nouveau.runpm=0.
08:02 pmoreau: I don't know how you can force wake up Nouveau otherwise.
08:03 Walther: how much power management does that disable - from "it won't be put to sleep automatically" to "it will how every watt it can get and be at 100% utilization all the time"
08:03 imirkin: pmoreau: unlikely, nouveau can't shut a dgpu off. could be some kernel bug though
08:04 imirkin: i mean, in a desktop
08:04 imirkin: Walther: pastebin dmesg + xorg log
08:04 pmoreau: imirkin: I'm too used to Optimus setups :-/
08:05 pmoreau: (gtg, bbl)
08:05 Walther: http://walther.guru/temp/Xorg.0.log.txt http://walther.guru/temp/dmesg.txt
08:06 imirkin: really?
08:06 imirkin: coz the xorg log seems all happy...
08:07 imirkin: Walther: pastebin xrandr --listproviders
08:07 Walther: xrandr --listproviders says Providers: number: 1; Provider 0: id: 0xe7 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 6 associated providers: 0 name:Intel
08:07 Walther: doesn't list nouveau or modesetting at all
08:07 Walther: like it used to
08:08 imirkin: oh, i see... you have a Driver "intel" section?
08:08 imirkin: try removing it
08:08 Walther: I have no manual xorg.conf at all
08:08 imirkin: er wait, no you don't
08:08 imirkin: hrmph
08:09 imirkin: oh wait! is this the reverse prime issue that 1.18 fixed? dunno
08:09 imirkin: gr
08:09 imirkin: sorry, i'm just not entirely sure what got fixed when
08:09 Walther: hey, no worries :)
08:10 imirkin: airlied would know off the top of his head, but he's in deep slumber
08:15 imirkin: gnurou: neat, saw your g+ post... let me know if you have trouble getting the texture/sampler descriptors released, i can probably sucker someone into making some traces for me, enough to RE the new thing.
08:36 gsedej: Still no microcode for GM108M from nvidia?
08:40 nchauvet_: Walther, I might have the same issue as your described with xrandr and optimus, I've just enabled DRI3 in xorg.conf and I was able to use DRI_PRIME=1 glxinfo outputs nvidia
08:41 nchauvet_: (using xorg-server 1.18)
08:42 RSpliet: gsedej: nope :-C
08:43 gsedej: nchauvet_, nouveau: probe of 0000:07:00.0 failed with error -12
08:43 gsedej: darn nvidia...
08:44 gsedej: did they say if they plan and when?
08:44 RSpliet: although I didn't think GM10x required any nvidia-provided firmware yet... imirkin could you confirm that?
08:44 Walther: imirkin: https://bugs.freedesktop.org/show_bug.cgi?id=89047 this might be relevant as per https://wiki.archlinux.org/index.php/PRIME#XRandR_specifies_only_1_output_provider
08:44 gsedej: how to get what error -12 means?
08:46 RSpliet: gsedej: it's a standard error code, defined in error.h or errno.h I think
08:46 gsedej: full dmesg http://paste.ubuntu.com/13863046/
08:46 RSpliet: ehh... ENOMEM sounds wrong
08:47 RSpliet: gsedej: nouveau 0000:07:00.0: unknown chipset (118010a2)
08:48 gsedej: using ubutnu 15.10, kernel 4.4, last mesa (PPA)
08:49 RSpliet: yep, I don't think there's support for 0x118, but you could rebuild your kernel copying line 2461 from drivers/gpu/drm/nouveau/nvkm/engine/device/base.c to get an entry
08:49 RSpliet: case 0x118: device->chip = &nv117_chipset; break;
08:49 RSpliet: and see if that works
08:50 RSpliet: if you're lucky you'll get basic display stuff (status unknown, sorry, others know more about maxwell), if you're unlucky it doesn't work in random ways :-P
08:50 gsedej: i downloaded kernel from ubuntu kernel-ppa
08:50 RSpliet: gsedej: yes, you'll have to build your own kernel to try what I suggested
08:51 gsedej: I see...
08:51 gsedej: but main problem is lack of firmware?
08:52 RSpliet: first problem is lack of nouveau knowing about your GM118 device
08:52 RSpliet: or, well, that's the most logical name I could give it based on the identifier it gives :-P
08:53 RSpliet: ah, GM108 it is, NV118, that makes (marginally more) sense
08:53 imirkin_: gsedej: RSpliet probably means GM108
08:53 gsedej: gpu namin is really confusing. "geforce 940m" , "GM108M". and 0x118 or GM118
08:54 imirkin_: gsedej: there's a patch in bugzilla to enable support for it in nouveau
08:54 RSpliet: gsedej: it confuses me too :-)
08:54 imirkin_: gsedej: but it really won't do you much good
08:54 imirkin_: GM118 is not a thing. there's NV118, which is the nouveau naming convention which worked a lot better before the GK208 came out
08:55 imirkin_: i.e. it was always 2 hex digits
08:55 RSpliet: yes, sorry I confused you there
08:55 imirkin_: gsedej: https://bugs.freedesktop.org/show_bug.cgi?id=89558
08:55 gsedej: (as optimus) so it won't be usefull at least untill firmware cames
08:56 imirkin_: gsedej: also nouveau has had (open) firmware for GM10x since kernel 4.1 or so
08:56 imirkin_: RSpliet: pmoreau: you guys really need to memorize this stuff before helping people -- GM20x is the problematic stuff, not all maxwell. GM10x also has problems, but not firmware ones.
08:56 gsedej: I heard it should be signed or something
08:57 imirkin_: gsedej: for GM20x yes. for GM10x no.
08:58 imirkin_: but for GM20x that's but a small fraction of the problem
08:58 imirkin_: gsedej: with the patch in bugzilla, your GM108 should basically work
08:58 RSpliet: imirkin_: that was in the back of my mind mind you, but yes, it'd be helpful if that was documented in the/a status matrix (splitting NV110 from NV120?)
08:58 imirkin_: gsedej: however you won't have things like reclocking/etc, making it essentially useless unless you're looking to hack on nouveau.
09:02 imirkin_: RSpliet: feel free to edit to your heart's content
09:02 gsedej: yes I know... i was just checking status...
09:02 imirkin_: RSpliet: also feel free to nuke the NVF0 section if it's still there
09:03 RSpliet: if I knew the status in detail I would, but as you could tell from my careful IRC replies here... ;-)
09:03 imirkin_: for reasons that are beyond me, skeggsb hasn't yet integrated GM108 support despite the fact that a mmiotrace is available and it looks to basically be identical to GM107
09:03 gsedej: why ther is no "case 0x118: device->chip = ..." for GM108m?
09:04 imirkin_: my guess is -EBIGGERFIRES
09:04 gsedej: in main repo
09:05 gsedej: pardon?
09:05 imirkin_: bigger fires, i.e. other more important things to do
09:06 gsedej: but there is 1 line magic?
09:07 imirkin_: that's not how things work...
09:08 imirkin_: someone has to go through the trace and see if the golden register values have changed
09:08 imirkin_: and by "someone" i mean "skeggsb" since he's the only one who knows what to look for
09:09 gsedej: but he is probably very occupied guy, and has bigger fires
09:10 imirkin_: exactly
09:19 gsedej: thanks for chat!
09:19 gsedej: and also thank you all for your work on FOSS drivers!
09:22 Walther: hmm, apparently i'm not the only one https://bugs.freedesktop.org/show_bug.cgi?id=74692
09:22 Walther: comment 6 and 8 show it isn't radeon-only
09:23 imirkin_: you might have more success asking in #xorg-users -- i think X people hang out there?
09:23 imirkin_: unfortunately i'm largely ignorant of the various X issues
09:31 Walther: nod. Huge thanks for the help!
11:36 pmoreau: imirkin_: I do remember that only GM20x need signed firmware, but I'm unsure about the switch to modesetting: is it only for GM20x or also for GM10x?
11:37 imirkin_: pmoreau: also for GM10x... there's no EXA code in the nouveau ddx for maxwell right now
11:37 imirkin_: so there's no point in using it
11:37 imirkin_: the modesetting ddx does everything the nouvaeu ddx would do and more
11:37 pmoreau: Ok, thanks. I'll try to remember
11:37 mupuf: imirkin_: speaking about this, there is a buffer age issue on the modesetting driver with dri2
11:37 imirkin_: the nouveau <-> glamor integration was broken... we could have fixed it but... who cares
11:38 mupuf: and I couldn't test the dri3 code
11:38 imirkin_: mupuf: ok...
11:38 imirkin_: mupuf: you're telling me because...?
11:38 mupuf: because we are talking about the maxwell and modesetting driver
11:38 imirkin_: ah
11:38 mupuf: not because I want you to fix it :p
11:39 RSpliet: mupuf: be honest now... you do
11:39 imirkin_: well, the modesetting driver might also have any number of bugs
11:39 mupuf: RSpliet: nope, that is something I should really fix
11:39 mupuf: not sure if there is a buffer age test
11:39 mupuf: but it seems to work most of the time, so that may be an intermitent issue
11:40 mupuf: anyway, I got a GM206
11:40 mupuf: my colleague let me have a look at his this morning and since I was at the equivalent of newegg in finland, I got it
11:40 mupuf: there are a bunch of new table versions
12:04 karolherbst: now I am curious to
12:04 karolherbst: o
12:04 imirkin_: mupuf: if you feel like making some mmt traces of stuff with the GM206 let me know
12:05 karolherbst: mupuf: did you take care of the PM_Mode already?
12:06 karolherbst: ohhh wait
12:07 karolherbst: mupuf: the blob doesn'T report the voltage used by the way?
12:08 karolherbst: mupuf: would be nice to confirm that the max voltage used while boost is below or equal 1.225V
12:17 mupuf: imirkin_: they are already in the vbios repo
12:17 mupuf: karolherbst: will see
12:18 mupuf: I made a very short trace using nvidia-smi
12:18 mupuf: because I did not want to configure x
12:18 mupuf: and I did this during a break
12:18 imirkin_: mmt, not mmio
12:18 mupuf: oh
12:18 mupuf: that can be done
12:18 mupuf: I will plug it on reator for people to have fun with
12:19 mupuf: Alexandre said nvidia is pretty close to releasing the firmwares
12:28 Tom^: karolherbst: well it is below 1.2x on kepler on blob that i can guarantee.
12:28 Tom^: karolherbst: overclockers has to mod the vbios to go above it :p
12:33 mupuf: yeah, the performance is not bad at all :D
12:34 mupuf: never seen heaven so smooth :D
12:35 Tom^: mupuf: which card?
12:35 mupuf: the shadows are really bad though :o
12:35 mupuf: GTX 960
12:35 Tom^: meh, blob then i assume. thats cheating :P
12:36 mupuf: sure! But since I need the blob to do some proper REing, why not run some benchmarks too?
12:40 mupuf: ok, the shadows were bad because I was in medium quality
12:40 mupuf: now, it is getting pretty slow using MSAAx8, full hd, tesselation normal and highest quality
12:41 imirkin_: only x8?
12:41 imirkin_: why not x32
12:41 imirkin_: and in 4k resolution
12:41 imirkin_: or 8k
12:41 mupuf: 8k is so 2017!
12:44 imirkin_: 8kx64@144hz
12:44 imirkin_: should be fine right
12:44 mupuf: ah ah, nice
12:44 imirkin_: (what msaa do blob drivers top out at?)
12:44 mupuf: 33 fps, not bad
12:44 mupuf: let's check
12:45 mupuf: x8 is the max
12:45 mupuf: not sure if it is MSAA
12:45 imirkin_: huh, they used to fake it before
12:45 imirkin_: maybe that's just a heaven limit
12:46 imirkin_: i think it might have diff shaders depending on MS level
12:46 mupuf: possible
12:46 imirkin_: glxinfo should tell you
12:46 imirkin_: 3rd column from the right
12:46 Tom^: ive never seen heaven do above 8x either on my card
12:46 imirkin_: ms/ns (multisample/number of samples)
12:47 mupuf: 16
12:47 imirkin_: are you sure you're not lookign at 4th from right?
12:47 imirkin_: i.e. the accum buffer bits?
12:47 imirkin_: you should see values like 2 4 8 16 32
12:48 mupuf: pretty sure, yes
12:48 hakzsam: mupuf, how many perf counters on that maxwell2? :p
12:49 mupuf: hakzsam: no idea
12:49 mupuf: how can I list them? LGD?
12:49 hakzsam: mupuf, /opt/cuda/extras/CUPTI/samples/cupti_query for compute-related ones
12:49 hakzsam: and LGD for the rest, yeah
12:51 mupuf: hakzsam: 4? :D
12:51 mupuf: sorry, 5
12:51 hakzsam: ahah no
12:51 hakzsam: it's the number of domains
12:51 hakzsam: so, cupti_query -domain XX -getevents
12:51 mupuf: tex0_cache_sector_queries, tex1_cache_sector_queries, tex0_cache_sector_misses, tex1_cache_sector_misses, elapsed_cycles_sm
12:52 hakzsam: these are global perf counters
12:53 hakzsam: mupuf, look for a domain which exposed warps_launched or threads_launched
12:53 hakzsam: *exposes
12:54 mupuf: there are quite a few, indeed
12:54 mupuf: counters about 70/80
12:54 hakzsam: in what domain?
12:55 mupuf: in all the domains
12:55 mupuf: max I found was 36 in one domain
12:55 mupuf: you will check them out when I am not on the machine :)
12:55 hakzsam: the card is plugged in reator? :)
12:56 mupuf: yes
12:56 hakzsam: nice!
12:59 hakzsam: mupuf, don't forget to plug the screen on that card, it would be good to run a full piglit too ;)
12:59 mupuf: it is plugged
12:59 hakzsam: thanks
13:01 mupuf: hakzsam: I will fix the vbios parsing, so if you want, you can have a moment alone with the gm206
13:01 mupuf: if you make mmt traces, store them for imirkin_
13:03 karlmag: hmm? gm206?
13:03 hakzsam: mupuf, I'll try
13:04 mupuf: karlmag: gtx 660
13:04 mupuf: err, 960
13:04 karlmag:looks at the box containing his 960.... I've heard of those.. ;-)
13:09 hakzsam: mupuf, I'm using reator
13:09 mupuf: hakzsam: ok, still fixing the vbios and checking how it looks like
13:11 hakzsam: mupuf, right, there are only few perf counters on that card, weird.
13:12 hakzsam: ahah, vectorAdd doesn't even work :)
13:13 mupuf: nice :D
13:14 mupuf: karolherbst: oh, it is not pwm-based
13:15 mupuf: it has 5 gpios for selecting the vid
13:16 mupuf: INA3221 with a sane power lane layout
13:17 mupuf: I wonder if the 5 connectors I have (3 DP, 1 HDMI and 1 DVI-I) can all work at the same time. Kepler increased the number of crtcs to 4, so maybe they lifted the stupid limit of 3 connectors max!
13:18 mupuf: or they may have added two more crtcs, to match AMD
13:19 imirkin_: pretty sure it's still limited to 4
13:19 hakzsam: imirkin_, http://people.freedesktop.org/~hakzsam/traces/maxwell/gm206/
13:20 imirkin_: hakzsam: cool. i was thinking mroe along the lines of graphics... texturing, etc
13:20 hakzsam: yeah, wait a sec :)
13:20 imirkin_: btw, cool project for someone who wants to dick around -- adding texture previews to demmt with aalib :)
13:21 hakzsam: fun!
13:22 karlmag: 3 connectors?... I had 4 monitors connected to my 650ti. (Or am I missing some point now?)
13:23 mupuf: karolherbst: some keplers had 4 but nvidia never supported more than 3 screens on windowds
13:23 mupuf: and linux got the restriction a few months later
13:25 karlmag:facepalms.. limiting hardware for all the wrong reasons :-(
13:25 mupuf: it was a feature for the quadros :D
13:25 hakzsam: imirkin_, what you want me to trace on that gm206? piglit tests or something?
13:26 imirkin_: hakzsam: piglit sounds good
13:26 hakzsam: which piglits?
13:26 imirkin_: some :)
13:26 hakzsam: okay
13:26 imirkin_: something with textures sounds good
13:26 imirkin_: i just want to see tic/tsc setup
13:54 mupuf: hakzsam: ok, can I continue on reator?
13:54 imirkin_: ok, looks like the TIC is totally different
13:54 imirkin_: but TSC stayed the same
13:55 hakzsam: mupuf, sure
13:55 mupuf: good, let's check out those power tables
13:56 imirkin_: i won't be able to work it out from this one datapoint, so gnurou -- let me know if i need to do it or if you'll be able to open up the docs for it
13:57 mupuf: imirkin_: you have access to the gpu though, if you want
13:57 imirkin_: mupuf: thanks. but it's not like a 0 amount of time to work it all out
13:57 imirkin_: mupuf: i'd rather not spend time on it if i don't have to
13:57 mupuf: I am sure it is not!
13:58 imirkin_: mupuf: esp for a GPU that nouveau still can't work on
13:58 mupuf: right, and you have been making perf improvements recently, which is unusual for nouveau :p
13:58 imirkin_: my guess is it'd be an hour or two of work to figure it all out
13:58 imirkin_: assuming they just shifted the fields around coz they could
13:59 imirkin_: [probably a few fields got wider, and they had to]
13:59 imirkin_: larger max texture size perhaps?
13:59 imirkin_: mupuf: hakzsam: can one of you grab 'glxinfo -l -s' for it?
14:01 hakzsam: imirkin_, http://paste.awesom.eu/loZQ
14:01 imirkin_: thanks
14:01 imirkin_: GL_MAX_SAMPLES = 32
14:01 imirkin_: so same as before
14:02 hakzsam: good news, compute seems to be pretty similar regarding gk104 :)
14:02 imirkin_: cool
14:02 imirkin_:wonders if GM20x has native ASTC or if it's all faked
14:04 imirkin_: hmmmmm... none of the max sizes appear to have changed
14:04 imirkin_: i wonder why they moved things around
14:05 mupuf: hmm hmm, nvafakebios does not work anymore?
14:05 hakzsam: demmt can now decode compute support on maxwell :)
14:06 mupuf: well, let's have a look at a mmiotrace
14:08 hakzsam: well, time to extract the firmware now :P
14:09 mupuf: PDISPLAY.VGA.ROM_WINDOW => { BASE = 0 | TARGET = VRAM } --> hmm, that's not gonna fly :D
14:09 imirkin_: hakzsam: firmware's not in the trace
14:09 mupuf: same problem as karol, except he has an invalid memory address, which is even worse
14:10 hakzsam: imirkin_, sure, I know
14:10 mupuf: imirkin_: the base address must be ... somewhere :D
14:10 imirkin_: yep
14:10 pheller: Are renouveau dumps still useful for the development team?
14:10 mupuf: pheller: nope
14:10 hakzsam: I never used renouveau
14:10 imirkin_: and all you have to do is read out that address when it's written to the gpu, and read the associated ram
14:11 imirkin_: pheller: renouveau is a bit outdated
14:11 imirkin_: by about 6 years or so?
14:11 imirkin_: pheller: are you having particular issues, or just inquiring?
14:13 pheller: Thanks. Last time I ran Linux on a machine with an attached display was in 1996 or so. I just built a machine for fun and the graphics card I chose is relatively new, so not a lot of support outside the proprietary drivers it seems.
14:14 imirkin_: pheller: if it's a GM20x, yeah, nouveau's not going to be great for you
14:15 imirkin_: pheller: but linux graphics have come some ways since XFree86 3.3
14:15 imirkin_: (which iirc was the latest and greatest in '96)
14:16 pheller: I chose a Quadro K1200 (GM107). It's not bad under nouveau, but not fast enough I'd use it day to day, yet.
14:16 imirkin_: ah yeah. GM107 should kinda-sorta work
14:16 imirkin_: esp with kernel 4.1+
14:17 pheller: Yeah, on fedora rawhide and wayland it's not too bad. Nice to keep the same screen mode from EFI the whole way through logged in without a single flicker.
14:20 imirkin_: hakzsam: oh, another demmt task is to make it display TIC/TSC info on kepler+
14:20 imirkin_: hakzsam: right now it doesn't because it's all bindless... we should decode it ... at some point. unclear.
14:21 hakzsam: imirkin_, which kepler? gk208 for example?
14:21 imirkin_: any
14:21 imirkin_: it's all bindless
14:21 imirkin_: we should look at what's stuffed into the TEX_CB
14:21 hakzsam: there is a gk208 in reator, and I have a gk106 at work
14:21 imirkin_: at ... say... draw time
14:22 imirkin_: and decode any TSC/TIC's as a result
14:22 imirkin_: or maybe anytime anyone writes to the TEX_CB
14:22 imirkin_: presumably that dosen't change too often
14:24 hakzsam: okay
14:24 imirkin_: yeah, looks like that should work
14:25 imirkin_: http://hastebin.com/jorodiyixa.avrasm -- 0x103589700 = tex cb for frag shader
14:25 hakzsam: I'll do that tomorrow :)
14:30 imirkin_: let me know if you run into trouble (i suspect you will...)
14:31 joi: imirkin_: or demmt could save textures to files as it decodes the stream :D
14:31 imirkin_: joi: yeah, but having it inline is so much prettier ;)
14:31 joi: :D
14:31 hakzsam: imirkin_, for sure, I will :)
14:32 imirkin_: hakzsam: basically trigger it on CB_DATA writes
14:32 imirkin_: [note that the deocded tic for gm204 won't make sense -- that's expected]
14:33 hakzsam: okay
14:54 mupuf: well well
14:55 mupuf: it would seem like something funny is going on
14:55 imirkin_: i'm laughing already
14:55 mupuf: nvidia does read the vbios from PRAMIN
14:55 mupuf: twice actually, first using 8-bits reads
14:55 mupuf: and another time with 32-bits reads
14:56 mupuf: and, for some reason, decides to give up right after
14:56 imirkin_: no 128-bit reads :)
14:56 mupuf: hehe
14:57 mupuf: maybe we parse the length of the vbios wrongly or otherwise don't copy far enoug
14:57 mupuf: I guess it is easy to check!
15:20 mupuf: well, same issue as karolherbst, the middle of the vbios gets corrupted
15:20 mupuf: but this is because we upload past the vbios size :s
15:22 mupuf: seems like when the blob is reading from PRAMIN, it limits itself to the first 0xf400 bytes
15:44 mupuf: everything seems to be fine though :s I guess the problem is that it may be missing stuff
15:45 mupuf: and the blob complains loudly about this
15:46 mupuf: I *may* be able to fix it because the blob seems to read after the end of the vbios and just gives up rapidly
15:46 mupuf: which may indicate that some validation kicks in
15:46 mupuf: that is ... unfortunate
15:49 mupuf: hmm, actually, this looks like a signature or something
15:51 mupuf: well, time to slee[
15:51 mupuf: that will be work for friday or the week end
15:52 mupuf: let's cross fingers that it is the problem here!
16:11 karolherbst: mupuf: fun times right? :D
16:11 karolherbst: mupuf: I also try to upload only a bit, still crash
16:11 karolherbst: maybe f400 bytes work? don't know I think I tried a little mroe
16:21 gnurou: imirkin_: ideally I'd like for us to release the docs, but if you have a chance to poke around, please feel free
16:42 imirkin_: gnurou: well, i can do it, but it will require thought and concentration and... hardware :) which mupuf is kindly providing, so not a huge issue. what are the chances of you releasing the new tic format?
16:43 gnurou: imirkin_: don't know yet, I am still waiting for a reaction from the people who can give an ack for this
16:43 imirkin_: gnurou: ok. what sort of timeframe do you expect to hear back from them?
16:43 imirkin_: a week? a month? no clue?
16:44 gnurou: imirkin_: no clue really, but it should not take too much time... I will ping some more people today
16:44 imirkin_: no rush :) just want to know when to give up waiting and just do it myself
16:44 gnurou: all that is required is someone to look at my request and say "mmm yeah that's fine"
16:44 imirkin_: i'm sure your docs will be a lot more complete than any crap i come up with
16:45 gnurou: well you would have every little detail documented, things that a trace cannot reveal
16:45 imirkin_: exactly :)
16:45 imirkin_: hence my preference for your docs
16:45 imirkin_: (that and laziness, which also runs deep)
16:46 imirkin_: bbl