00:14Hijiri: My friend told me that there is fermi reclocking support in kernel 4.10, is that true?
00:20nyef: Hijiri: From about six hours ago: <imirkin_> currently there's reclocking support for nv4x, GT21x, GKxxx, and GM10x <imirkin_> oh, and G94-G200 <imirkin_> although that's less-well-tested
00:21Hijiri: nyef: ok, thanks
00:21nyef: You might try a 4.10 and see if it works, and if it doesn't feel free to pitch in to get it working for 4.11 or 4.12 or so.
00:23Horizon_Brave: anyone using Debian Stretch?
00:24Hijiri: I am
00:24Hijiri: nyef: I don't think my card is in that list
00:24nyef: Hijiri: My GF119 also isn't in the list, but my current priority isn't getting reclocking working for it, unfortunately.
00:25Horizon_Brave: for amd64 by chance? what kernel is it on right now? 4.9? when it goes stable is it going to remain at 4.9?
00:25Hijiri: Horizon_Brave: I think stretch is meant to be 4.9
00:25Hijiri: I'm going to hop on the next testing anyway
00:25Hijiri: whenever that is
00:26Hijiri: nyef: I might have asked in this channel before, but what are the most important parts of the "IntroductoryCourse" wiki page to read to get started with driver development?
00:27imirkin: Hijiri: your friend lied to you, maliciously.
00:27nyef: I... don't know? I also don't know how up-to-date the wiki is.
00:27imirkin: Hijiri: that said, someone has been playing around with it a bit, but it will most likely not work on your board
00:28imirkin: nyef: when in doubt, not very.
00:28nyef:is still fairly new here.
00:28Hijiri: oh, ok
00:28Hijiri: are there other resources I should check out then?
00:28Horizon_Brave: wow..didn't just lie to you...he lied maliciously..that's serious stuff guy
00:28imirkin: what are you looking for?
00:28Hijiri: I want to help with reclocking support on Fermi
00:29imirkin: your best bet is to talk to RSpliet who has been working on it on and off for the past ... 2 years?
00:29imirkin: that seems like a lot. maybe more like 1?
00:29Hijiri: sounds like a tough problem
00:29imirkin: his super-duper experimental tree is available at https://github.com/RSpliet/kernel-nouveau-nv50-pm -- i believe it kinda-sorta works for one of his boards.
00:30imirkin: unfortunately there's no "easy 5-step guide to getting reclocking working". if there were, the person writing the guide would have just done it :)
00:32nyef: Looks like a year and a half?
00:32Hijiri: should I just ping him on IRC?
00:33dboyan_: imirkin: Bad news. I did see misrenering with disk cache enabled.
00:34dboyan_: It was in Portal 2, when I looked into one of the portals, it displays thing at the back of that portal
00:34dboyan_: Any idea how I should debug that?
00:35imirkin: Hijiri: yeah, that's good. he doesn't have a ton of time to work on it... he's busy with ... work? postdoc? i haven't kept up =/
00:35imirkin: dboyan_: good news - i have a trace of that, from when we had a little oopsie on nv50
00:35imirkin: (bad news - i haven't the faintest clue where it is)
00:36imirkin: aha! i think i found it.
00:36Horizon_Brave: lol...a little oopsie...
00:36Horizon_Brave: sounds like an interesting story...?
00:37Hijiri: RSpliet: How would I help with adding reclocking support to Fermi? I've never done kernel development, which would probably be a problem, but I do have a GF114
00:37imirkin: not really. just a bug.
00:39imirkin: Hijiri: mostly it takes an incredibly amount of patience, access to hardware, and lots of tracing/analysis.
00:41Horizon_Brave: you lost me at patience....
00:41dboyan_: imirkin: http://imgur.com/Qemfd1g and http://imgur.com/fOn9nQB
00:41dboyan_: It only happens at some portal.
00:43imirkin: do you have a trace?
00:44dboyan_: wait a minute
00:44imirkin: i don't want it
00:44imirkin: just asking if you do :)
00:47imirkin: if you don't - make one, find the relevant draw call where it messes up, and figure out the diff between the shader cache case, and the non-cache case
00:51dboyan_: I just made one. 640M in size...
00:51imirkin: ok, mine's still uploading =/
00:56dboyan_: imirkin: Do you think it has anything to do with fixups? That's where I suspect most
00:56imirkin: it's unlikely - the fixups VERY rarely do anything
00:56imirkin: although tbh i don't fully remember what they are
00:57dboyan_: or maybe flags or headers?
00:59imirkin: that's more likely.
01:00nyef: When I'm passing a bag of bytes (or two) through nvif, should I be padding out to a 32-bit boundary?
01:00dboyan_: I think it's about the very same tgsi ends up in different program binaries, and I forget to take something into account
01:01imirkin: nyef: that's a question for skeggsb, who's not around. take a look at the nvif_unpack macro, that should yield some hints.
01:01imirkin: my suspicion is that "no", but i'm not sure.
01:01imirkin: dboyan_: could be. if you like, i could look at your code if you clean up your commits a bit
01:01imirkin: perhaps i can spot the issue
01:04dboyan_: gotta go now, I'll dig into that later
01:05Horizon_Brave: imirkin: is what you just described a very general way that you guys actually develop drivers for prop. hardware and fireware?
01:06nyef: Ah well, I'll just add the question to the cover notes once I get that far.
01:21imirkin: Horizon_Brave: what description are you talking about?
01:24nyef: ... patience, hardware, and tracing/analysis?
01:24imirkin: that's how you RE things
01:25imirkin: you develop drivers against undocumented hw very much like you do against documented hw... except you also have to write the docs.
01:26imirkin: [or gain the same level of understanding as you would from reading the docs]
01:26nyef: There's also poking at the hardware registers to see what effect they have, which is a bit more intercessory than mere trace analysis, but yeah, that's RE.
01:26nyef: Heh. As if docs are ever complete and accurate. (-:
01:42imirkin: nyef: hm, "define:intercessory" isn't coming up with anything useful. care to edify?
01:49nyef: How about "intercede"?
01:51nyef: Intercessory isn't quite the right word, because it's "on behalf of another", but... Basically, poking about to see how the hardware responds to input not necessarily in the trace file.
02:20Lyude: this is turning out to be a challenging rectangle
02:58nyef: Okay, the changes for the v2 patch series are now in my working tree, compiled, and partly tested. Progress!
02:59nyef: Still have to finish testing and get everything squared away as a proper (revised) commit series, and possibly make another attempt to figure out the frame-packing thing, but still, progress. (-:
03:29Horizon_Brave: So... poking around my /lib/firmware directory... I noticed some manufacturers firmware is in .fw format (like b43 ) and other's are in .bin format like Radeon, RTL etc.. what's the difference? are both used as firmware but just written in different languages?
03:30nyef: Horizon_Brave: They're just different file extensions.
03:30nyef: The actual format is dependent on the driver and the hardware.
03:31Horizon_Brave: hmm I see, so it's pretty much arbitrary, but more so about what it's being used by..
03:31nyef: ... And I have a lead on the frame-packing stuff! But now is not the time to chase it down. /-:
03:54Horizon_Brave: Okay...here's one... I notice that on my Debian system, the nouveau driver is a .ko..kernel object...but from what I can tell, there is no firmware files for it. Most of the files are in /lib/modules/kernel/<version>/etc.. So this means that these are rolled up in the kernel... but the other .fw and .bin firmware bits are in /lib/firmware, the difference is that these are put into the debian package but not in the kernel righ
03:54Horizon_Brave: these individual firmware files?
03:55Horizon_Brave: and the 2nd part is.... why nouveau gets the special treatment of being directly implemented into the kernel? and not AMD? (not that I"m complaining around these parts.. just curious lol)
03:59nyef: There are *two* AMD kernel drivers.
03:59nyef: Possibly more.
04:00nyef: And most (all?) of the AMD cards require firmware.
04:01Horizon_Brave: right... well in the case of this specific instance, from what i can see here... there are no nouveau firmware files that I can see...
04:01Horizon_Brave: just the nouveau .ko files
04:01Horizon_Brave: unless they're named as something more obscure
04:03dboyan_: Horizon_Brave: Nearly every gpu driver are devided into 2 parts, the kernel driver part and the userspace parts
04:03dboyan_: They handle different tasks
04:03nyef: And there are typically at least two userspace parts, aren't there?
04:03dboyan_: which two?
04:04nyef: The mesa driver and the X11 driver.
04:05dboyan_: yep, but they are different things
04:05nyef: Sure. One does the 3D bits, the other does some 2D bits and mediates with the X server.
04:06dboyan_: Horizon_Brave: For gm200+, the firmware lives in the nvidia/ directory of the linux-firmware package.
04:08Horizon_Brave: dboyan_: ehh...what am I looking at here..?
04:08dboyan_: Horizon_Brave: And for previous generations, the firmware are in kernel tree, with assembly in .fuc suffixes
04:09dboyan_: Horizon_Brave: The firmware released by nvidia (gm200+) has .bin suffix
04:12Horizon_Brave: what you're talking about, and what you linked to...thes are the official nvidia drivers? the non-free ones? or the nouveau ones developed here?
04:14dboyan_: Horizon_Brave: They are for the nouveau driver. gm200+ need firmware from nvidia because of signing
04:15dboyan_: Horizon_Brave: If you want to see what firmware look like in previous generation (the free and open ones). You can take a look at e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/engine/gr/fuc directory.
04:19Horizon_Brave: oh wow, so that means that nvidia actualy did provide free and open firmware in the past?
04:20dboyan_: No, those free ones are reverse engineered
04:20nyef: No, it means that some people are really, REALLY good at reverse-engineering.
04:20Horizon_Brave: lol oh
04:21Riastradh: ...and then NVIDIA started verifying signatures on firmware...
04:21Horizon_Brave: silly me, thinking nvidia would do good...
04:22Riastradh: So even the really good reverse engineers can't make their own firmware for newer hardware models any more.
04:22Horizon_Brave: ohhh so that's why they sign their firmware... to make sure that the firmware being pushed onto the card/device is authentic and not reverse engineered?
04:22nyef: Is authentic and not malware.
04:23dboyan_: at least what nvidia says "not malware"
04:23Riastradh: There's a security rationalization about malware. Doesn't justify preventing users from installing their own verification keys, though...
04:23nyef: Well, yes. And there's also the possibility that someone manages to get their paws on the signing keys.
04:24Riastradh: Classic defective-by-design digital restrictions management here.
04:24Riastradh: Could happen. So far I haven't heard of any indication that they've pulled a Sony and misused the signature scheme in a way that reveals the private signing key, but then I haven't been looking closely either.
04:30Horizon_Brave: hmm alright, thanks guys, makes more sense. Thanks Riastradh, dboyan_ and nyef
04:31nyef:suddenly wants a NuBus nVidia card.
04:31Riastradh: Do such things exist?
04:32nyef: Almost certainly not.
04:32Riastradh: Are you going to put one in your Frankenstein's monster of a mac68k-lispm?
04:32nyef: Hey! I don't have the lispm bits for it yet. d-:
04:33nyef: (The MacIvory 2 is supposed to arrive tomorrow.)
04:33Riastradh: Awww. I still have an Alpha sitting around that I haven't tried running OpenGenera on.
04:33nyef: Of course, the board that I really want for it is a microExplorer.
04:36nyef: I also need to decide if I'm going to try putting the board in my Q800, or if I'm going to use my IIfx.
10:31kattana: all ppl wasted saturday morning :/
12:52dboyan: imirkin: I've pushed my shader cache branch at https://github.com/dboyan/mesa/tree/nouveau-cache
12:53dboyan: imirkin: And I also uploaded a trimmed apitrace https://people.freedesktop.org/~dboyan/apitrace/portal2.trace.xz
13:05dboyan: imirkin: Difference can be seen, for example, at call 651538, where it is drawing things behind the opposite portal. They don't appear in correct rendering, but show up (winning depth test) after shader cache is enabled.
14:17nyef: Okay, rough plan for the stereo patches for the kernel: Get my working tree and branch sorted out into a coherent set of (revised) commits. Test against the gt215 and gk104 DISPs. Defer posting the patch series until skeggsb is known to have returned. In the mean time, possibly try to get frame-packing to work.
14:59imirkin: nyef: sounds like a plan. weren't you going to try to get gf119 too? or did that not pan out?
14:59imirkin: (or "one thing at a time")
15:00nyef: G84 and GF119 are tested and working.
15:03nyef: Even made sure that HDMI audio didn't break while in 3D mode on GF119.
15:03nyef: Can't do much for G84 HDMI audio at this point, though. /-:
15:04imirkin: assuming you don't have the spdif hookup thing?
15:04imirkin: should just be a cable from your mobo's audio chipset to the gpu
15:04imirkin: it's like a 3-pin header somewhere
15:04imirkin: ideally marked S/PDIF :)
15:04imirkin: but sometimes marked C75
15:05nyef: Haven't tracked down the pinout information to know which end is ground on each card, and I'm trying to clear the worst of my queue before my new toy arrives today.
15:06imirkin: oh, speaking of toys, the fx3700 is mine. ideally i'll have a G92 showing up, might play with the VP2 stuff on it.
15:11imirkin:hopes it'll fit in my case
15:13nyef: Always a concern, right?
15:14imirkin: esp for me... this is a large case, but a lot of that goes towards HDD housing
15:14imirkin: (used to have a 4x 2TB RAID5... now 2x 8TB RAID1 :) )
15:28dboyan: imirkin: Any idea how I can debug my problem?
15:28dboyan: Now that I found one of the problematic calls, but I just wonder why the correct rendering is correct
15:28nyef: Okay, everything synced up except for one commit message that needs to be rewritten and one commit which needs to be dropped. Good enough for a build-and-test cycle.
15:28imirkin: dboyan: did you look at the shaders being used for that call (by nouveau)
15:28imirkin: dboyan: and then compare & contrast?
15:30dboyan: I just wonder what should I compare it with
15:30imirkin: the code being uploaded to the gpu
15:32dboyan: I haven't done that, and I'm a little bit concerned if I can single out one shader from hundreds of them
15:35nyef: ... smoke test passed, gf119 still works.
15:37imirkin: dboyan: add a thing that prints the shaders CURRENTLY being used
15:37imirkin: rather than as they're being uploaded
15:41dboyan: imirkin: yeah, I'll try to do that
16:25nyef: ... Broke GT215 HDMI audio. Lovely. /-:
16:49user51: I'm sorry for the 'search it yourself' question, but I can't find ANYTHING on overclocking my GPU. I'm using an nvs140m.
16:51MichaelLong: user51, why do you have the impression that overclocking is a topic at all for nouveau? be lucky if you own a card that can reach its standard clocks to begin with.
16:53user51: MichaelLong: Just trying to squeeze some more performance from my old thinkpad.
16:55user51: In all fairness, I was a little worried when I had a nvidia chip on it, but it works surprisingly well.
16:56MichaelLong: user51, yeah my nvidia-chip was working quite ok but only using the lowest (initial) clock-configuration. but the basics worked
16:57dboyan: user51: Maybe you are interested in reclocking
16:58user51: dboyan: I'm not aware of any program that dynamically reclocks my GPU as needed.
16:58user51: But if you know, a recommendation would be helpful.
16:58dboyan: user51: You have to manually reclock with nouveau for now
16:59nyef: ... and the test gk104 system isn't on speaking terms with the HDMI. /-:
16:59user51: dboyan: man nouveau doesn't have anything about it, perhaps I missed something?
17:02dboyan: user51: If you have a 4.5+ kernel, you can reclock using /sys/kernel/debug/dri/<id>/pstate
18:34Rumple: Does nouvea support NVML?
18:35imirkin: well that's all highly unfortunate. looks like this NV44A never worked, or at least not with the kernels i had lying around =/
18:40imirkin: mwk: i think i need your help on this one :) let me know if you have any advice for getting a NV44A/PCI going. The FIFO doesn't seem to be able to access the commands properly.
18:40imirkin: mwk: perhaps i can use your hwtests to experiment with it? i assume you're submitting fifo commands and whatnot?
18:41Horizon_Brave: afternoon folks, hey imirkin
18:54mwk: imirkin: hwtests don't submit fifo at all atm :(
18:54mwk: except some nv1 tests, but that's not applicable to NV44A
18:55mwk: all the pgraph tests just stuff the commands through FIFO bypass regs on pgraph
18:55imirkin: mwk: doh :( any opinion on what could be going wrong, assuming that NV44A + AGP works ok with nouveau?
18:55mwk: well... anything, really
18:55imirkin: it's saying INVALID_CMD
18:55imirkin: and the get address is 0
18:55imirkin: which seems ... like something's misconfigured.
18:56imirkin: (the put address is like 0x100, so it's at least consistent)
18:56imirkin: [ 8.822107] nouveau 0000:09:00.0: fifo: DMA_PUSHER - ch 0 [DRM] get 00000000 put 00000178 state 80000000 (err: INVALID_CMD) push 00000000
18:56mwk: and what's the memory type for the pushbuf dma object?
18:56imirkin: oh right - it's GART. forcing it to vram allegedly makes it work
18:56mwk: what GART
18:56mwk: 2 or 3?
18:57imirkin: "above my paygrade"
18:57mwk: there's a possibility something's off about GART handling on NV44A
18:57mwk: since it's sorta AGP, but really a h4xed NV44 PCIE core
18:57imirkin: /* allocate memory for dma push buffer */
18:57imirkin: target = TTM_PL_FLAG_TT | TTM_PL_FLAG_UNCACHED;
18:57imirkin: if (nouveau_vram_pushbuf)
18:57imirkin: target = TTM_PL_FLAG_VRAM;
18:58imirkin: (and nouveau_vram_pushbuf is false as you might imagine)
18:58mwk: it may be worth a try to disable AGP GART and use PCI sg instead
18:58mwk: ie. DMA object mem type 2 instead of 3
18:58imirkin: this is a PCI board
18:59mwk: that's an even better reason to make sure it's not using AGP accesses
18:59imirkin: well, i'm pretty sure that's disabled
19:00imirkin: pci_is_pcie(pci_dev) ? NVKM_DEVICE_PCIE :
19:00imirkin: pci_find_capability(pci_dev, PCI_CAP_ID_AGP) ?
19:00imirkin: NVKM_DEVICE_AGP : NVKM_DEVICE_PCI,
19:00imirkin: so it should be ending up with NVKM_DEVICE_PCI
19:00imirkin: i guess i didn't check that explicitly
19:01imirkin: i see no mention of agp - https://hastebin.com/tuyezamehe.cs
19:09jamm: hi imirkin: i saw a task posted on trello "Update maxwell shaders with proper delays" I was wondering how one would go about updating them? I see a lot of assembly code at /xf86-video-nouveau/tree/src/shader but being new to graphics drivers in general, especially DDX, I'm kinda lost :/
19:10imirkin: jamm: it says (st 0x0) now. it should have proper delay flags in there for maor fps
19:10imirkin: jamm: the fact that this is the ddx is largely irrelevant
19:11imirkin: just ... need to update the shader assembly with proper scheduling info
19:11imirkin: (only the gm107 ones - the rest are fine...ish)
19:11imirkin: mwk: so ... it what is this gart 2 or 3 thing you were talking about? is it this?
19:11imirkin: case NV_MEM_TARGET_PCI:
19:11imirkin: dmaobj->flags0 |= 0x00023000;
19:12imirkin: case NV_MEM_TARGET_PCI_NOSNOOP:
19:12imirkin: dmaobj->flags0 |= 0x00033000;
19:12imirkin: (and AGP -> PCI_NOSNOOP)
19:12mwk: imirkin: yes
19:12mwk: where is that?
19:13imirkin: mwk: usernv04.c
19:13mwk: 2 is PCI, so it's fine... but it also seems to be setting the linear bit, which is worrying
19:13imirkin: for pushbufs, you wouldn't want the linear bit?
19:13mwk: not on PCI cards
19:14imirkin: ok, well it definitely does work on *some* PCI cards
19:14mwk: VRAM objects are not paged, so linear is good; AGP GART objects are paged via, well, the GART
19:14mwk: but for PCI objects, you need the card to do the paging
19:15imirkin: this is an area of the GPUs i know nothing about
19:15imirkin: is there something in the hwdocs about this already?
19:15mwk: probably not
19:16mwk: yeah nothign
19:16imirkin: ok, but does the get address of "0" make sense? since it's relative to the start of the dmaobj?
19:17mwk: yeah, that sounds fine
19:18imirkin: ok. i guess i need to double-check whether it's really coming up as PCI and not secretly as AGP
19:18mwk: so it's not going through this code at all... well, shouldn't be
19:19imirkin: really? see nouveau_chan.c::nouveau_channel_prep
19:19mwk: yeah, but if base.target == NV_MEM_TARGET_VM, it sets the clone flag
19:19imirkin: right, which it is
19:19mwk: which will result in using the dmaobj set up by mmu, not making a new one
19:20imirkin: and that's set up by nvkm/submdev/mmu/nv44.c i believe
19:20mwk: but that'd be real bad
19:20mwk: as nv44 GART doesn't involve dma objects
19:21imirkin: .mmu = nv44_mmu_new,
19:21mwk: what if you change it to nv04?
19:21imirkin: that would take time. i can't reboot just now.
19:21imirkin: but i'll definitely try that
19:21imirkin: if (device->type == NVKM_DEVICE_AGP ||
19:21imirkin: !nvkm_boolopt(device->cfgopt, "NvPCIE", true))
19:21imirkin: i suspect that should instead be
19:21imirkin: if device->type != PCIE || ...
19:22mwk: ah :)
19:22mwk: seems to be our culprit
19:27imirkin: ok, i'll def give that a shot
19:27imirkin: presumably same deal for nv41
19:28mwk: there shouldn't be any AGP/PCI device using nv41 mmu in the first place
19:28imirkin: or are those more likely to be PCIE -> PCI chips
19:28imirkin: yes to what
19:29mwk: that could be triggered by PCIE -> PCI chips
19:29mwk: so yeah, same for nv41
19:29imirkin: and so then you'd want ... the PCI logic or the PCIE logic?
19:29mwk: I think
19:29mwk: but I'm not really sure
19:29imirkin: well, i'm sure it's quite rare
19:30mwk: if the MMU is on the GPU, there's really no reason why it shouldn't cooperate with a bridge chip
19:30mwk: I mean, MMU or not, the card does a PCIE read/write cycle either way
19:31imirkin: oh, but with a bridge chip
19:31imirkin: it'd come up as a PCIE device, not AGP/PCI
19:31mwk: I guess NV44A could just be special, since it's really a different chip than NV44
19:31mwk: no, the other way
19:31mwk: without bridge, NV41 is PCIE; with a bridge, it comes up as AGP/PCI
19:31imirkin: transparent bridge... ugh
19:32mwk: so the bridge will convert the PCIE transaction to a PCI/AGP transaction
19:32mwk: why would it care whether it came through MMU on the card or not
19:32imirkin: ok. so ... probably nv4a is just weird?
19:32mwk: that's likely
19:32imirkin: i'll buy that
19:36jamm: imirkin: ah, i see sched 0x0's in the *nv110.fp assemblies. I'm new to GPU assembly, but have worked on x64 assembly on nasm before. Any references you could point me to understand GPU assembly better? I remember AMD having some of their references hosted on their site, not sure about nvidia though..
19:37jamm: Also, this might be a silly question, but do I need a maxwell GPU to be able to test/run this? I have a pascal GPU with me ATM
19:43imirkin: a pascal GPU will do just fine, but will require you to bring up pascal in the DDX. should be easy enough.
19:43imirkin: the "correct" sched codes will be based on an understanding of instruction latencies and whatnot
19:43imirkin: some of this knowledge is encoded in nv50_ir_emit_gm107.cpp in mesa
19:44imirkin: the rest of it is inside hakzsam's head, although i doubt he'll let you open it up for deeper analysis
19:47nyef: "It is easier to obtain forgiveness than permission." d-:
19:57jamm: imirkin: well, i'm ready to take up this quest of knowledge ^_^
19:58jamm: i'll look into nv50_ir_emit_gm107.cpp. I'll take a nap now since it's like 5am in japan and i probably have to force myself to sleep, no idea why XD
20:03pmoreau: jamm: Here is some reading regarding scheduling, for when you wake up: https://github.com/NervanaSystems/maxas/wiki/Control-Codes
20:08nyef: At least it's not a correctness issue, right?
20:08nyef: Or is it?
20:10imirkin: nyef: (st 0x0) makes it delay 15 cycles
20:10imirkin: that might not be enough for texture fetches, but ... hopefully ...
20:10imirkin: bbl. testing out the nv44a theory.
20:14imirkin: mwk: w00t! it worked!
20:28imirkin: so why did i want this in the first place? i forget :(
20:29nyef: Because you were out of PCIe slots, but had an open PCI slot?
20:30imirkin: no... that's a means to an end... i wanted a nv4x.
20:30imirkin: [but not badly enough to sacrifice a pcie slot]
20:44imirkin: if i have a DB9 male <-> DB9 female adapter, that's *most likely* a null modem rx/tx line switcher thing, right?
20:46Riastradh: Hmm. Aren't those usually male<->male?
20:47imirkin: so why does this thing exist then?
20:48imirkin: under what circumstances would you want a male <-> female adapter
20:48imirkin: it's not a cable, it's like a hard thing that's about 2" long
20:49Riastradh: No, never mind, your guess is probably right.
20:49Riastradh: My DB-25 null modem is a male<->female.
20:55Riastradh: https://mumble.net/~campbell/tmp/20170318/assembly.jpg https://mumble.net/~campbell/tmp/20170318/disassembly.jpg
20:55imirkin: mine's thinner.
20:56Riastradh: That's my magic nouveau debugging serial console wand, since I couldn't find a DE-9 null modem when I last went looking, but I did happen to have two DB-25/DE-9 adapters handy.
20:56imirkin: anyways, this is excellent. i've been missing a null modem thingie.
21:04Riastradh: `Null modem? Gee, I dunno, I think all we have are Comcast ones.'
21:21imirkin: i'm going through a box-o-stuff, where i found it, also found a 56k pci modem. good times.
21:21imirkin: (probably a softmodem, although equally likely that it was one of the few that worked on linux)
21:35imirkin: mwk: you got any nv41+ PCI boards (that aren't nv4a)?
21:36mwk: imirkin: GF119, curiously enough
21:36mwk: other than that, no
21:37imirkin: mwk: hm ok. a little surprising about the GF119. i meant nv4x though ;)
21:42imirkin: i guess skeggsb might have one lying around... dunno.
21:50imirkin: airlied: this look familiar? looks like my gpu went into runpm and isn't coming back. this is not a system where runpm is an option... https://hastebin.com/inozoyasod.go
21:51imirkin: airlied: i'm running a bit of a frankenkernel - 4.10.4 + all of ben's patches for 4.11.
21:51imirkin: i think it's stuck on the NV4A gpu, at least based on the xorg log
22:21airlied: imirkin: strange might be a bad pm hook
22:21imirkin: airlied: for now i've booted with nouveau.runpm=0
22:41imirkin: airlied: i can test patches if you have any concrete ideas though
22:42imirkin: airlied: a little odd that anything of the sort would trigger on my system, since ... no ACPI, no nothing (related to these devices)
22:42john_cephalopoda: Is it possible to apitrace 32 bit applications?
22:47john_cephalopoda: Hmm, can't really get it to work.
22:47john_cephalopoda: It really bugs me, that I get small glitches in some situations.
22:48imirkin: ok... i assume you're using a 32-bit apitrace to trace 32-bit applications?
22:50john_cephalopoda: imirkin: Haven't compiled the 32 bit version yet. It's a bit tricky for me because I have no experience with cross-compiling.
22:50Calinou: easy way: compile from a chroot/systemd container
22:50john_cephalopoda: I was talking about general graphics glitches in some situations in 32 and 64 bit applications.
22:52john_cephalopoda: It's hard to trace them down to something.
22:53imirkin: john_cephalopoda: well, the thing ain't magic, it preloads a lib that hooks into the gl stuff. so it better match the ABI of the target application.
22:54john_cephalopoda: imirkin: Yeah, I know.
22:55pmoreau: imirkin: I have got that issue as well on my MBP (Kepler card), and there shouldn’t be any runpm going on either. It was with "vanilla" 4.10.1.
22:56pmoreau: It hasn’t happened recently though, not sure why.
22:56imirkin: are you using the other gpu? :)
22:57pmoreau: Well yes, but the error occured as I was using the IGD (IIRC)
22:58imirkin: pmoreau: btw, if it's not difficult, can you give me a 'glxinfo -l -s' for the kepler against mesa 17.0? (which i assume you have installed)
22:58pmoreau: I do, 17.0.1 to be precised
23:20imirkin: awesome thanks
23:21Megaf: Hi all, on recent kernels the nouveau driver began do often go nuts
23:21Megaf: [17391.808048] nouveau 0000:04:00.0: gr: 00000010 [ILLEGAL_MTHD] ch 6 [000f6b8000 systemd-logind] subc 2 class 502d mthd 0320 data 0000001c
23:21Megaf: this happens when wathing youtube videos, playing media or games
23:22Megaf: only way to stop the errors is a reboot after killing the X server
23:23imirkin: Megaf: anything else in dmesg?
23:23Megaf: just thousands of those lines
23:23imirkin: and which GPU?
23:24imirkin:doesn't see a method 320 for the 502d class... so i agree with the gpu...
23:24Megaf: 04:00.0 VGA compatible controller: NVIDIA Corporation MCP89 [GeForce 320M] (rev a2)
23:25imirkin: it does, however, exist in the copy class, which your gpu should have... interesting
23:26nyef: ... MCP89, huh?
23:26nyef: Mac Mini?
23:26Megaf: MacBook Pro Mid 2010 13"
23:26Megaf: aka MacBook Pro 7.1
23:26nyef: Ah, okay.
23:26nyef: Still, Mac.
23:26Megaf: pretty much so
23:26imirkin: apple was the only one to get that gpu
23:27Megaf: I believed it worked fine in some older version of 3.2.x
23:27Megaf: Linux aluminium 4.9.0-2-amd64 #1 SMP Debian 4.9.13-1 (2017-02-27) x86_64 GNU/Linux
23:27imirkin: well, my guess is you've also had some small little tiny changes in userspace?
23:28Megaf: OpenGL version string: 3.0 Mesa 13.0.5
23:28Megaf: imirkin: Fresh Debian install
23:28Megaf: Gallium 0.4 on NVAF
23:28Megaf: I think that's all relevant information
23:31imirkin: my main point was that blaming this on the kernel may be misguided
23:34imirkin: either way, nothing jumps out at me as an obvious cause. sorry.
23:42Megaf: imirkin: http://paste.debian.net/plain/922604
23:42imirkin: Megaf: oooooh
23:42imirkin: Mar 18 23:10:18 aluminium kernel: [16775.432355] nouveau 0000:04:00.0: fifo: DMA_PUSHER - ch 6 [systemd-logind] get 00200302f0 put 0020031454 ib_get 00000144 ib_put 00000155 state 8000ef05 (err: INVALID_CMD) push 00400040
23:43imirkin: so ... this is a fairly common error on tesla-era gpu's. unfortunately the cause is unknown.
23:44Megaf: anything to do with..
23:44Megaf: Mar 18 17:50:08 aluminium kernel: [ 4.662115] nouveau 0000:04:00.0: bus: MMIO write of 0000807f FAULT at 100c18
23:44Megaf: Mar 18 17:50:08 aluminium kernel: [ 4.745154] nouveau 0000:04:00.0: bus: MMIO write of 0000807e FAULT at 100c1c
23:44imirkin: [hmmm... i wonder if this is a lack of synchronization between switching fifo context and switching mmu context]
23:44imirkin: no, i think those are unrelated.
23:44imirkin: nyef: do you see those same MMIO write faults on your MCP89?
23:45imirkin: oh. huh. yeah. those come from mcp77_ram_init which has a workaround for MCP77/79. i guess it doesn't apply to MCP89?
23:46nyef: imirkin: I... don't do much with my MCP89 these days?
23:46imirkin: i think at the time we didn't test it on MCP89 since no one had one handy
23:46imirkin: and just assumed it'd be all good
23:46nyef: Well, other than building kernels and running intel-gpu-tools testdisplay.
23:47imirkin: nyef: does it show that on load?
23:47imirkin: [of the nouveau kernel module]
23:48Megaf: so indeed it was working and you broke it xP
23:48pmoreau: imirkin: According to NVIDIA (IIRC), the fix should not apply for MCP89
23:48imirkin: Megaf: not really broke, more like "added some errors that are printed on boot"
23:48imirkin: pmoreau: oh, so we should probably fix that, huh
23:48pmoreau: Let me have a look at the email
23:49nyef: Let me fire it up.
23:49karolherbst: imirkin: for hitman: total instructions in shared programs : 517553 -> 481872 (-6.89%), total gprs used in shared programs : 35576 -> 34235 (-3.77%)
23:49imirkin: of course nvidia tends to lie about things like this, but if in addition someone's seeing mmio errors, that's a pretty good indicator.
23:49imirkin: karolherbst: =]
23:49karolherbst: guess waht teh biggest change is
23:49imirkin: karolherbst: any improvement to perf?
23:50karolherbst: .... little
23:50karolherbst: avg fps: 6.09 -> 6.12
23:50nyef: ... Nothing. Only thing it bitches about at startup is hwmon_device_register().
23:50imirkin: hrm. ok. so *some* nvaf devices have those regs others don't? annoying.
23:51karolherbst: imirkin: this change improved instruction count by around 5.5%: https://github.com/karolherbst/mesa/commit/e64f0e546ed71860c7202840a67aad2fa64a3fc0
23:51pmoreau: imirkin: "The pollers exist on MCP77/78 and MCP79/7A", from https://lists.freedesktop.org/archives/nouveau/2014-November/019266.html
23:51nyef: This on 4.10.0 + local patches.
23:51imirkin: karolherbst: ship it :)
23:52karolherbst: imirkin: I already wondered: neg $r2 $r2; fma $r2 $r2 $r3 $r4... and I was like: mhhh, something is definitly wrong
23:52imirkin: nyef: yeah, that workaround went into kernel like 4.0 or so
23:52imirkin: if nto earlier
23:52karolherbst: imirkin: tomorrow or so. Sadly I have no internet access at my new home right now. Just tethering currently
23:52imirkin: karolherbst: it used to be that nothing generated OP_FMA. now it's reachable though.
23:53nyef: There's something about "using M2MF for buffer copies". Is that relevant?
23:53karolherbst: I also had to modify my postraloadpropagation pass
23:53imirkin: karolherbst: mail the patch, i'll apply it
23:53imirkin: nyef: i mena ... it's just informational.
23:53karolherbst: imirkin: https://github.com/karolherbst/mesa/commit/e64f0e546ed71860c7202840a67aad2fa64a3fc0.patch
23:53karolherbst: I could even add a signoff-by or so :D
23:53imirkin: karolherbst: can you add a s-o-b line?
23:53pmoreau: it went in 3.19 IIRC
23:53Megaf: imirkin: nyef: So, what you suggest me doing? Going to the proprietary driver?
23:53karolherbst: imirkin: I will do a full shader-db run as well and post some fancy stats
23:54imirkin: Megaf: that's definitely the way to get the most out of your gpu.
23:54imirkin: karolherbst: ok. go for it. let me know when that's ready.
23:54Megaf: My two biggest problems with the proprietary driver are, 1- it's proprietary, 2- doesn't work in EFI mode, I have to remove grub-efi and install grupc and migrate stuff to BIOS mode, running it emulated.
23:54karolherbst: imirkin: will do
23:55Megaf: then the console resolution will be wrong, and brightness keys will no longer work
23:55Megaf: requiring me to edit configuration files to work around
23:55Megaf: shoud just run macOS...
23:55imirkin: Megaf: the situation with nouveau is that there's a very finite quantity of people working on it, with a very finite quantity of documentation, with a fairly infinite breadth of hardware to support
23:55Megaf: I understand
23:55karolherbst: imirkin: but something else is wrong with nouveau here.. nothing I do really changes the perf, though it should. Maybe it is mostly related to scheduling, but sadly I can't try out my dual_issue pass, cause it is broken and hitman hits the broken parts...
23:55Megaf: but as a user, that doesn't help, does it?
23:55imirkin: Megaf: not in the least
23:56imirkin: Megaf: as a user, your only option is to stick to intel/amd gpu's
23:56Megaf: remember when nvidia used to be hardware of choice for Linux?
23:56imirkin: i do.
23:56imirkin: that time is long gone.
23:57Megaf: at the time I had a Radeon 9200.
23:57karolherbst: at that time, a lot of stuff was better
23:57imirkin: i had a radeon 7000 iirc... the vivo kind. it was awesome.
23:57Megaf: it was
23:57imirkin: and then i wanted to watch over-the-air ASTC broadcasts, which were the cool new thing
23:57imirkin: and realized my cpu was *nowhere* close to being able to decode them
23:57Megaf: and that Radeon was the reason I was using the distro I was using at the time. That I used until not very long ago.
23:58imirkin: and then i got a NV34 or so
23:58imirkin: with xvmc support. it was great.
23:58imirkin: in the past few years, upstream support for recent-model amd hw has really come together.