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