00:43mooch: i'm thinking about setting up a nouveau dev partition alongside my standard linux partition
00:43mooch: what distro should i use? i'm thinking arch, since it has REALLY up-to-date packages
00:45orbea: mooch: choose w/e distro doesn't make it too hard to compile your own packages and you are comfortable using
01:14imirkin: mooch: mostly just pick a distro you're most familiar with
01:44mooch: fair enough
01:47mooch: or maybe
01:47mooch: i should work on hwtests for NV4x!
01:47mooch: i have that hardware, after all
02:32mangix: mooch: arch.
02:33nyef: Yeah, I'd use gentoo, but that's mostly from familiarity.
02:34mooch: i already installed arch on here
02:34mooch: well, a different computer
02:34mooch: but yeah
02:35nyef: Also because I can nfsmount the portage directory from an already-installed system and not have to deal with all the bloody downloading on top of all the bloody compilation.
02:35mooch: fair enough
02:35mooch: i have an nv4e, so it's kind of a late nv4x
02:37skeggsb: nv4e is a horrible chip :P
02:37skeggsb:used to have one in a laptop, and *hated* it
02:37nyef: Hello skeggsb.
02:37skeggsb: nyef: hey
02:38nyef: skeggsb: I've already received some feedback on the v2 HDMI 3D patch series, mostly about doing a compile where I can actually see compiler warnings and running checkpatch.pl, but do you have anything further to recommend?
02:39skeggsb: not as of yet, i've had a quick look over the patches, but want to do some more in-depth testing/looking at them
02:39nyef: (Am I doing anything not quite right with the NVKM interface, for example?)
02:39nyef: Okay, I don't *think* I'm in a hurry at this point. (-:
02:39mooch: skeggsb, well, it's the only nv4x i have
02:39skeggsb: currently in the process of moving house, so i'll probably play with various boards on my 3D-capable TV when that's settled
02:39mooch: so i'll write the tests for it
02:40nyef: Fair enough.
02:40skeggsb: mooch: fair enough :) it was my main GPU for a while
02:40nyef: (When does the merge window for getting stuff ready for 4.12 close, btw?)
02:40skeggsb: when airlied yells at me ;)
02:41imirkin: it's a highly refined and formal process...
02:42nyef: My current thought for the userland side, btw, is to start with the modesetting driver rather than xf86-video-nouveau.
02:43nyef: For two reasons. First, because it's simpler. And second, because it should also work with the i915 driver.
02:43skeggsb: my advice is to not even bother with -nouveau
02:44skeggsb: imirkin: btw, on that front.. i'm probably going to push a patch that, by default, fails probe on >=GF119 (anything that can do MST), but allow it to be overridden in xorg.conf
02:44skeggsb: nyef: it's basically unmaintained, and the display-related stuff is buggy as hell vs -modesetting
02:44skeggsb: nyef: and it has no MST support, as indicated above
02:45mooch: skeggsb, same here
02:46nyef: So... mesa should work accelerated anyway on -modesetting, and glamour as well?
02:46nyef: Good enough, I guess.
02:46skeggsb: imirkin doesn't agree :P
02:46imirkin: my advice is the inverse :)
02:46skeggsb: and that's fair enough, there are some valid reasons against it
02:47imirkin: skeggsb: i'd much rather support MST - should be easy.
02:47skeggsb: patches welcome :)
02:47nyef: I'm half-tempted to try and write a DRM driver for Apple's 8*24GC card, just because, but that's a bit off-topic for here.
02:47orbea: at least 3 bugs went away with modesetting for me :)
02:48imirkin: skeggsb: yeah, i'm going to push out the pascal one shortly
02:48mooch|craptop: mwk: do you understand anything about the nv4x ctxprogs yet?
02:48imirkin: skeggsb: will try to look at what all is necessary for MST. my guess is, "not much"
02:49imirkin: the hardest part will be to find someone to test
02:49imirkin: none of my nvidia gpu's even have DP
02:49skeggsb: i think it's stuff to handle new connectors appearing, and others disappearing
02:49skeggsb: can't imagine there's anything beyond that
02:49mooch|craptop: imirkin, do you know anything about nv4x ctxprogs and their purpose?
02:49nyef: I'll have access to my test equipment, GF119 and GK104 with DPort outputs, for a week, maybe two, starting on about Easter.
02:49imirkin: mooch|craptop: i think it's all documented in nouveau.
02:50skeggsb: mooch: it's microcode to handle the graphics engine context switch
02:50skeggsb: performs the same function as the falcon ucode on alter GPUs, essentially
02:50nyef: ... But what's "MST" in this context?
02:50skeggsb: nyef: DisplayPort Multi-stream
02:51mooch|craptop: skeggsb, imirkin, so are they not necessary for functioning, or what?
02:51nyef: Ah. So the question becomes, will my *display* even handle it?
02:51skeggsb: mooch|craptop: yes, they're necessary if you want to use more than one channel
02:51mooch|craptop: well then
02:51imirkin: nyef: it's DP 1.2. this comes up if you e.g. daisy-chain monitors, or have a DP hub (as many laptops and/or their docks do)
02:52skeggsb: or have a stupid 4k monitor that pretends its 2 monitors
02:52imirkin: [or if you have one of those awesome 4K panels that present themselves as 2 separate panels to get 4k@60
02:53nyef: So... if I'm going to test this, either get *another* bloody panel, or a hub?
02:53nyef: (an external hub, if such things exist?)
02:53imirkin: hubs aren't exactly common either
02:53mooch|craptop: shit, hwtest doesn't work here
02:53skeggsb: they exist, airlied has 2 of them :P
02:54skeggsb: more common in docking-station form though
02:55nyef: ... wow. $80, retail.
02:56imirkin: nyef: well don't do it on my account!
02:57nyef: Right. I'd also need a DPort to miniDPort adaptor, or the other way around, M-to-F, in order to cover all of the hardware combinations, and I only have one DPort display at the moment, so I wouldn't need it otherwise...
02:58nyef: So, if it's not necessary, I'll give it a miss.
02:59mooch|craptop: any reason why nva would be unable to find my nvidia gpu?
03:00imirkin: nyef: i'm sure i can con someone else into doing it... maybe even skeggsb.
03:19mooch: mwk, some of your vp1 tests fail on nv4e lmao
03:27nyef: Hrm. rc6 is, what, a week and a half away?
04:24nyef: ... Ah. I didn't think I'd managed to screw up an include like that and not notice, even with the build process I'd been using. Looks like a rebase onto 4.11-rc5 is in order soon.
04:32nyef: Rough plan: I start prepping the v3 patch series on Monday, with an eye towards getting it out the door by midweek, preferably sooner, even though I'm without almost all of my test hardware.
08:14mwk: mooch: I understand most of nv40 ctxprogs
08:14mwk: not all
08:14mwk: as for vp1 fails... interesting
12:43karolherbst: gnurou: you know anything new about PMU firmware images? Because we kind of need a solution for this. And if the PMU situation will be the same over and over again for every new chipset, then we need a solution without depending on Nvidia. I am kind of super annoyed about this now
13:33whompy: ^this. From a user standpoint, I cannot even consider purchasing an nvidia-based laptop on the present situation. I just can't trust it to not be a pain in Linux.
13:35karolherbst: whompy: it is even worse. Because the vbios is signed as well (or at least we think/assume so), we can't do any vbios reverse engineering on maxwell2+ GPUs. Maybe there is a way, but we didn't find it yet
13:36karolherbst: which also means that reclocking on pascal won't be supported by Nouveau
13:36karolherbst: and can't be really
13:36karolherbst: except with a lot of guessing and far from being as stable as we have it for kepler/maxwell now
13:38RSpliet: karolherbst: As long as we haven't gotten our Fermi DRAM clock changing game on, I don't think it's fair to call that a top priority issue O:-)
13:38karolherbst: well, I won't buy a fermi GPU next and use it as my main one :p
13:39karolherbst: I guess I would buy a 780TI + Pascal for REing
13:39RSpliet: Right, but practice shows that it takes several years to get this going, let's first think about the most pressing issues (ctxswitch and fan management!!!!!)
13:40karolherbst: if we solve fan management on maxwell2, we also kind of solve the vbios issue if we find a way without nvidia
13:40RSpliet: While we get GSOC students to squeeze out the last drop of performance from boot clocks
13:40karolherbst: and to be honest, I would prefer every way if it doesn't involve nvidia
13:41RSpliet: Autonomy is nice, but so is trust and collaboration
13:41karolherbst: well, I am working on dynamic reclocking in the meantime anyway
13:41karolherbst: nvidia doesn't make it easy to trust them
13:42karolherbst: and what collaboration are you talking about :p Tegra is nice and everything, but seriously on the desktop side there is basically none or not enough
13:42RSpliet: as long as you discouple that sentiment from the few people we know are trying everything they can to make it work (gnurou, sooda, aritger, ... thanks) I'm cool with it ;-)
13:43karolherbst: still sucks to don't get any PMU images and yes I know there are some at nvidia, which want to help us
13:43karolherbst: and this is nice and good and I am thankfull for that
13:43RSpliet: Just checking :-)
13:44karolherbst: I am just a little annoyed, that everything "official" is mostly super useless, except the firmware images we got now and all the support skeggsb gets for adding modesetting support
13:45karolherbst: uhm, wait a second
13:45RSpliet: karolherbst: bear in mind NVIDIA has not truly committed to getting the desktop side of the story straight. They promised firmware as a means of not getting in our way, but their commitment is mainly Tegra. Helping out with modesetting is already beyond that
13:45karolherbst: "/open-gpu-doc/qmd/" is this new?
13:45karolherbst: Queue Meta Data
13:46mwk: it's been there for some time
13:46karolherbst: ohh, okay
13:46RSpliet: "10/11/16" to be precise
13:46karolherbst: I checked a few weeks ago
13:46mwk: but I haven't noticed an announcement for that, I just checked one day and it was there
13:46karolherbst: and I didn't see it
13:46karolherbst: this is for pgraph, right?
13:47karolherbst: :D hihi
13:48karolherbst: mhh, NVC0C0_QMDV01_07_THROTTLED
13:49karolherbst: NVC0C0_QMDV01_07_DEBUG_ID_UPPER and NVC0C0_QMDV01_07_DEBUG_ID_LOWER
13:49karolherbst: this sounds like interesting stuff
13:50RSpliet: NVIDIA are doing things, unfortunately 'The bureaucracy is expanding to meet the needs of the expanding bureaucracy.'
13:51karolherbst: imirkin: did you checkout the qmd stuff already?
13:55karolherbst: I still prefer a way of doing the firmware stuff without nvidia. I am currently just waiting on the first drop of PMU images and decide then how I want to continue. Maybe those end up in being super usefull, but that still has to be decided
13:56RSpliet: All you need to do is find (a collision of) their signing key. Go go go!
13:57karolherbst: There are other ways
13:58karolherbst: I doubt that the hardware implementations is 100% secure or the releases images or the images inside the nvidia driver
13:58karolherbst: just depends on how usefull the issues are we may find
13:59RSpliet: a rowhammer attack on their internal security mode register?
13:59karolherbst: why not
13:59RSpliet: there might not be rows :-D
13:59karolherbst: I am sure we could do timing attacks
14:00RSpliet: think it's pub/privkey mechanism, so finding the certificate isn't going to help you
14:01karolherbst: who says we have to sign it with a key?
14:01karolherbst: as long as the hardware eats it, it's fine, no matter how we came to this
14:02karolherbst: for example. if we get a different timing with half of the signature right, then we can adjust the sig until it's right
14:02karolherbst: one example
14:02karolherbst: this just makes deployment difficult, but still
14:03karolherbst: thinking outside the box is very important here ;)
14:03karolherbst: using a key makes it _easy_ not _possible_, it's always possible, you just need to find a useable mean
14:07ctOS: If I’m reading this right, then there is no nouveau driver for Pascal cards (GeForce GTX 1060) and there won’t be any? https://nouveau.freedesktop.org/wiki/ — or is that just refering to the mobile chips?
14:09RSpliet: ctOS: there is nothing on the webpage related to the future
14:10RSpliet: Currently there is very very very limited support for Pascal, I believe hindered by a lack of firmware
14:11ctOS: RSpliet: firmware as in driver released by nvidia?
14:11RSpliet: if we could, we would've developed this firmware long ago, unfortunately, as we just discussed, our hands are currently tied up like a bad bondage porno
14:11RSpliet: not the whole driver, just firmware
14:18karolherbst: well, it's inside the nvidia driver _somewhere_
14:22RSpliet: The firmware? Yes, compressed and unrecognisable... No-one's gone on the big scavenger hunt yet I think, might be one of your best bets at the moment
14:23karolherbst: allthough "compressed" is a guess or was it confirmed somehow?
14:24karolherbst: because if I would be a nice developer at nvidias, I would make it so, that others can find it "accidentally" :O
14:24karolherbst: thinking of that, maybe in the first release with maxwell2 support, it is indeed detectable
14:24karolherbst: andwas fixed later
14:24RSpliet: educated guess, see https://raw.githubusercontent.com/imirkin/re-vp2/master/extract_firmware.py
14:25karolherbst: uhh, I see
15:04gnurou: karolherbst: I don't want to give you any false hopes. I don't see the situation getting better anytime soon
15:05karolherbst: gnurou: :/
15:06gnurou: I am at least as annoyed as you are about this
15:07gnurou: but that's beyond my power
15:09karolherbst: yeah, I don't blame anybody personally
15:25Lyude: Is anyone working on vulkan for nvidia? curious
15:26karolherbst: gnurou: I just hope, that we figure something out, and currently I would go for nearly everything
15:27orbea: Lyude: i think skeggsb is at least planning to, but it may be a while.
15:27Lyude: hm, alright
15:32dboyan_: imirkin: I think I've got ARB_shader_clock working on nvc0 with nha's series.
15:45imirkin_: dboyan_: awesome. i was going to hook it up, bug happy for someone else to take it :)
15:46imirkin_: whompy: no, you can trust it to be a pain.
15:48dboyan_: imirkin_: i'll send my series tomorrow, maybe. I have to go to bed now.
15:50whompy: I guess I get to wait and hope for Vega to work out well
15:53karolherbst: whompy: do not expect Vega to be any better ;)
16:12Lyude: imirkin_: finally should have all 9 shader tests done, will cleanup and send out new series for mesa+piglit for fill_rect after lunch :)
16:13imirkin_: does it all work?
16:13imirkin_: i.e. does it do what you expect it to do, i.e. no effect on lines/points, effect on triangles?
16:14Lyude: yep! isolines aren't affected, tris from the TES are, tris in point_mode from the TES aren't, points and lines from the gs aren't affected, triangles from the gs are, and the normal GL_POINTS and GL_LINES modes aren't affected
16:20imirkin_: yay :)
16:24whompy: Karolberbst: Vega, not Volta. ;)
17:09Lyude: imirkin_: btw, I was thinking we might also want one additional shader test to make sure that mesa throws an error if we try to draw with only one polygon side set to GL_FILL_RECTANGLE_NV?
17:09imirkin_: yes, a few error-related tests are good too
17:09imirkin_: that said, i don't know if shader_runner is well equipped for that
17:10imirkin_: normally those are written as C tests
17:10imirkin_: find piglit/tests -name errors.c
17:10imirkin_: for inspiration
17:10Lyude: Yeah I figured shader_runner wasn't able to, I could also just add some stuff to shader runner to expect GL errors as well
17:11imirkin_: that'll be tricky
17:11imirkin_: esp as different APIs can have different error requirements...
17:11imirkin_: imho not worth it
18:57karolherbst: my first brain dump for the presentation I want to held about Nouveau: https://drive.google.com/file/d/0B78S7GSrzebIYnpSTTkzV3B4WmM/view
18:57karolherbst: would be nice to comment on this for wrong/missed points or things I should rewrite/remove and stuff
19:34imirkin_: karolherbst: (Nvidias Linux API für Videobeschleunigung)
19:34karolherbst: mhh meh
19:35karolherbst: okay, thanks, fixed
19:35karolherbst: I was thinking about adding translation support to the latex document, but then I thought: even if all of those can speak german, it would be to painful to keep that kind of stuff updated
19:36karolherbst: But I think I even removed the Nvidia part
19:36karolherbst: because, well
19:37karolherbst: ohh, I have twice
19:50imirkin_: well, feel free to do stuff in german
19:50imirkin_: but my german is ... weak at best
19:51karolherbst: maybe I translate it later
19:51imirkin_: karolherbst: what's the context for the presentation btw?
19:51karolherbst: I was kind of asked to hold one, cause I was telling people I am a nouveau dev
19:52imirkin_: if it's not a gpu-focused environment, i might recommend having more info
19:52imirkin_: like ... history, maybe mention timelines and gpu's
19:52karolherbst: it's totally not gpu focused
19:52imirkin_: as well as their capabilities and differences
19:52imirkin_: but i dunno hwo long it's supposed to be
19:52karolherbst: too much time
19:53imirkin_: or is this like a 5-minute talk?
19:53karolherbst: not 5
19:53karolherbst: but I wanted to do more over questions than actual presenting
19:53karolherbst: it should be a presentation about the project, not GPUs in general
19:53imirkin_: you won't get good questions -- never rely on that.
19:53imirkin_: [sometimes you will, and it's nice if you do, but ... ]
19:54karolherbst: I already got some before giving this presentations :D
19:54karolherbst: yeah I know
19:54karolherbst: but my main focus is more on the actual work/task we are working on, or at least this was my first idea
19:54imirkin_: that's too advanced for people who know nothing about GPUs though
19:55karolherbst: well nothing is an underestimation though
19:55karolherbst: I would say, most don't know much
19:55imirkin_: i dunno, well you know the audience better, so ... your call :)
19:55karolherbst: it would make sense to somehow explain the basics about GPUs though or maybe how the graphics pipelines works or something lke this
19:56imirkin_: yeah... nothing complex
19:56imirkin_: basically explain vertex/frag shaders
19:56imirkin_: and then handwave tess/geom :)
19:56karolherbst: but I don't feel like giving too much timelines stuff
19:56karolherbst: cause this is just boring
20:35Lyude: imirkin_: for config.supports_gl_compat_version in the PIGLIT_GL_TEST_CONFIG section for the binary test for fill_rect, should that be 43? I tried 43 here and I just kept getting "piglit: error: waffle_context_create failed due to WAFFLE_ERROR_UNKNOWN: glXCreateContextAttribsARB failed", but 31 seems to get a little farther (but 3.1 isn't the right GL version...)
20:36imirkin_: you probably want 11
20:36imirkin_: or 13 or something
20:41Lyude: that worked, thanks!
23:23imirkin: Lyude: no need to resend btw, make the fixes, put them in a branch somewhere, i'll pull
23:45Lyude: imirkin: oh okay, sounds good
23:49imirkin: [or if you have push rights, i could probably just bless the final versions]