00:02 orbisvicis: that's the from supported 340 driver, but I used the older 325, without error
00:02 orbisvicis: anyway, I think I need some help
00:02 orbisvicis: perhaps the firmware files aren't compatible with NVE0 (gt 730), but I see no difference in video acceleration
00:03 orbisvicis: or perhaps they're not loaded, is there a logging mechanism I can enable on boot ?
00:36 mwk: heheh, of course
00:37 mwk: I improved the random initial state generator, and uncovered a crapload of new failures in old tests
00:37 mwk: how unsurprising
00:56 mooch: lol
00:58 mooch: mwk: i guess i'll have to revise my emulation then, since i've already made some changes to fit your tests, at least hypothetically.
01:06 mwk: mooch: don't worry, most of the new fails are on nv1
01:07 mooch: ah, okay, good
01:07 mwk:is currently trying to merge nv1 and nv3 testsuites into one, and generally do a lot of deduplication in the code
01:07 mooch: i haven't messed with nv1 yet
01:07 mwk: it's quite a mess, it seems I currently have 6 different functions that set a new vertex coord and its associated status regs
01:07 mooch: oh god
01:07 mwk: 3 of them on nv1, 2 on nv3, and 1 on nv4
01:08 mooch: mwk: would you be willing to help debug my nvidia emulation so that the win 3.11 nvidia drivers will work?
01:08 mwk: nvidia has 3.11 drivers?
01:08 mooch: YEAH
01:09 mooch: only for nv3 tho
01:09 mooch: and since they don't have dos drivers except for nv1, i figured i'd start there
01:09 mooch: oh wait, nvm, you wouldn't be able to help
01:09 mooch: because the fuckup is in the dynarec
01:09 mooch: basically, it deletes a block it's already deleted lol
01:12 mooch: and because of that, it crashes the whole emulator
01:28 mupuf: mwk: fun :)
02:28 mooch: mwk: are there any new fails on nv3?
06:19 mwk: mooch: iirc I've fixed them all already
06:21 mwk: the main source of failures on nv1 is ifc_data method, and that's not easy to fix
06:21 mwk: I don't simulate it at all on nv3 yet
10:46 fbe^-: hi, i'm using ubuntu 16.10 with a 4.8.0 kernel. i have a quadro K3100M (and an internal intel video card, i7-4800MQ). it's possible for me to connect an external display port display (the display port is connected to the nvidia card), but the performance is really bad - my terminals are lagging when rendering output. is this a known behaviour? is it possible to increase the gpu clock in nouveau manually (maybe that helps?)
10:59 karolherbst: fbe^-: I guess that the intel gpu is used for all that
10:59 karolherbst: read up on prime offloading
10:59 karolherbst: and check to which GPU your ports are connected
11:00 karolherbst: and also make sure you render on the nvidia gpu
12:19 fbe^-: karolherbst: yay, that worked. i had to disable gpu switching in my bios to get a xserver up and running with nouveau, but now the performance is okay
12:30 karolherbst: fbe^-: mhh, well you can also just look into prime offloading and get that working
12:38 fbe^-: oh, well, thats fine for me as it works now because it works =)
16:36 interestedDude: hi, so remember there is a concept as absolute addressing of the registers, this is written in radeon docs, and again pretty much sniffable inside the code too
16:37 interestedDude: what it essentially means is that warp backing lane regs can be globally addressed, and it is even said that it reduces register pressure, which of course when a little bit is even correct statement
16:38 interestedDude: 's/when a little bit/when you think a little bit/g'
16:41 interestedDude: on radeon that is what we'll end up using , to mask the lanes with using ds instruction in addition, which can be mostly similarly done on NVIDIA hw too
16:43 interestedDude: currently that is from me, as this concept and a way to do things, is very easily implementable, currently i wish you mary christmas , and we'll see when is the for you the proper moment or time to fix this up later
16:44 interestedDude: is the/ is the right time
16:46 interestedDude: however seems my fingers are twisted for some reason, better off heading out, well i haven't wished all that bad to imirkin, but it seems the bans have been unjustified despite the fact, that i have not really shown up with the diffs, there is some conspiracy and crap around me what people have served for the world intentionally all the time, can't
16:46 interestedDude: really know what to make out of it
16:48 interestedDude: i've been seriously upset because of you not on time did not understand my talks, they were not as mature as they are now anyways, i was seriously upset by those bans, but i pushed my own a bit more, and i am calm now
16:54 interestedDude: let's say if you have just grasp/grip at the concept, it is actually so easy one , that there is no point getting into conflicts
16:58 interestedDude: again starts, well either merry christmas and happy new year, during this time around i make the implementation to radeon
16:58 interestedDude: what is wrong with you imirkin, why behaving so?
16:59 interestedDude: it is just a friggin 100lines of code what i have been talking about, it's no invention or nobel prize stuff, designers have inch perfectly accounted that it ends up thin in doing the perf path
21:18 orbisvicis: I've got a motherboard/gpu combination that doesn't support s3 resume re-initialization in either linux or windows
21:19 imirkin: congrats :)
21:19 orbisvicis: I've tried a bunch of different kernels, drivers, debugging etc
21:19 orbisvicis: nouveau seems to think the card was reinitialized properly (no errors) but video out is dead
21:20 imirkin: define 'dead'
21:20 imirkin: can you ssh in and do 'grep . /sys/class/drm/card*-*/status' ?
21:22 imirkin: also, which GPU do you have?
21:23 orbisvicis: pny gt 730 1gb gddr5
21:23 imirkin: GF108 or GK208?
21:26 orbisvicis: gk208
21:27 orbisvicis: ok, so all three outputs (DVI-D,VGA,HDMI) report disconnected
21:27 imirkin: what if you unplug + plug?
21:27 orbisvicis: nope, tried that with vga and hdmi (dont have DVI though)
21:28 imirkin: do you see anything in dmesg from disp saying INVALID_STATE or somesuch?
21:28 imirkin: actually, just pastebin your dmesg for good measure
21:31 orbisvicis: imirkin: before I ruled out everything, and realized it was a problem under windows as well, I posted the problem @ http://superuser.com/questions/1153248/causes-failure-to-reinitialize-video-out-on-resume
21:32 orbisvicis: anyway, should I boot with any special flags first (https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues) ?
21:32 imirkin: mmmm ... you could boot with nouveau.debug=debug drm.debug=0xe
21:33 imirkin: btw - you mention x16 in that post, but just fyi, that card is x8-only afaik
21:33 imirkin: (the thing might have a x16 connector, but only x8 is hooked up)
21:33 orbisvicis: no pny changed it to x16 connector from the reference
21:33 orbisvicis: but yeah, I figured in the second (intended for sli slot) the BIOS might skip initialization
21:34 orbisvicis: *second pci slot
21:34 imirkin: bios doesn't do anything on resume
21:34 orbisvicis: oh
21:34 imirkin: it's up to the OS to reinit the hw
21:34 orbisvicis: ok give me a few seconds
21:34 imirkin: (on boot, the bios can stomp all over ram and whatnot, while on resume that's a little trickier)
21:43 orbisvicis: ok, it doesn't actually include the initial boot (too long) but has the full suspend/resume cycle:
21:43 orbisvicis: https://paste.fedoraproject.org/499959/97410414/
21:46 orbisvicis: imirkin: the full log: https://paste.fedoraproject.org/499960/74348148/
21:46 orbisvicis: btw, everything looks OK, right ?
21:47 imirkin: [looking]
21:49 imirkin: hrmph
21:49 imirkin: everything is fine, yet nothing works =/
21:49 imirkin: that's a little unfortunate
21:49 imirkin: skeggsb: perhaps you might have a look at this --^
21:50 imirkin: i'm not 100% on how the resume process is supposed to go, but i would have expected to at least see some disp state dumps with the debug setting
21:51 orbisvicis: could it be a display issue? I can try with an old crt I have lying around
21:51 imirkin: anything's possible, but highly unlikely given that it doesn't come back when you plug/unplug the hdmi cable
21:53 imirkin: orbisvicis: one thing you can try is drm-next, which has a bit of a rewrite of a lot of the display logic
21:53 imirkin: to support atomic modesetting
21:54 imirkin: perhaps it magically jiggers something to make it start working
21:58 orbisvicis: no luck plugging in the crt, ill try a full reboot with it once we figure out how to get disp. state dumps
21:59 orbisvicis: imirkin: how do I get drm-next on fedora, 25 ?
21:59 imirkin: sorry, i can't really help with distro support
22:00 imirkin: afaik there's something called "rawhide". not sure how it relates to all that.
22:00 orbisvicis: np, but I'm not evens sure what drm-next is. a replacement for xorg-x11-drv-nouveau ?
22:00 orbisvicis: basically, nouveau_drv.so ?
22:00 imirkin: no - the linux kernel
22:00 orbisvicis: oh
22:01 imirkin: drm-next is a branch which contains the "next" pull for drm
22:01 imirkin: i.e. what will be in 4.10
22:01 imirkin: it lives here: https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
22:02 orbisvicis: do I have to build a new kernel, or can I just pick the drm module and build that ?
22:03 imirkin: it's unlikely that the drm (and related) modules will work as-is with the old kernel
22:03 imirkin: there is no in-kernel ABI, so these things shift around a lot with each release
22:05 orbisvicis: imirkin: so that repository is standalone, I just have to build it?
22:05 orbisvicis: and figure some stuff out :)
22:05 imirkin: that's right. but chances are there are already rpm's available
22:05 imirkin: i just don't know anything about where they are or how to use them ;)
22:06 orbisvicis: imirkin: also, what about nouveau_drv.so, Id probably need to build a new version too ?
22:06 imirkin: (my idea of "easy to use" appears to be different from most of the marketing dollars behind "easy to use" claims)
22:06 imirkin: nope
22:06 imirkin: that's a separate component
22:06 imirkin: and also not one you're using as i believe you're using wayland + Xwayland
22:06 imirkin: which in turn uses glamor
22:07 orbisvicis: that's right. interesting, didn't know that
22:30 orbisvicis: I might put this off till the weekend
22:37 imirkin: unfortunately i'm not of much help. hopefully skeggsb will be able to glance at it.
22:44 orbisvicis: imirkin: thats my hope. In the case that I do have to build drm-next, are there any debug flags I should enabled, not covered by: http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/config-debug
22:44 orbisvicis: *enable
22:44 imirkin: highly unlikely.
22:45 imirkin: there's no much in terms of compile-time debug options that need to be enabled
22:45 orbisvicis: ok, great
23:17 voxadam: How is Nouveau's support for GTX 10 series cards? I'm thinking about buying a 1060 soon(ish) and I'd really like to avoid Nvidia's binary driver.
23:18 imirkin: roughly non-existent
23:18 imirkin: i believe that the 1060 is a GP106 (or GP107), which is not even recognized
23:18 imirkin: but even if it were, you'd only have modesetting, and no acceleration at all
23:18 voxadam: NV136 (GP106)
23:19 imirkin: because nvidia has not released any acceleration firmware
23:19 imirkin: [and requires signed firmware blobs, so nouveau can't provide its own]
23:19 imirkin: if you're looking for open-source support, go with AMD
23:19 voxadam: I forgot about that.
23:19 voxadam: Hmm...
23:20 voxadam: Thanks.
23:22 imirkin: if for some reason you want to use nouveau, the best semi-modern cards supported are kepler's
23:23 voxadam: What exactly does Nvidia have to gain from acting like they are?
23:23 imirkin: my guess is that it makes counterfeiting harder
23:24 imirkin: and their revenue (and profit) is primarily in the high-end space
23:24 imirkin: where my guess is that there's not a *ton* of nouveau users
23:25 imirkin: [high end meaning datacenters full of gpu's, not some dude with a single computer]
23:26 imirkin: what i'm really unclear about is why they don't distribute their blobs in a redistributable manner along with releasing the various GPUs
23:27 imirkin: maybe not worth the effort? dunno.
23:28 voxadam: I wasn't aware GPU counterfeiting was an issue.
23:28 imirkin: it might also have been motivated by some secure boot thing
23:28 imirkin: either way, it's a major pain in the ass
23:30 voxadam: So Kepler is the most modern arch really supported by Nouveau?
23:30 voxadam: No Maxwell.
23:30 imirkin: pretty much, yeah
23:30 imirkin: GM20x also has the same signed firmware stuff
23:31 imirkin: and they've yet to release all the necessary firmware for that as well
23:31 imirkin: GM10x has working accel and reclocking (in drm-next), but the compiler is missing a critical bit to make it performant
23:31 imirkin: (and it was never a high-end chip in the first place)
23:32 imirkin: kepler has everything in place, but is of course subject to the usual nouveau issues surrounding stability, error recovery, etc
23:43 voxadam: Well, thanks for the info.
23:44 voxadam: I appreciate it.
23:45 voxadam: Between Nvidia signing their firmware and Intel with their Management Engine I'm quite annoyed.
23:46 imirkin: yeah. get a talos workstation. it's almost free at $18k
23:46 voxadam: That's a bit outside my price range at the moment.
23:46 imirkin: just have to drop the 'k' and then it's all good? :)
23:47 voxadam: Maybe I'll have to settle for a pint or two. :)
23:47 voxadam: 4pm isn't too early to start drinking, is it?
23:47 imirkin: it's after 5pm *somewhere*
23:47 voxadam: I like your attitude.
23:48 imirkin: and you're not drinking alone... you're drinking with the lord :)
23:48 voxadam: hahaha.
23:48 voxadam: I've never heard that one.
23:48 imirkin: from the simpsons, i believe
23:48 voxadam: I love it.
23:48 imirkin: "marge: do you ever drink alone? homer: does the lord count?" or something along those lines
23:49 imirkin: "do you need a bear to go to sleep? thanks, that'd be great"
23:49 imirkin: beer*
23:49 voxadam: lol
23:50 imirkin: https://frinkiac.com/caption/S04E16/838720