00:00 karolherbst: well, whenever X dies
00:00 imirkin_: well, wayland != DE
00:00 imirkin_: anyways, ideally the reason i switch will be because something compellingly better is out
00:00 imirkin_: rather than merely newer
00:01 agrecascino: i use xfce or icewm
00:01 agrecascino: both are nice
00:01 karolherbst: "nice" right
00:01 agrecascino: and occasionally openbox
00:01 imirkin_:uses WindowMaker
00:01 karolherbst: with kde you get better battery lifetime than both of those :p
00:01 imirkin_: and have been roughly since the dawn of time
00:02 agrecascino: karolherbst, ?
00:02 karolherbst: agrecascino: xfce power manager is shit, bluntly put
00:02 agrecascino: i'm not a fan of 500mb jokes stored in memory
00:02 agrecascino: ;)
00:02 imirkin_: karolherbst: i dunno... 1us vs 2us of time that the power supply's caps let the system run for ... not a big difference either way, even if it were true.
00:03 karolherbst: imirkin_: I messured that once, plain DE, wihtout those fancy applications their come with, 25% difference between xfce and kde
00:03 karolherbst: allthough power management on linux sucks anyway :/
00:04 agrecascino: at least it's not GNOME
00:04 karolherbst: but it is getting better
00:04 agrecascino: or GNOME 3
02:28 mwk: hehe
02:29 mwk: apparently it's quite possibe to put the NV01 IFC machine into an infinite loop by messing with the context
02:29 imirkin_: that ... doesn't seem surprising
02:29 mwk: and hwtest simulates that correctly, by hanging itself, yay
02:41 mwk: alright
02:42 mwk: the main loop of a normal IFC appears to be simulated correctly
02:44 mwk: so now... IFC initialization, IFC errors, and IFC monochrome with < 0x20 width (funny special case)
02:48 imirkin_: NV1 was in saturn, right? you could look at an emu...
02:49 mwk: it wasn't
02:49 mwk: they had a little problem delivering
02:49 imirkin_: oh. hm.
03:40 agrecascino: mwk, make a win98 virus that attacks the nv1?
03:41 imirkin_: he has the last working ones...
05:10 imirkin: gnurou: time to find a GM204 with 4GB of vram? :)
05:10 gnurou: imirkin: I'd expect gm206 with 4GB to trigger the same error...
05:11 gnurou: ... but yeah, I probably should get the same card
05:11 gnurou:goes to bother marketing
05:11 imirkin: out of stock in the closet down the hall? :)
05:11 gnurou: we're a small office here... :)
05:12 gnurou: my own machine still has a GM107 (running Nouveau, mind you)
05:12 imirkin: so out of date! :)
05:12 imirkin: my machine has a NV34 :p
05:12 gnurou: is it well supported at least? :P
05:13 imirkin: http://hastebin.com/unimotebel.sm
05:13 imirkin: eh. decently. the GL driver sucks
05:13 gnurou: ah, but you have a gk208 too
05:13 imirkin: :)
05:13 imirkin: a recent upgrade from a GF108
05:13 gnurou: I'm sure you get more FPS than me with that one
05:13 imirkin: doubtful
05:14 gnurou: using karol's patches, no doubt
05:14 imirkin: although i can reclock (without karol's patches)
05:14 imirkin: you should be able to reclock using his tree as well actually
05:14 imirkin: and i bet you have one of those fancy-shmancy GDDR5 versions of the board
05:14 imirkin: whereas the GK208 is DDR3 and PCIe x8
05:14 imirkin: i go for the high-end stuff :)
05:15 imirkin: anyways, it runs circles around the GF108
05:15 gnurou: but the shaders on GM1 need instruction scheduling information, which Mesa does not provide yet
05:15 imirkin: but i bet the GT215 will still beat it
05:15 imirkin: eh
05:15 imirkin: mesa provides it
05:15 imirkin: just ... in a very constant manner :)
05:16 gnurou: hehe
05:16 imirkin: anyways, i doubt that would account for more than a 30% perf change
05:16 imirkin: whereas your ram is like 5x faster
05:16 gnurou: aha, got to trigger that REGION_VIOLATION fault eventually
05:16 gnurou: 11.213338] nouveau 0000:01:00.0: fifo: write fault at 0000020000 engine 1f [] client 12 [PMU] reason 0d [REGION_VIOLATION] on channel -1 [0000000000 unknown]
05:17 gnurou: that's when I set the WPR address to be zero
05:17 imirkin: that sounds familiar
05:17 skeggsb: gnurou: is it as i predicted - we don't disable a previously secure-booted board correctly before attempting it again?
05:17 skeggsb: ah, no, you're just messing with addresses i think :P
05:17 gnurou: skeggsb: we reset the falcon first thing, so that should be enough?
05:17 gnurou: skeggsb: yes, exactly
05:17 skeggsb: gnurou: you're the one with the docs ;)
05:18 imirkin: gnurou: hakzsam said he might look at doing some basic sched info for maxwell, coz it's apparently a lot more required for atomic ops
05:18 gnurou: would be nice... I am trying to get the scheduling docs released too, but it takes a while as usual :(
05:19 imirkin: well, MaxAs is a pretty good reference
05:19 imirkin: i think the kepler scheduler could be copied in principle
05:19 imirkin: it's different, but the types of information that needs to be tracked are quite similar
05:20 imirkin: i'm still a bit confused by the whole "reuse" thing
05:21 skeggsb: gnurou: just added another thing for users to try on the bug, which should rule in/out that theory
05:23 gnurou: skeggsb: ah indeed, the card won't be POSTed or anything when resuming... nice catch!
05:23 imirkin: skeggsb: won't the second modprobe fail because nouveau is already loaded?
05:24 skeggsb: imirkin: fixed ;)
05:25 imirkin: ok. just making sure i wasn't missing out on some crazy kernel feature...
05:25 skeggsb: nope, when i do such things i have bash autocomplete for me, so, i forgot a step :P
05:28 imirkin: yeah... ^R is nice
05:46 gnurou: alright, got a GTX970/4GB from marketing!
05:46 gnurou:hopes this machine wasn't doing anything important
05:46 gnurou: and... failure!
05:47 gnurou: \o/
05:47 gnurou: exactly the same one
05:47 gnurou: how interesting
05:47 gnurou: (the same as reported on the bug, that is)
05:47 skeggsb: excellent :)
05:47 skeggsb: i hate it more when i buy a board to debug something, and mine works
05:48 gnurou: since this is the same machine that booted the GM206/4GB without issues, I guess we can rule UEFI out
05:48 skeggsb: indeed
05:48 skeggsb: unless it's the graphics fw on that particular board
05:49 skeggsb: (uefi fw, that is)
05:49 gnurou: still... I'm speechless, I remember another GM970 working just fine on that same machine
05:49 gnurou: it had probably less memory though
05:50 gnurou: let's allocate WPR/blobs in a lower memory region first...
05:50 gnurou: ... how do we do that.
05:51 skeggsb: nvkm/subdev/instmem/nv50.c, change the 0x800 in ram->func->get to 0
05:51 skeggsb: (yes, non-obvious magic, that'll be fixed when i can finish my mmu code)
05:51 gnurou:bows
05:52 imirkin: skeggsb: i bet you hate it a lot more when you buy a board to debug something, and even though it's labeled the same as the problem board, it's actually a totally different gpu inside :)
05:52 skeggsb: yes, there was one case of that.. damn nvidia marketing using the same name for 50 different things
05:52 imirkin: that lenovo laptop, right?
05:52 skeggsb: oh, and another case of it with a particular laptop.. i was sent 3 before i got the right one
05:52 imirkin: or dell or whoever
05:53 skeggsb: i think it was lenovo
05:55 imirkin: gnurou: this is probably obvious, but gm206 loads different fw than gm204 - perhaps the gm204 files are screwed up somehow?
05:57 imirkin: hm, just the data files are different
06:29 gnurou: mmm GTX980 Ti boots fine, even though it uses addresses > 4GB...
06:30 gnurou: and is the same fw as 970...
06:30 gnurou: whyyyyyyyy
06:36 imirkin: so *that's* why there hasn't been a stream of people complaining nouveau won't run on their 980 Ti's...
06:36 imirkin: not because nobody runs nouveau on those :)
06:36 gnurou: only 970 seems to be faulty
06:36 gnurou: and I'd say only 970 with 4GB ram
06:37 gnurou: trying to get my hands on a founder's edition to confirm, I could swear this one was working when I tried it
06:39 gnurou: or could it be related to this: http://wccftech.com/nvidia-geforce-gtx-970-memory-issue-fully-explained/
06:39 gnurou: would be surprised though
06:39 skeggsb: gnurou: actually, can you get me a mmiotrace of your board with the binary driver?
06:41 gnurou: ah! allocating instmem in the lower VRAM region *works*
06:41 skeggsb: a nouveau.debug=debug dmesg log could be interesting too
06:41 skeggsb: yeah, i think i know what's going on
06:41 skeggsb: it was a possibility i suspected, but ruled out because of a "normal" amount of vram
06:42 imirkin: oh, the stupid partitions thing?
06:42 gnurou: guess we should not cross that 3.5GB boundary on GTX970
06:42 skeggsb: nouveau is doing the wrong thing on maxwell with mixed-memory configurations
06:42 skeggsb: i'm aware of it from the pascal work, but haven't fixed it yet
06:43 gnurou: that's interesting though, why doesn't GM200 and GM206 suffer from this limitation?
06:43 skeggsb: all the memory controllers have the same amount of ram
06:45 gnurou: skeggsb: shall I fix this by forcing instmem to not be allocated beyond 3.5 GB on GTX970? or do you have a better idea?
06:46 skeggsb: can i see a nouveau.debug=debug log first, then let's see
06:46 gnurou: sure, do you want it with or without the instmem workaround?
06:47 skeggsb: there's some stuff that you can't stick in the weirdo bits of ram (ie. the ram that's not spread across all memory controllers) - i'd be surprised if this was one of them, but, it's not impossible.. nouveau *is* sticking the weird bit at the wrong physical address on maxwell though
06:47 skeggsb: doesn't matter
06:50 gnurou: skeggsb: there you go: http://dpaste.com/0DQBZDX
06:50 gnurou: this is with the instmem workaround
06:51 skeggsb: ok. so, nouveau apparently doesn't think you have a mixed-memory configuration (all partitions have the same amount of memory)
06:51 skeggsb: *but*
06:51 skeggsb: apparently these can also have differing numbers of ltcs (which nouveau doesn't handle because i've never seen an example)
06:51 skeggsb: can i get a mmiotrace :)
06:52 skeggsb: (ie. currently, nouveau doesn't know your board has part of its ram that's "different")
06:52 skeggsb: assuming this is actually the cause of the issue
06:53 gnurou: ok, mmiotrace of the proprietary driver I suppose?
06:53 gnurou: let's go
06:53 skeggsb: we need to fix it properly if it is, because there's other stuff you can't stick in that memory too
06:53 skeggsb: yep, of the binary driver
06:54 gnurou: do you want it up to GR init/secure boot? to know if I need to run startx or not
06:55 skeggsb: startx or nvidia-smi should be fine, RM doesn't do anything unless a client connects
06:59 gnurou: skeggsb: there ya go: https://drive.google.com/file/d/0B4Wi9SO0F_89ZXN6LWtWSUpzWDQ/view?usp=sharing
07:00 skeggsb: that was quick!
07:00 gnurou: well the card is very fast ;)
07:02 skeggsb: yep, ok, this definitely falls into the disabled-LTCs category
08:06 karolherbst_work: gnurou, skeggsb: what are you up to?
08:07 karolherbst_work: the 4GB problem?
08:07 skeggsb: karolherbst_work: fixing the gm20x issues some users are seeing
08:07 skeggsb: i've got enough of a handle of it (i think) to write a patch, but it'll likely need some tweaking again no doubt
08:07 karolherbst_work: I assume the 4GB problem is part of it?
08:09 skeggsb: it's not 4GiB that's the problem exactly, it's that the board is a mixed-memory configuration that nouveau can't currently detect (so, some of the memory is at a different physical address than you'd expect, and can't be used for certain stuff)
08:09 karolherbst_work: well, I plan on having my next GPU be a gm20x, which I want to fully reclock as well :p
08:09 karolherbst_work: skeggsb: I see
08:09 skeggsb: about that... have you tried our pmu ucode on it, it'll probably work
08:09 skeggsb: nfi if the scripts have changed, but you should be able to run them
08:11 karolherbst_work: we can't control the fan
08:11 karolherbst_work: so it is rather pointelss
08:11 karolherbst_work: but no, I didn't try
08:11 skeggsb: no, i know, but, it'll allow you to make progress on the rest of the bits in the meantime (until nvidia grace us with more control....)
08:14 karolherbst_work: I highly doubt we will get them though. I kind of took the vpstate doc a bit… offensive against our efforts
08:15 gnurou: karolherbst_work: they just have no clue where you are at. If I knew better I could provide them with that information, but sadly I am pretty ignorant myself :/
08:15 karolherbst_work: gnurou: pretty much done with gpuboost 2.0 :p
08:16 gnurou: karolherbst_work: well soon you will not need us at all ;)
08:16 karolherbst_work: except power capping
08:16 karolherbst_work: who said I need anything :p
08:17 gnurou: that's the spirit!
08:18 karolherbst_work: the power_budget table has to be REd, but that is like low priority right now
08:18 karolherbst_work: software thermal protection is more important right now
08:18 hakzsam: imirkin, confirmed, all MS tests have been fixed on gm206, only polygon-offset now fails regarding gm107 :)
08:19 hakzsam: [I ran piglit last night]
08:19 karolherbst_work: gnurou: I only complained about that documentation being rather useless, though a nice confirmation about that one field :D
08:19 karolherbst_work: I wasn't sure which is the "base" and which one the "tdp" one (because they are always the same)
08:19 skeggsb: we need a sight lot more work than that! but yes, the general idea is there ;)
08:20 skeggsb: i gave nv a bit of an update on where we're lacking info on the details of changing clocks in general (not so much the policy stuff)
08:20 skeggsb: hopefully something will come of that
08:23 hakzsam: skeggsb, did you run piglit on pascal btw?
08:23 hakzsam: it would be nice to have full run :)
08:23 skeggsb: i haven't, but i can probably attempt that tomorrow
08:24 hakzsam: cool
08:24 karolherbst_work: skeggsb: good
08:27 karolherbst_work: skeggsb: nvf0+ has a lot of new stuff :/
08:28 hakzsam: skeggsb, does this sound familiar to you http://hastebin.com/akivikuwok.sm ? it appears to only happen on gm206
08:28 karolherbst_work: currently we can't read out the right clock on those gpus (not for all cstates though and usually we only read out the higher ones wrongly)
08:30 rhn: mslusarz: can you give a quick introduction how to use the fuzzer? by default it seems to only find IOCTL sizes (I think), and not CREATE pointers
08:39 clean: can anyone help with pcie GPUs with libreboot? The vbios is not being executed. The Nvidia GS8400 sold by think penguin (https://www.thinkpenguin.com/gnu-linux/geforce-8400gs-1gb-pci-express-20-video-card-gnulinux-full-low-profile-brackets) says "Not dependent on wrappers, binary blobs, or proprietary drivers-firmware "
08:41 karolherbst_work: clean: if the vbios isn't interpreted, you are pretty much on your own
08:42 karolherbst_work: also the vbios isn't considered any of those things
08:42 karolherbst_work: (at least by us)
08:44 clean: Any ideas where I can start?
08:45 karolherbst_work: by telling us what your problem is
08:46 clean: Well I've put a GT GS8400 in a motherboard with libreboot. Output is still being displayed through the MB vga. GPU vga is nothing.
08:47 karolherbst_work: then you should ssh into it and see what dmesg says
08:47 clean: ok thanks
08:47 karolherbst_work: ohh wait, you don't need ssh, because your mb vga works :D
08:48 clean: yeah
08:48 clean: I'll still go and figure out how to use dmesg in grub, or is it just a grub console command?
08:49 Tom^: does MB in general let you use the onboard vga at the same time as the PCI card?
08:50 Tom^: atleast on mine i have to choose in the efi settings which one to uh power on at boot.
08:51 clean: Tom^: I'm not sure. I guess I will have to reflash proprietary bios to check?
08:52 Tom^: oh no idea
08:56 clean: karolherbst_work: do you mean use dmesg once gnu/linux has booted? Would that still contain info from bios?
08:58 karolherbst_work: clean: right, once it has booted
09:53 clean: Wouldn't my issue be pre-nouveau anyway? BIOS & grub use like vesa before linux starts don't they?
10:06 mupuf: karolherbst_work: 690 received
10:19 karolherbst_work: mupuf: yay \o/
10:19 karolherbst_work: clean: check dmesg, how should we know what the problem is otherwise?
10:19 karolherbst_work: clean: you could try to blacklist nouveau or to add "nomodeset" to it and see if that changes anything
10:21 karolherbst_work: mupuf: so first task is getting prime offloading to run over SLI instead of PCIe? :D
10:22 karolherbst_work: I am also wondering if there is a PMU counter for SLI like for PCIe
10:22 karolherbst_work: but then I have no idea why there should be one
10:38 Calinou: lol, people actually buy that 8400GS?
10:38 Calinou: I'm baffled :|
10:49 clean: Calinou: I just have an 8400GS from years ago, different from the thinkpenguin model. What's the issue with it anyway?
10:52 mupuf: karolherbst_work: what do you mean, I am sure both GPUs are exposed as different devices on the PCIe bus
10:55 karolherbst_work: mupuf: exactly
10:55 karolherbst_work: mupuf: and by default, prime offloading should go over the pcie bus, right?
10:55 karolherbst_work: why not doing that over SLI, just to get familiar with SLI
10:56 mupuf: because it is a waste a developer time?
10:56 mupuf: nouveau sucks on one GPU and sucks on two
10:56 mupuf: so, let's work on fixing one gpu performance :D
10:56 karolherbst_work: we don't have to work on that now :p
10:56 karolherbst_work: it was just an idea
10:56 mupuf: hehe
10:56 karolherbst_work: hey, kepler ain't that bad
10:57 karolherbst_work: anyway, if somebody wants to work on SLI, this would be quite a nice task
10:57 Calinou: clean: very old/low-end GPU
11:03 karolherbst_work: mupuf: that gpu needs 2x8 power pins, right?
11:03 mupuf: karolherbst_work: yes...
11:03 karolherbst_work: k, so it isn't pcie conformant D:
11:03 karolherbst_work: :O
11:03 karolherbst_work: I think the pcie logo is also missing or something
11:03 mupuf: well, it is there
11:04 karolherbst_work: mhh odd
11:04 mupuf:should fix the code and sent it to ben for 4.9
11:04 karolherbst_work: which code?
11:04 karolherbst_work: also, your LED stuff!
12:14 rhn: mslusarz: I guess what I actually need to know is how to interpret this demmt output: http://wklej.org/id/2772499/
12:14 rhn: I understand that this is a fuzzer message, but demmt doesn't know how to handle it
12:45 Amfern: Imirkin: nice catch on the 4GB
13:02 mupuf: karolherbst_work: what PCIE logo were you talking about?
13:02 mupuf: and yes, I meant the LED stuff
13:05 karolherbst_work: the official PCIe logo devices usually have :p
13:07 mupuf: never seen it :o
13:07 mupuf: or I never paid attention
13:07 mupuf:would make a bad bad Sherlock
13:09 karolherbst_work: yep
13:31 mwk:gave up and used goto
13:36 mupuf: mwk: WTF
13:36 mupuf: you will soon have a very accurate simulation of the nv01
13:36 mupuf: and pretty sure it would run faster than the original :D
13:37 mwk: mupuf: that's the goal
13:37 mwk: well, accurate simulation, don't know about the "faster" part :p
13:37 mwk: IFC is... quite scary
13:39 mwk: and the damn thing wil probably be 2× longer when complete, I still don't simulate the EDGEFILL[8] == 1 case
13:39 mupuf: ...
14:34 mlankhorst: mwk: but why the nv01? wouldn't nv03 be more useful?
14:46 mupuf: mlankhorst: he said it was easier and he would like to model one GPU at some point :D
14:46 mupuf: and this is a good one :p
14:49 mwk: mlankhorst: because NV01 comes before NV03, obviously :p
15:02 mwk: also... NV01's 2d engine is pretty much a subset of NV03
15:03 mwk: the plan is to start hwtest/nv03_pgraph as soon as NV01 2d is reasonably covered
15:18 imirkin: skeggsb: perhaps you can write a quick hack to get these people going? maybe limit vram to below some size where everything is the same? or something else easy?
16:00 night199uk: hey
16:01 night199uk: anyone can talk on the structure of the video PLLs @ 0x614140?
16:01 night199uk: (any more than is in the nouveau code already) :-)
16:01 imirkin_: they have loops
16:01 imirkin_: and they lock phases
16:02 imirkin_: (you might want to be more specific in your questions)
16:04 night199uk: heh - well, i have a bunch of questions
16:04 night199uk: i’m trying to map out the ctrl register which seems to be offset @ 0xc
16:05 night199uk: bits 8 and 9 specifically @ 0x61414c are queried by the driver to set up some flags for the VPLL
16:06 night199uk: the structure of the coefficients seems to be the same as those set up for GPCPLL_COEFF in gk20a
16:06 night199uk: but the definitions under GPCPLL_CFG2 (0xc) seem to be quite spare in the nouveau headers
16:07 night199uk: i’ve done a lot of trawling through new/old nouveau code bases and VPLLs seem to be mostly statically configured - besides the coefficients the data values programmed into ctrl and cfg seem to be fixed (known) numbers
16:08 night199uk: so my questions really are:
16:08 night199uk: is/are the clock sources for the VPLLs static?
16:09 night199uk: from what I’ve read that some of the PLLs can change to different reference clocks - and the clocks & plls are configured separately?
16:11 night199uk: in the BIT PLL Limits table I see RefClk and AltRefClk
16:11 night199uk: so I’m thinking one of these bits is use to switch between RefClk source and AltRefClk
16:13 night199uk: guess i just want to see if anyone has any ideas around this stuff / ever did any work on those regs
16:15 imirkin_: RSpliet: mupuf: --^
16:18 mupuf: night199uk: well, if nvidia does stuff differently based on these values, then it likely means we shouldn't do stuff statically
16:18 mupuf: more to the point, what do you call VPLL?
16:18 mupuf: And what gpu are we talking about?
16:19 night199uk: so the code i’m talking about is used on pretty much all nvidias from PID 0x6c0 (GF100) up
16:19 mupuf: https://github.com/envytools/envytools/blob/master/rnndb/pm/gf100_pclock.xml <-- here is our doc
16:21 night199uk: VPLL I’m assuming is the video (pixel) clocks i’m assuming from the context in nouveau and the driver
16:21 mupuf: then it has nothing to do with GPC, right?
16:22 night199uk: that is a good question, i don’t have any idea what the GPC is :-)
16:22 mupuf: sorry, gotta go
16:22 night199uk: general purpose clock i’m assuming?
16:22 night199uk: hence asking really - i’m trying to understand the clock structure better so excuse my ignorance here :-)
16:22 mupuf: oh, right, it depends on where you get your names :D
16:22 mupuf: yeah, it is messy to read
16:23 mupuf: have a look at our docs, that should help
16:23 mupuf: but make a full write up of what you are trying to do
16:23 night199uk: looking at envy 0xc isn’t even mentioned
16:23 mupuf: the relevant parts of the traces for nouveau and nvidia
16:23 mupuf: it is ... but it is encoded differently
16:24 mupuf: make the full write up, I will have a look at it tomorrow, sry!
16:24 night199uk: ahh - if you have some time later can you ping me?
16:24 night199uk: no worries
16:24 night199uk: i want to make sure i write something sensible before i write something
16:24 mupuf: ping me with the write up, I will answer back ASAP
16:24 night199uk: too many fragmented questions and bits of knowledge right now
16:24 imirkin_: night199uk: have you looked at the actual code in nouveau?
16:24 night199uk: okay, i’ll try and put what i can
16:24 imirkin_: not the rnndb docs?
16:24 mupuf: then talk about what you want to achieve
16:24 night199uk: imirkin_: yes, a lot
16:24 imirkin_: those aren't always in sync
16:24 imirkin_: ok
16:24 night199uk: sec, i can put you at the nouveau code i’m talking about
16:26 imirkin_: nah, it's fine
16:26 imirkin_: i'm just pointing out that those arne't always in sync, so it's good to check both
16:26 imirkin_: also i wouldn't assume that the nouveau RE of this stuff is 100% accurate
16:26 night199uk: yeah
16:26 imirkin_: it's usually "accurate enough"
16:26 night199uk: gf100_devinit_pll_set(struct nvkm_devinit *init, u32 type, u32 freq)
16:26 imirkin_: but it's not like any of us have spectrum analyzers to test anything
16:27 night199uk: nvkm/subdev/devinit/gf100.c
16:27 imirkin_: nor would we know or be able to hook into the right test points for it
16:27 night199uk: yeah, i’m in the same boat
16:27 night199uk: so its hard to ask smart questions
16:27 night199uk: i’m just hoping folks might have look at some of this before and be able to fill in some of the blanks i have and vice versa
16:27 night199uk: :-)
16:27 night199uk: in that func nouveau just does:
16:27 night199uk: nvkm_mask(device, info.reg + 0x0c, 0x00000000, 0x00000100);
16:28 night199uk: so specifically, i’m wondering where they value/write comes from. i guess just someone pulled it out of a reverse as ‘thats what works'
16:29 night199uk: i see the driver doing some additional stuff with bit 8 there
16:29 night199uk: it uses bit 8 to drive some of the VPLL config
16:29 night199uk: (and bit 9)
16:35 imirkin_: normally it'd come from looking at what blob does
16:35 imirkin_: you'd see that it reads a reg, and then immediately does a write with some additional bit set
16:36 night199uk: got it - thats what i thought
16:36 night199uk: the UEFI driver seems to do a lot more than this
16:37 night199uk: some stuff tied up with registers at 0xe900 / 0xe904 / 0xe9f8
17:29 inglor: right so new SLI card in house. So how does one get involved into power consuption stuff :D
17:35 night199uk: aha, i think i understand this now
17:35 night199uk: PLL_UNK41 & PLL_UNK42 in nouveau seems to be alt / extra video PLLs?
17:36 night199uk: looks like any of the VPLLs can be set to source clock from PLL_UNK41 & PLL_UNK42
18:29 Tom^: holy moly, 3 extensions from 4.5 on nvc0 O_o
18:32 imirkin_: 3?
18:33 imirkin_: should be ARB_enhanced_layouts and KHR_robustness
18:34 hakzsam: 3 for maxwell though :)
18:34 imirkin_: 3 more for maxwell :p
18:35 mslusarz: rhn: this is some kind of mmt bug, look at the log with "less" to see the whole message
18:35 rhn: mslusarz: thanks
18:35 hakzsam: imirkin_, ARB_enhanced_layouts, KHR_robustness and ARB_tessellation_shader
18:35 imirkin_: hakzsam: and ... images.
18:35 imirkin_: coz someone chickened out and didn't enable them
18:36 hakzsam: oh well, images is there
18:36 hakzsam: but not enabled :p
18:36 imirkin_: aka "not there" :p
18:36 hakzsam: you know why :)
18:37 mslusarz: rhn: IIRC demmt does not know how to handle fuzzer messages, so you need to look at the output directly
18:38 rhn: mslusarz: ok. if I get tired of it, I might implement some output
18:40 mslusarz: well, you are supposed to run mmt once, find argument sizes in the log, update mmt_nv_object_types array in mmt source and redo the trace without fuzzer
18:41 rhn: mslusarz: it terminates early with the fuzzer, so I think it will not be so easy
18:45 rhn: mslusarz: FIFO objects get special handling in demmt/nvrm.c - is there anything else I need to know about them to add a new one?
18:45 rhn: GP104 introduces c06f code
18:46 mslusarz: I don't remember, sorry
18:46 rhn: mslusarz: ok, trial and error should work :)
19:01 rhn: how to regenerate headers from xml?
19:02 imirkin_: headergen
19:03 rhn: that's as far as I got: http://wklej.org/id/2772711/
19:04 imirkin_: iirc the path is rnn_path-relative
19:04 rhn: oh
19:04 imirkin_: i.e. try just nvrm_object.xml
19:04 rhn: you mean relative to rnndb directory?
19:05 imirkin_: well, to the path supplied in RNN_PATH
19:05 rhn: ah
19:05 imirkin_: it's been 100 years since i've run it though
19:05 rhn: just did that
19:05 rhn: it didn't crash, but I don't know what happened to output
19:05 rhn: let's see
19:05 imirkin_: it's in nvrm_object.xml.h
19:06 imirkin_: in the same dir as nvrm_object.xml
19:06 rhn: imirkin_: you're right! thanks for help
21:36 karolherbst: ohh, life is trange is now first episode free and it seems quite advanced. Unreal engine 3.5 or something
21:36 karolherbst: also ported by feral
21:37 karolherbst: seems to run good enough though
21:38 imirkin_: hangs for me after a short while in-game
21:38 imirkin_: like a few minutes
21:39 imirkin_: haven't investigated
21:40 karolherbst: mhh
21:40 karolherbst: well I ran it like 2 mintues
21:40 imirkin_: try 5 :)
21:40 karolherbst: :D
21:40 karolherbst: k
21:40 imirkin_: could be specific to my gpu speed, of course
21:41 imirkin_: i also seem to recall twiddling with some paraemters
21:41 karolherbst: depends on the issue
21:41 karolherbst: but it somehow looks different compared to nvidia :/
21:42 karolherbst: but the graphics are soo odd, that it may be just me
21:44 skeggsb: hakzsam: the LAUNCHERR is the cause of the problem, and it's userspace fucking up there
21:45 skeggsb: i haven't yet figured out how to reliably recover from it on the kernel-side
21:45 hakzsam: skeggsb, yeah, we figured with imirkin_
21:45 hakzsam: I will write a patch for that
21:50 hakzsam: skeggsb, it appears that m2mf doesn't like when chunks are > 64k because for example a rgba32f image with 4096x1 works while 4097x1 miserably fails
21:50 karolherbst: imirkin_: no issues on my end so far
21:51 imirkin_: skeggsb: specifically the CE, since no more m2mf on there
21:51 Tom^: karolherbst: dont think you are mistaken on that, nouveau looks different in cs:go compared to blob here aswell.
21:52 imirkin_: Tom^: karolherbst: chances are some filtering parameters are different
21:52 Tom^: cant say exactly what, but the textures are somehow different. :p
21:52 karolherbst: Tom^: well, why don't you make an apitrace and compare the generated images :p
21:52 imirkin_: it's pretty configurable, and we don't set any of it.
21:52 karolherbst: I see
21:52 hakzsam: imirkin_, right, the copy engine :)
21:52 karolherbst: well, heaven is also a bit different, but nothing you really notice
21:52 imirkin_: sure, but there's like 30 different aniso settings
21:53 karolherbst: uhh
21:53 karolherbst: do you think there might affect performance? (asking the important questions here)
21:53 imirkin_: yes
21:53 keringar: Are the tables in nvbios different for different companies?
21:53 karolherbst: keringar: chances are, they are always different
21:53 imirkin_: i have to assume those settings affect perf, since otherwise they'd just be set to the max always :)
21:53 karolherbst: imirkin_: I see
21:54 karolherbst: imirkin_: so, we could set them to the minimum and see what happens?
21:54 imirkin_: keringar: the vbios is created by the board maker. i think that nvidia supplies some tool they can use.
21:54 karolherbst: maybe if I got time I could play around with those things
21:54 imirkin_: karolherbst: if we knew what the minimum was ;)
21:54 karolherbst: right, but as I said, I could play around with those
21:55 imirkin_: go for it.
21:55 karolherbst: no clue where to look though :D
21:55 imirkin_: sampler and texture descriptors
21:56 karolherbst: k
21:58 hakzsam: grep for tsc/tic and you will see a bunch of parameters for those descriptors
22:01 karolherbst: is most of the stuff inside _tex.c?
22:01 hakzsam: yes
22:02 hakzsam: nvc0_create_texture_view() essentially
22:03 karolherbst: yeah, already looking at gf100_create_texture_view
22:03 karolherbst: the "tic[0] = (tex_fmt << G80_TIC_0_COMPONENTS_SIZES__SHIFT) |" lines
23:17 keringar: karolherbst: I'm looking at my fan_mgmt table and it maps to what nvbios tells me. But there's a lot of zeros at the end that don't seem to do anything when I change them. https://gist.github.com/Keringar/c6e9112dea70133ff6a8014d30b0b3c2
23:38 mupuf: # nvalist
23:38 mupuf: 0: (pci) 0000:01:00.0 GM206 126010a1
23:38 mupuf: 1: (pci) 0000:07:00.0 GK104 0e4080a2
23:38 mupuf: 2: (pci) 0000:08:00.0 GK104 0e4080a2
23:38 mupuf: seems like the GTX 690 indeed is working
23:39 imirkin: neat-o
23:39 mupuf: however ... it was a *very* tight fit in reator
23:39 mupuf: took me about 30 seconds to insert the card
23:39 mupuf: that is what I call a freaking-tight squeze!
23:39 mupuf: down to less than a mm
23:41 mupuf: Nouveau does not seem to choke on it
23:41 mupuf: karolherbst: ^^
23:42 mupuf: I wonder if both bioses are the same
23:43 mupuf: hmm, seems like the vbios repo already has some information
23:44 mupuf: and yes, they do differ
23:44 mupuf: :D