11:34moongazer: How do I find out if I have a NVIDIA Maxwell GM107 / GM108 chip?
11:40pmoreau: `lspci -d 10de:` will restrict the output to NVIDIA devices
11:40moongazer: pmoreau, gnarface 01:00.0 3D controller: NVIDIA Corporation Device 179c (rev a2)
11:42moongazer: pmoreau, tell me?
11:42gnarface: '3D controller' ?
11:42pmoreau: Are you running Nouveau on it?
11:43gnarface: if it was actually a video card, i would expect it to say "VGA..."
11:44gnarface: wouldn't it have to?
11:44imirkin: 179c is not a range that is in my pci.ids file, interesting
11:44imirkin: 3D Controller is a subtype of VGA
11:44imirkin: (sort of)
11:44gnarface: maybe it's something ancient? a PCI or AGP card?
11:44imirkin: anyways, 17c-f is GM200, and 172x is GP100
11:44moongazer: Well I have a NVIDIA GeForce 940MX with 2GB VRAM on my notebook
11:44imirkin: no, ancient stuff is all covered
11:45moongazer: Now tell m
11:45mwk: imirkin: not fully
11:45imirkin: moongazer: well, if you install envytools, and run 'nvapeek 0' it should tell you
11:45imirkin: mwk: fully enough that we have every range :p
11:46moongazer: imirkin, any other way?
11:46mwk: well, it's not GM108, that's for sure
11:46imirkin: mwk: why not?
11:47gnarface: moongazer: it usually says, right there. the issue is nobody has ever seen one that looks like yours. it usually looks like this: 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 650 Ti Boost] (rev a1)
11:47mwk: that'd be 13[4-7]*
11:47imirkin: moongazer: nothing particularly easy
11:47moongazer: Well, I am running a nouveau driver on it
11:47imirkin: mwk: could have multiple ranges, lots of chips do, no?
11:47imirkin: moongazer: oh. then just look in dmesg.
11:47mwk: well, in principle...
11:47imirkin: moongazer: dmesg | grep nouveau
11:47gnarface: it's so weird in fact, i wonder if it's counterfeit
11:48moongazer: gnarface, No it's not a counterfeit, don't worry
11:48imirkin: gnarface: nah, i've seen the 179c thing before, in conjunction with the 940MX in fact
11:48imirkin: i don't remember the outcome though
11:48imirkin: gnarface: lspci is just based on the pci.ids file -- since it's not in there, it won't say
11:48moongazer: [ 0.847216] nouveau 0000:01:00.0: NVIDIA GM107 (1171c0a2)
11:49imirkin: moongazer: so there you have it.
11:49mwk: so... multiple ranges?
11:49moongazer: imirkin, where do I have what?
11:49pmoreau: NVIDIA GM107
11:49moongazer: pmoreau, what does that even mean?
11:49imirkin: mwk: it's been known to happen
11:50mwk: well, you asked if it's a GM107 or GM108
11:50pmoreau: You were asling whether it was a MG107 or GM108
11:50moongazer: And why isn't my card name been shown
11:50mwk: because nobody except marketing cares about card names
11:50moongazer: I got that
11:50mwk: nouveau doesn't even bother to figure it out
11:50moongazer: mwk, lol OK
11:50mwk: all that matters is the chipset
11:50imirkin: it'd be a full time job to keep track of that... we have better things to do.
11:51imirkin: although ben did do an initial import of all the names for some odd reason
11:51mwk: well, they were in xf86-video-nv, ages ago
11:51mwk: once in a while someone thinks we care and sends a patch that updates it :p
11:53mwk: heck, I made a list in envytools as well
11:53moongazer: Someone look at the above page
11:53moongazer: And look at 'Maxwell Accelerated Video Decoding'
11:53moongazer: Can someone tell me what this project is all about?
11:54imirkin: video decoding on maxwell?
11:54mwk: ah, scary things
11:55imirkin: moongazer: basically "through willpower and magic, make video decoding work on GM10x chips"
11:55bsper: Hey. I have a GTK 770M, is power management through pstate supported for that card?
11:55moongazer: imirkin, The meaning is hardly clear....
11:55imirkin: it actually shouldn't be that hard... no more than a month's work i figured
11:55imirkin: bsper: yes.
11:55pmoreau: imirkin: I guess GM20x as well, except that at low clocks it is not that useful?
11:55moongazer: imirkin, I am student interested in doing this project.
11:56bsper: imirkin: Thanks!
11:56imirkin: pmoreau: an except for the potentially signed firmware situation
11:56imirkin: moongazer: ok ... so what's your question?
11:56pmoreau: Ah, yeah
11:56imirkin: [fyi, GSoC has already started, but EVoC can be done at any point afaik]
11:57moongazer: imirkin, What does it mean exactly, how do go about contacting the right people, what do you mean by video decoding, what technologies are used etc.
11:57imirkin: well ... irc is the right way to contact, and i am the right person
11:58imirkin: video decoding means ... decoding videos. sorry, not sure how to better describe it.
11:58imirkin: you have a video, and you want to decode it, so you do video decoding?
11:58moongazer: imirkin, I mean I know what video decoding means
11:59imirkin: ok, so what's your question?
11:59gnarface: moongazer: it's not actually working currently. when you play video it's using software decoding. it's not hardware-accelerated
11:59bsper: Hmm, none of the settings in /sys/kernel/debug/dri/0/pstate seem to be activated, but the settings are there. Is AC the default setting? Even though there's no visual feedback of it being activated
11:59moongazer: gnarface, so is that what the project is all about.
11:59imirkin: bsper: AC is the current setting
12:00moongazer: imirkin, how do I go about doing this project
12:00bsper: imirkin: Okay, thanks
12:00imirkin: bsper: you can't (currently) reclock while the GPU is off
12:00gnarface: moongazer: presumably (i didn't actually look at the schedule in question, i don't work here)
12:00imirkin: bsper: so make sure that the application is already running before changing clocks
12:00bsper: imirkin: Noted, thank you
12:00imirkin: moongazer: the project is about the video decoding engine on maxwell. figure out how it works, and then add code to make use of it.
12:01imirkin: (RE = reverse engineer, btw)
12:01pmoreau: imirkin: Didn't karolherbst_ or RSpliet fix that (reclocking while the GPU is off)? Or at least that it wouldn't hang?
12:01RSpliet: not me
12:02imirkin: pmoreau: iirc the fact that it was dying was fixed, but it still doesn't set the old values on resume
12:02pmoreau: Ah, ok
12:02RSpliet: my mapping of nouveau plumming is still from three rewrites ago, I never found the time to keep up properly :-(
12:02imirkin: bsper: oh, and another little bit of info you might be missing is that the GPU goes to sleep on laptops when it's not in use - it should say DynOff in the vgaswitcheroo file.
12:02imirkin: RSpliet: yeah, ben writes this stuff faster than i can read it too :)
12:02imirkin: RSpliet: but i think i'm one rewrite ahead of you...
12:03pmoreau: RSpliet: But I'm sure the most recent one was the Last One (TM)!
12:03imirkin: pmoreau: just like all the previous ones.
12:04pmoreau: But I am definitely not going to complain about those rewrites, they have definitely improved the code
12:04bsper: imirkin: I don't have an optimus laptop, the integrated GPU is turned off for whatever reason. It shouldn't apply to me then, right? vgaswitcheroo doesn't exist on my system (great name by the way)
12:05imirkin: bsper: oh, then yeah, you can just reclock. the settings should be reflected on the AC line. if they're not, you're in trouble
12:05imirkin: bsper: also note that this stuff only started working with moderately recent kernels... 4.9 or 4.10 or something
12:05imirkin: [well, it STARTED working a long time ago, but started working RELIABLY only recently]
12:06bsper: imirkin: Thanks, take care
12:06pmoreau: bsper: Integrated GPU being turned off, are you on a rMBP?
12:06bsper: pmoreau: Asus ROG
12:07karolherbst_: pmoreau: not pushed
12:07pmoreau: Ah, ok. Cause on some of the MacBook Pros (2013 at least), the Intel GPU is turned off by the EFI firmware if the OS does not identify as macOS.
12:08pmoreau: karolherbst_: Ok
12:10moongazer: imirkin, ok hmm
12:10moongazer: imirkin, the kepler project after that...is my video card good enough to do that
12:11karolherbst_: pmoreau: we need to poke skeggsb more often
12:12bsper: The state seems to be reflected on the AC line, and there's an asterisk by the chosen pstate. So that seems to work, neat
12:13RSpliet: karolherbst_: maybe send him a joint-weekly report of stuff he still needs to do. Rather concentrate than constantly distract ;-)
12:13moongazer: imirkin, pmoreau ?
12:13pmoreau: moongazer: There are probably a few differences in the video engines between Kepler and Maxwell. I don't know how much though.
12:14karolherbst_: RSpliet: or maybe this problem will solve itself anyhow at some point
12:14moongazer: Okay, I got to wait for imirkin
12:16moongazer: pmoreau, Description: RE the mechanism for video decoding in VP6 (the video engine iteration used in GM10x chips). Implement support for driving the engine.
12:17moongazer: Where do I find the codebase for this
12:17pmoreau: RSpliet: Patchwork could work to list outstanding patches waiting for review, might need some cleanup.
12:18RSpliet: moongazer: it doesn't exist. that's the problem. Earlier generations are part of the Linux kernel and mesa.
12:18RSpliet: pmoreau: yeah that might automate the weekly report thing ;-) Although it doesn't help with collaboration on things like clk-devel
12:18RSpliet: I guess that's my problem more than anyone else's
12:18pmoreau: moongazer: In Mesa, you can look for VP3 here: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau
12:19moongazer: RSpliet, what doesn't exist?
12:20RSpliet: moongazer: code for the VP6 video engine
12:20moongazer: RSpliet, that is what I have to make
12:20RSpliet: yes ;-)
12:20pmoreau: RSpliet: clk-devel?
12:21RSpliet: pmoreau: pardon, devel-clk, Ben's dev tree for DRAM reclocking
12:21moongazer: RSpliet, I am confused so as how to start doing anything related to it
12:22pmoreau: RSpliet: I would have asked the same about devel-clk :-D
12:23pmoreau: RSpliet: Looking at accepted patches for Nouveau on patchwork, there are only two of mine, which I manually set to accepted :-D https://patchwork.freedesktop.org/project/nouveau/patches/?submitter=&state=3&q=&archive=both&delegate=
12:25pmoreau: moongazer: I am not enteriely sure, but you would probably look at how it worked for VP3, to get an idea of what is happening. Then you encode a small video using the NVIDIA driver while tracing it. After that, you look through the trace to see what the NVIDIA driver did, you implement it for Nouveau.
12:25RSpliet: moongazer: these projects aren't for the faint of heart. "reverse engineering" is an important skill to have before you can embark on a project like this. We don't have a programming manual to follow that will guide you through the implementation...
12:26pmoreau: Finally, you try encoding the video using Nouveau, decode it with another decoder and check that the output from the decoding matches what you gave to the encoder.
12:26RSpliet: pmoreau: I'd be happy if patches get plucked from the nouveau ML (tricky, because it gathers various projects...), we might have to refine patchwork for Ben's workflow
12:27moongazer: pmoreau, RSpliet That is fine.
12:27RSpliet: I'm sure it'd help if he has a todo list that updates itself
12:27moongazer: I will try the mailing list to get more help and ask more specific questions
12:28pmoreau: RSpliet: Yeah, a todo list could be nice. Or some WIP branches, rather than seeing series appear on his master branch.
12:29RSpliet: pmoreau: everyone can manage their own github fork as a WIP branch. devel-clk is one such branch
12:29RSpliet: (but requires a bit of effort from Bens side to keep pushing WIP stuff, it's out of date to a point that I can't work with it properly right now)
12:30RSpliet: it's a bit of a niche problem though, Ben does tend to be the only kernel dev 99% of the time, so forcing him into different workflows for the 1% might be a stretch to ask
12:30RSpliet: (or is this a chicken-and-egg problem...? ;-))
12:31pmoreau: In most cases, probably not
12:38imirkin_: moongazer: based on your questions, i doubt you're in a position to tackle the project
12:39imirkin_: moongazer: this is a medium-to-high difficulty project
12:39imirkin_: it would require a student of fairly exceptional abilities to do during the GSoC period
12:39moongazer: imirkin_, Sorry:( I know that my questions were totally stupid and I asked them in a hurry. But I think if I research enough and get the guidance, I can do it
12:40imirkin_: moongazer: your premise is that this is a homework assignment. there's a teacher somewhere who has the answer but won't give it to you.
12:40imirkin_: however the reality is somewhat different - this is more of a research project.
12:40imirkin_: in order to provide guidance, i'd have to do the project myself
12:40imirkin_: which would somewhat defeat the point of someone else doing it
12:41imirkin_: we can point you at tools that we use/etc
12:41imirkin_: having RE'd VP2 and helped iron out a few things with VP3, i'm reasonably well placed to know what's required to do such a project
12:42imirkin_: the steps are basically: (a) trace kernel operations under blob, (b) trace userspace operations under blob, (c) write enough nouveau kernel support to bring up the engine and (d) write a test program that decodes a frame.
12:42imirkin_: after you hit step (d) things get pretty easy actually
12:43imirkin_: the steps after that are basically to get mesa up and running with it
12:43imirkin_: i've been led to believe that the actual interchange format is pretty similar between VP3 and VP6
12:43imirkin_: if not identical
12:44moongazer: imirkin_, that is what I am looking for, the steps, the tools, where to learn the skills required etc
12:45moongazer: imirkin_, I have not worked in this field earlier, so I have not idea about it
12:47moongazer: imirkin_, where do I start reading
12:56moongazer: imirkin_, what do you do here?
13:09imirkin_: reading what?
13:09imirkin_: envytools has an assortment of tools
13:09imirkin_: mmiotrace will be useful, as will valgrind-mmt
13:13gnarface: moongazer: you know how to code in C, right?
13:18moongazer: gnarface, Yes, I am pretty good at C.
13:18moongazer: gnurou, github.com/universecoder/Horus-Chess-Engine
13:18moongazer: gnarface, *
13:18moongazer: That's C++ though
13:22gnarface: just making sure
13:25moongazer: gnarface, What were you about to tell me?
13:25moongazer: gnarface, tell me; how do I go about reverse engineering it
13:31gnarface: i was not about to tell you anything, i was just trying to figure out where you were starting from
13:38moongazer: gnarface, errr
13:42gnarface: moongazer: i guess i would have told you to learn about gcc
13:43gnarface: and maybe download the kernel source
13:46moongazer: gnarface, yeah I have been using gcc for 3 years now
13:46moongazer: gnarface, kernel source?
13:51gnarface: you know
13:51gnarface: apt-get source linux-image-amd64
13:51moongazer: That's ok. But for what?
13:51moongazer: gnarface, I mean for what purpose
13:52gnarface: just to look at drivers
13:54moongazer: gnarface, ok
13:54moongazer: Got to go now
13:54moongazer: I will try researching stuff and also look at the other projects
13:54moongazer: Got to go now
15:23imirkin_: hakzsam: did you ever end up providing some docs for the various bindless things?
15:23imirkin_: hakzsam: do you figure it's something i can implement in an hour or two? [on nouveau]
15:33hakzsam: imirkin_: I added some gallium docs yes
15:33hakzsam: not sure if it's doable in two hours though :)
15:49imirkin_: hakzsam: hm... ok. what do you expect won't work out of the box?
15:49hakzsam: nothing, but 2 hours seem short
15:50imirkin_: hakzsam: just create a texture and image bin, stick the resident handles into it
15:50imirkin_: and let the good times roll
15:50hakzsam: yeah, in theory but in practice :)
15:50imirkin_: hehe ok
15:50imirkin_: fair enough
15:50hakzsam: let me know if you start to work into it
15:50imirkin_: did someone want to take a stab at it? if not, i'll try it.
15:50hakzsam: eventually, but not before july...
15:51hakzsam: so, have fun :)
15:52hakzsam: imirkin_: btw, bindless is required for dow3
16:00dboyan: hakzsam: I saw your r-b on my perfmon patches. Do you think it proper to change type of matrics like ipc to float?
16:01hakzsam: should work
16:03dboyan: ok, I'll take a look and append that to my previous series. I'll also add some messages to previous ones. Probably tomorrow.
16:03imirkin_: dboyan: btw, heed mupuf's email
16:09dboyan: imirkin_, yeah I saw that, and currently working on it. Should be done soon
16:12imirkin_: dboyan: cool
16:12imirkin_: just making sure you saw it
17:03bsper: Hey, stupid question, but is it the drivers (software) or the hardware (BIOS/firmware/whatever) that turns off the computer if the card gets too warm?
17:08imirkin_: bsper: most modern GPUs have overheating protection where they just take themselves off the pcie bus past a certain temp
17:09bsper: imirkin_: Thanks
17:09imirkin_: no protection is perfect of course
17:09imirkin_: laptops tend to have GPU fans that are controlled by the EC rather than the GPU directly
17:10imirkin_: the drivers are meant to take preventative measures to avoid overheating as well
17:10imirkin_: although nouveau has no such thing
17:11bsper: Ah, I see. Is it a WIP to get such countermeasures?
17:11bsper: Or on the to-do list?
17:11imirkin_: all depends how one defines 'in progress'
17:11imirkin_: but basically no, it's on a wishlist/todolist
17:12imirkin_: that no one is tasked with getting to the end of :)
17:16bsper: Awh. Well I'm impressed by how far the project has gotten
17:16imirkin_: it's not bad, but hardly a bastion of perfection. and unfortunately very easy to compare to the golden standard in video drivers...
17:43mooch2: mwk, do you know of anybody who knows how the windows nv3 drivers work?
17:43mooch2: or the windows nv4 drivers, that'd be good too
17:44imirkin_: they execute series of instructions on the host cpu?
17:45mooch2: you know what i mean <.<
17:45mooch2: like, i need to figure out why the current drivers fuck up before rendering anything
17:45mooch2: interrupts seem to be working okay
18:33imirkin_: mooch2: this is with an emulated gpu right?
18:33imirkin_: if so, just make a log of everything
18:33mooch: i did
18:34mooch: it just stops after setting up some interrupts and reading from the crtc port
18:34mooch: i have no fucking clue what's going on
18:34imirkin_: it's likely due to the responses you're giving to the various queries
18:34mooch: it also tries to read the EDID, which i don't emulate yet
18:34mooch: because i2c is complicated and shit
18:35imirkin_: ok, well you should emulate failing to return things
18:35imirkin_: like what happens when there's no edid
18:35mooch2: how does that work?
18:36imirkin_: no clue
18:36imirkin_: there was a time before 1996 though
18:36imirkin_: i remember it as though it was yesterday :)
18:36imirkin_: monitors didn't have EDIDs
18:36mooch2: i was born in 1998 lol
18:37karolherbst: imirkin_: fun times
18:37imirkin_: you youngin's
18:37karolherbst: hey. my actual first computer was an atari ST 1040
18:54hakzsam: imirkin_: is bindless done? :)
18:54imirkin_: hakzsam: haven't even so much as looked at it
18:54imirkin_: i wasn't planning on doing it now... work ... etc
18:54hakzsam: sure, no rush
19:05mooch2: imirkin_, how does edid reading work exactly?
19:05mooch2: like, at i2c port 0x50, how does reading that work?
19:15imirkin_: mooch2: do you know what i2c is?
19:15mooch2: i've got it mostly implemented
19:15mooch2: except i don't know how reading the eeprom works
19:15imirkin_: so ... it's the "chip" at address 0x50
19:15imirkin_: and you can send reads (or writes)
19:15imirkin_: (since the idea of i2c is that you can have multiple chips on a single bus)
19:16mooch2: yeah but how do you read at a specific address on the chip?
19:16imirkin_: iirc you send a write with the address
19:16imirkin_: and then you send a read
19:16imirkin_: but i don't 100% remember
19:16imirkin_: you'd have to check
19:17imirkin_: i suspect reading some linux kernel helpers for i2c would also be instructional
19:17mooch2: no i mean like
19:17mooch2: the eeprom specifically
19:17imirkin_: the eeprom is what's sitting on that i2c bus
19:18imirkin_: with some standard chip id
19:19mooch2: yeah but how do you read from it
19:19imirkin_: look at that function.
19:20mooch2: i think that answers my question. thanks
19:20mooch2: but just to clarify
19:21mooch2: you write the address to the chip addr, then you read the contents of the chip?
19:21mooch2: does it auto-increment?
19:30mooch2: thanks imirkin_
19:34moongazer: imirkin_, I am downloading the codebase now
20:19moongazer: Reading https://nouveau.freedesktop.org/wiki/InstallNouveau/ Out of the kernel compilation
20:19moongazer: https://paste.ofcode.org/NMaWNUJxVDjJ3PGn9XtdTs got this error I thought the linux/ directory was not required, since it's an out of the kernel compilation?
20:23moongazer: Anyone there?
21:18pmoreau: moongazer: No, the kernel source are still required for the out-of-tree module, as Nouveau relies, for example, on calls to the ACPI API, or the DRM one, which are not part of the out-of-tree module.
21:20pmoreau: With having the out-of-tree module though, you only need to compile the kernel once, and change Nouveau multiple times without having to re-create a kernel image each time you made a one line change in Nouveau.