00:00nyef: skeggsb: So, if I disable that check for the panel post-resume, I should also see no change to the observed behavior of the hardware?
00:01skeggsb: i don't know, it depends on the *why*
00:01skeggsb: it's possible we're not configuring something we need to to route that hotplug pin to that aux channel or something
00:01imirkin_: it's also MXM, which adds to the fun of it
00:01skeggsb: imirkin_: if that were the case, a hpd event would get generated when it reappears one would expect
00:01nyef: Meanwhile, I'm struggling to get a usable test environment again.
00:54nyef: Ugh. I had forgotten how dreadful it can be working with Nightmare File System.
00:55mwk: nyef: you too, eh?
00:55mwk: we hates it forever....
01:02nyef: Okay, to be fair, some of this suck might be due to my server being an Origin 350, but it's still suck.
01:02mwk: have no doubt, NFS sucks
01:03nyef: Oh, I don't doubt THAT, but that doesn't mean that I couldn't have an unusual piece of hardware making things WORSE.
01:06nyef: There's still a small pile of kernel stuff to be done for Origin 350 support, too... Oh, and the SMP support...
01:08imirkin: to be immediately followed by rm -rf...
01:16mwk: well, fuck me with a pencil
01:16mwk: apparently having the D3D6 class active when restoring Celsius state causes quite a few registers to be mangled
01:17mwk: in an invisible way, too
01:17mooch: well shit
01:18mwk: they read back as the written values, but the value hw uses internaly will be mismatched
01:18mooch: good thing i haven't gotten to that yet lol
01:18imirkin: somehow i doubt that's a hw feature
01:18mwk: imirkin_: it is
01:18imirkin: i mean - it is something the hw does
01:18imirkin: but not a desired feature
01:19mwk: it is a desired feature
01:19nyef: Fun and games, eh?
01:19imirkin: mwk: why?
01:19mooch: mwk: how do you know that?
01:19mwk: the hw patches some state to match D3D6 behavior
01:19mwk: it's necessary for correct emulation of TNT's combiners via Celsius register combiners, for one
01:19imirkin: would you want that on a ctx switch?
01:20imirkin: ohh, wait, i see what you mean. yeah ok, that makes sense.
01:20mwk: I have no idea why they decided to patch it *after* the register write
01:20mooch: mwk: ah, but how do you enable this?
01:20mooch: i would HOPE that you can disable that
01:21mwk: it would make more sense to make the D3D6 class fix the regs before sending them down the pipe
01:21mwk: but.... this is Celsius. apparently not.
01:21mooch: nvidia hardware rarely makes sense
01:21mooch: you should know this by know lol
01:21mwk: mooch: you "enable" it by having the D3D6 class active as the current object
01:22mooch: i dunno how i'm gonna emulate that
01:22mwk: that'd explain why the method behavior didn't make any fucking sense
01:22mwk: if it's supposed to be fixed by later stages of the pipeline
01:23mooch: you know, most nvidia emulators only emulate pgraph based on how you use it through pfifo
01:23mooch: they never emulate the actual pgraph mmio state
01:23mwk: I can imagine why.
01:23mooch: it looks like mine will be the first to do so
01:24mooch: since your tests are helping
01:24mwk: that's just great
01:25mwk: I have an invisible piece of state and no way to read it
01:25mooch: that just shows you how truly psychotic early nvidia hardware designers were
01:25mwk: I guess I'll just forget about it until I get to 3d rop tests
01:26mooch: that's probably what will be needed, yeah
01:26mwk: oh, and I'll make sure not to restore the damn context with d3d6 class active
01:26mooch: tbh it probably does the same thing with the d3d5 class active too
01:26mwk: I tried
01:26mooch: really? wow
01:27mwk: only 0x55 and 0x95 cause mangled values
01:27mooch: which ones are those?
01:27mwk: D3D6_NV4 and D3D6_NV10
01:27mooch: what does d3d0 do btw?
01:27mwk: it's the NV3 3d class
01:28mooch: i thought d3d5 was that
01:28mwk: I have no idea what d3d version it really corresponds to
01:28mwk: nope, d3d5 and d3d6 are NV4 classes
01:28mooch: or is d3d5 the nv4 version of it?
01:28mooch: oh, weird
01:28mwk: both are new on NV4
01:29mooch: i might look to implement a speed hack to where pgraph mmio state is ignored, and pfifo access is the only way to set pgraph regs
01:29mooch: but of course, you'd be able to disable that
01:31mooch: i'm also looking to implement an opengl rendering backend to speed things up
01:31mwk: implementing bit-perfect NV4 rendering as OpenGL shaders is going to be such a fun project!
01:31mooch: no, i won't do bit-perfect in the opengl renderer
01:32mooch: that's only if i mess with a compute-shader renderer
01:32mwk: come on, that's no fun :(
01:32mooch: bit-perfect opengl renderers are impossible lol
01:32mooch: there will be a software renderer tho
01:32imirkin: that's quitter talk
01:32mooch: actually, two, just like for voodoo
01:32mooch: one is standard, the other is a jit
01:33mwk: are you going to implement the NV4 rasterizer as a JIT?
01:33mwk: hmm, fun
01:33mooch: it's the only way to get respectable speeds lol
01:33mooch: same with nv3
01:33mooch: and nv5
01:34nyef: mooch: You've got me curious. What exactly are you working on?
01:34mooch: nvidia emulation in a pc emulator
01:34mooch: that emulator being 86box
01:34nyef: Ah. I don't think I've heard of that particular emulator, but neat!
01:35mooch: nyef: you should help
01:35mooch: i've got a couple of weirdass bugs with your name on em!
01:36mooch: one being the fact that on certain motherboards, the bios programs the wrong vga dac values
01:36mooch: another being nt4's pfifo bug
01:36mooch: on nv3 specifically
01:36mooch: i currently have no way to run nv4 on nt4
01:36mooch: or nv5
01:37mooch: also, pfifo pio mode isn't implemented lol
01:42nyef: Hrm... PS2 emulator?
01:44imirkin: PS2 had something else... PS3 had a G70-type gpu (much much newer than the gpu's they're talking about - had full shader support, etc)
01:45imirkin: xbox had a NV2A - still a bunch newer (but *highly* limited shaders, if you can call them that)
01:46mooch2: vertex shaders, and pixel register combiners
01:46mwk: ... and texture shaders
01:47mooch: seriously? weird
01:47mwk: the most hilarious item in this set
01:47mooch2: probably not as good as NV25's, but oh well
01:48mooch: dam, that posted WAY later than it was supposed to
01:49mwk: NV2A's feature set should actually be pretty much identical to NV25 when it comes to what it could render
01:49mwk: the NV25 new stuff is basically all performance optimizations
01:49mooch: that's a bit different from what nv15 did, afaik
01:50mooch: or even what nv17 did
01:50mwk: it's the same as NV17 really
01:50imirkin: nv17 added hiz...
01:50mwk: NV17 == NV11 + perf optimizations, same for NV25 vs NV20
01:50mwk: hiz is most definitely a performance optimization :)
01:50imirkin: but yeah, not much in terms of new rendering features.
01:51mwk:hopes he can start figuring what the fuck it is soon
01:52mooch: didn't nv17 have zcull?
01:52mwk: yeah, aka hiz
01:52mwk: zcull was independently introduced on NV17 and NV25
01:53mwk: welll... actually I think they made NV25 and then hammered the new features (zcull and clipid) until they sorta fit NV11 and released the result as NV17
01:55mwk: I mean, they didn't even bother to fix ZCULL offset width to match NV1x memory architecture
01:56mwk: all VRAM addresses on NV1x are 27-bit, except ZCULL addresses which are 30-bit (like everything is on NV2x)
01:56imirkin: cut & paste of hdl is so much easier than editing
01:57mooch2: i wonder if we'll ever see the hdl of the nv3 even lol
02:14mooch2: mwk: maybe you should help directly with the nvidia emulation! you could learn EVEN MORE about the hardware! :D
02:23mwk: yay, seems I finally got the damn mangling tests to work
02:24mwk:will not be convinced without some serious proof though, 1000000 iterations time, 2 machines
02:38imirkin: you've been fooled before...
02:41mwk: setting celsius mmio reg on NV10 [not other NV1x] while current class is set to SIFM or IIFC causes a lockup
03:18nyef: ... Almost have a working test environment. Managed to have NFS as a module while trying to use it as a root filesystem.
03:19imirkin: you need an initramfs with that...
03:19imirkin: why not just build nfs in?
03:20nyef: Exactly. The initramfs for some reason didn't help, so I just changed the kernel config, tweaked the hack that I'm trying in the nouveau driver, and kicked off a build.
03:23nyef: On the upside, I have PXE working enough to bring in a kernel and initrd, and a root filesystem waiting to be mounted.
03:24imirkin: nyef: i have to add "nolock" to my nfsroot line, fyi
03:24imirkin: i never spent the time to figure out how to get lockd working
03:25nyef: So noted. One step at a time, though. (-:
03:26imirkin: root=/dev/nfs nfsroot=192.168.3.1:/usr/armv7a-hardfloat-linux-gnueabi,nolock,v3 rw ip=dhcp
03:26imirkin: that's what i use
03:26imirkin: [adjust to taste]
03:29nyef: Seems like the most common thing I'm doing is passing a kernel directly and a root-path option from the dhcp server, but that'd be because basically everything that I try to boot this way uses bootp-capable firmware.
03:29nyef: Something is configured for yaboot, though. Going to have to look up which machine that is.
03:29imirkin: ah yeah, getting yaboot working took a bit of doing
03:29imirkin: happy to share configs if you like
03:29nyef: Ah, the mac mini g4... Which I thought was running its internal disk?
03:30nyef: ... And the alpha isn't configured for ANYthing other than an IP? What?
03:30imirkin: [i have a g5 PowerMac7,2 lying around]
03:30imirkin: er, make that 7,3
03:31nyef: Going to have to fix that, now that I've put OpenVMS on the local disk.
03:31nyef: I have a few G5 systems kicking around. Some of which have nVidia graphics hardware.
03:32imirkin: i bought this one for like $30 specifically to get stuff going again on nouveau + bigendian
03:32imirkin: it was ... a very partial success
03:32nyef: Every time I decide to set up a PPC mac, I find that the graphics situation is broken in some way or another, be it nouveau or radeon.
03:32imirkin: things kinda work, but not really that well
03:33imirkin: but not as poorly as they did before my fixes :)
03:33nyef: Urgh. If this compile were running to a local disk instead of NFS, it'd've been done twice over by now. /-:
03:34nyef: Mmm. The point of this, though, is to get everything deployed to my target root filesystem without extra steps.
03:34imirkin: ah yeah. i build stuff locally with gentoo's crossdev thing
03:34imirkin: i can use emerge to cross-compile. pretty neat. mostly works, not 100%
03:35nyef: I have a cross-AVR, but I'm not about to put in the effort to set up a cross-x86 to run on MIPS.
03:36imirkin: with gentoo it's pretty straightforward.
03:42nyef: Looks like the default options for an nfsroot include nolock.
03:44imirkin: hm ok
03:44imirkin: might be cargo-culted from another thing
03:47nyef: Okay, now for the dangerous bit: Swapping batteries.
03:48nyef: ... And done.
03:57nyef: There's no easy way to switch DPMS off without X, is there?
03:57imirkin: probably a fbcon setting
03:58mwk: obviously, junk state was the hardest to model by a wide margin.
03:59imirkin: nyef: according to google: setterm -powersave off -blank 0
03:59mwk: many sins were commited while writing hwtest, but that one makes me cringe...
03:59nyef: imirkin: Thank you.
04:00imirkin: haven't personally tried it
04:03mooch: mwk: geez, that's impressive
04:03mooch: how did you figure out PIPE without hanging your gpu a bunch?
04:03mwk: mooch: who said I didn't hang my GPU a bunch?
04:03mooch: fair enough
04:04mwk: PIPE is easy to handle once you know which addresses are valid and which will hang
04:04mwk: also, note that I'm only modeling about half the PIPE state right now
04:04mwk: and it's the way easier half
04:04mwk: quite forgiving, too
04:04mooch: i have a hacky version of the point method implemented
04:05mooch: just to hopefully get something drawing in the event that nt4 starts working
04:05mooch: or hell, if i can get linux to start being a viable testbench!
04:05mwk: but... figuring out which addresses are valid took a lot of hours and involved pressing reset a lot
04:06mooch: i bet
04:07nyef: imirkin: Doesn't seem to be quite right in terms of parameters, but does seem to be the right tool.
04:07mwk: there are 4 more readable PIPE areas left to model, and 3 of them are scary
04:07mooch: i could probably use the pfifo tests a lot more right now tho
04:07mooch: how scary?
04:07mwk: 2 of them are fucking scary, 1 is merely ordinarily scary
04:08mooch: which are the ones that are "fucking scary"?
04:09mwk: 0x200:0x2c0 and 0x800:0xc00
04:09mwk: they store post-transform vertex data
04:09mwk: reading them is easy, but writing them goes through the T&L engine
04:09mwk: also, they may or may not actually be the same area, I'm not sure
04:10mooch: oh sweet jesus
04:10mooch: so you've gotta model matrix multiplication and shit like that
04:10mwk: 0x200:0x2c0 stores the 3 inflight vertices for the Celsius class, 0x800:0xa00 stores the 16 vertices of the D3D classes
04:11mwk: yeah, matrix multiplication
04:11mwk: and nvidia has its own brand of floating-point format for that
04:11mwk: that's going to be lots of fun
04:11mooch: oh jeez
04:11mooch: so i'm gonna need softfloat for my emulator
04:11mwk: though matrix multiplication is not the scariest thing going on in T&L
04:12mooch: then what is?
04:12mwk: OpenGL light calculations involve a) vector normalization, b) exponentation
04:12nyef: Hrm. Looks like nouveau isn't setting the panel power state to D3 with this. I'm not sure how good a test case it is.
04:12mwk: and vector normalization means floating-point division
04:12mooch: oh jesus
04:13mwk: FWIW you need a bit of softfloat for D3D as well
04:13mwk: they mostly convert stuff to integers as soon as possible, but eg. perspective calculations are done on floats, I think
04:14mwk: that's going to be the scariest part of D3D for me, probably... interpolating attributes
04:15nyef: Okay, new test to try: IIRC, there's a way to force the suspend logic to only do devices and then resume without putting the rest of the system to sleep.
04:19nyef: ... Which works Just Fine. Damnit.
04:20wrl: hey, I have a major issue with nouveau. I'm getting a segfault in libdrm_nouveau.so.2 when trying to create two openGL contexts inside the same process.
04:20wrl: the segfault happens in a glBufferData call
04:21wrl: these contexts both exist on their own separate threads and do not interact
04:21imirkin: wrl: nouveau does not presently deal well with concurrent use of multiple GL contexts from separate threads.
04:21wrl: imirkin: ok. I am at a bit of an impasse here, then, because the binary nvidia drivers have ceased to work on this system for one reason or another.
04:22wrl: are there any plans to improve this situation inside nouveau?
04:22imirkin: i had some hackpatches available, but then fools started to try to merge them into distro builds against my express instructions, so i've taken them down.
04:23imirkin: there is work currently underway (not by me) to fix this up properly
04:23imirkin: but i don't know when that will be complete. it's a large project.
04:42nyef: Okay, checked all of the links for relevant-seeming patches that Jeansf suppliedd, and they're either not-that-relevant-seeming or already-applied. So that's my backlog caught up, basically.
04:45nyef: So, I can: Grovel through ACPI tables looking for likely-looking things, grovel through system specs and nouveau sources looking for likely-looking things, or grovel through the available parts of the nvidia kernel module source looking for likely-looking things.
04:47nyef: ... Or just plain take a break for a while.
04:51nyef: Hypothesis: There may be a gmux or similar in this mxm, and it's getting deconfigured WRT the eDP (though plausibly not the LVDS) during ACPI suspend. The panel gets woken up on resume, but because the gmux is misconfigured, no signals get to the panel, and it puts itself back into low-power mode because of that.
04:52nyef: Places to look for confirmation... vga_switcheroo, and the mxm spec.
04:55imirkin: nyef: Jeansf is a troll. you can pretty much ignore everything he says.
04:55imirkin: he appears under many guises here
04:56imirkin: i keep banning him, but he keeps popping up
04:58mwk: aaand there are 4 vectors in this PIPE area not covered by methods
04:58mwk: which nouveau apparently initializes to some important-looking consts
05:19nyef: imirkin: A troll he may be, or even merely afflicted with diahrrea of the mouth, but some of the links that he provided were quite relevant. I can certainly understand you banning him, and I might well so do were I in your place, but at this point I acknowledge that he's been somewhat helpful to me... Even if I do have to run basically everything he says through coherency and relevance filters.
05:21imirkin: duly noted
05:40nyef: ... The MXM spec says that there can be a MUX, that it can be implemented either for direct control by the MXM (in which case there should be obviousities in the Output Device Structure and GPIO Device Structure), or via an SBIOS interface.
05:42nyef: ... SBIOS is "System BIOS", which is about what I figured. Good.
05:55nyef: Looks like SSDT5 has the LVDS panel as PEG0.DGPU.LCD0 and the eDP panel as PEG0.DGP0.DSP1.
06:00nyef: ... And I need to dig up an ACPI spec. Tomorrow.
07:21nyef: No MUX, and now I'm badly late for getting some sleep.
16:07nyef: ... didn't think nouveau.runpm=0 would help, and was right.
16:08nyef: AFAICT, there are two devices in the system ACPI tables with _DOD methods. I have no idea what's going on there.
16:16nyef: Looks like the GFX0 object in the DSDT is for a not-present PCI device, while the mess in SSDT5 is for the MXM. Good enough, I guess.
16:17imirkin_: one might imagine it's for the intel gpu
16:22nyef: Right. And I'm not in much of a hurry to swap panels around to get an lspci of the system with the LVDS instead of the eDP.
16:28nyef: So, no MUX. No confusion about which ACPI device is the MXM.
16:28nyef: The panel definitely gets power post-suspend, because it comes up briefly with some garbage and flickering, then goes to black.
16:29nyef: No response on the aux channel post-suspend.
16:33mjg59: nyef: Did the system ship with eDP or LVDS?
16:36nyef: mjg59: It's a build option, apparently.
16:36mjg59: Hm, interesting
16:36nyef: The system is an Alienware m17x R4, if you want to look it up.
16:37nyef: Both the LVDS (ACPI LCD0) and eDP (ACPI DSP1) devices have _DGS methods, but they're literally identical.
16:38nyef: ... I'm thinking that the ACPI side is probably a dead-end.
16:40imirkin_: nyef: do you have an easy way to test whether this works properly on windows?
16:40imirkin_: nyef: and/or with blob drivers?
16:41nyef: Works fine with the blob.
16:42imirkin_: hmmmm.... i wonder if it's possible to mmiotrace across a suspend
16:46nyef: There's some indication that it's possible, or failing that would it make sense to rmmod the blob, suspend, resume, enable the mmiotrace, and then reload the blob?
16:46nyef: (It's been a LONG time since I've tried to use mmiotrace.)
16:46imirkin_: yeah, that'd work
16:46imirkin_: the latter should be fine
16:46imirkin_: or just suspend + resume + mmiotrace blob
16:59nyef: I think that my next angle is to read what the DP spec has to say about resume from D3 and initial power-on, and try to make sense of the aux channel i2c code in that context.
17:00nyef: After that, possibly playing with the blob and mmiotrace.
17:13nyef: Hrm. DPMS suspend could still be sending idle pattern over the eDP link, which has some effects on the panel power managemnt, while system D3 state would not send the idle pattern, which would have different effects on the panel power management.
17:24raboof^33c3: hi! I'm a happy nouveau user on X11, and wanting to play a bit with wayland
17:25raboof^33c3: usually when switching between vt1 and vt7 (which is where x11 is) this works fine, but when wayland is running my X session crashes
17:25raboof^33c3: excerpts from Xorg.log and dmesg at http://paste.debian.net/905233/
17:26imirkin_: if you're running it as your own user, do you have the proper permissions on /dev/dri/renderD* ?
17:27imirkin_: tbh, i suspect this is a general wayland + xwayland issue, not something nouveau-specific -- might want to try a wayland-specific chan
17:27imirkin_:has never run wayland
17:27raboof^33c3: looks like they're g+rw for the 'video' group and I'm in the 'video' group, so that seems good
17:27imirkin_: ok - the other thing with drmSetMaster is that there may only be one master at a time
17:28imirkin_: no amount of root or ownership will fix that
17:28imirkin_: and presumably weston or whatever wayland compositor you're running sets itself as the master
17:29raboof^33c3: right - so I'd want to find a way to have either x11 or wayland avoid setting itself as drm master?
17:29raboof^33c3: (this is unknown territory for me but I'd be happy to do some digging :) )
17:29imirkin_: well, if you switch to a vty, xorg should drop master
17:29imirkin_: ideally the wayland compositor would do the same
17:29raboof^33c3: ah, right
17:29imirkin_: either way, you may want to locate a wayland-specific user support chan (perhaps #wayland, but i don't know for sure)
17:30imirkin_: as i don't think that knowledge exists here. and it's the sort of thing i bet a lot of diff users deal with.
17:30imirkin_:is staying away from wayland for as long as humanly possible
17:31raboof^33c3: ah it looks like a timing issue: when I go vt1 -> vt2 -> vt7 instead of directly vt1 -> vt7 it actually works :)
17:32raboof^33c3: yeah I'm not convinced about wayland yet but wanted to test the waters a bit anyway :)
17:32imirkin_: ah ok :) and iirc xorg *really* hates it when it can't reacquire drm master when you switch back to it
17:32imirkin_: i made that mistake once when playing around with modetest, and *poof*, there went my session
17:33raboof^33c3: ouch :)
17:33imirkin_: haven't made that mistake twice ;)
17:37nyef: "wayland", "weston"? What's next, "natick", "concord", "sudbury", and "framingham"?
17:38imirkin_: probably just stops on daniels's commute :)
17:38nyef: Well, presuming that it's in towards boston, can we expect "waltham" next?
17:41nyef: Also, clearly not a commuter rail commute: It seems to fall between the southernmost north service line (south-acton/fitchburg) and the northernmost south service line (framingham/worcester).
17:44imirkin_: also daniels lives in or around london... i didn't recognize those as boston names.
17:44imirkin_: although framingham did sound familiar
17:45imirkin_: more familiar with, say, quincy or alewife. never went too far past the T's boundaries.
17:45nyef: Ah, okay, other side of the pond.
17:46nyef: Yeah, waltham is commuter rail zone 3, and the various T lines don't get out much past zone 1/1A.
17:46nyef: Well, maybe zone 2, in the case of the green line. I'd have to check.
17:47mjg59: Yeah Daniel's more Walthamstow than Waltham
17:48nyef: Okay, West Newton (framingham/worcester line) is Zone 2, and it's roughly in the same arc around the hub as Riverside, which is green line.
17:49nyef: On the other hand, they're a fair distance apart. It's a bit of a walk.
18:46mwk:wonders how hard it'd be to hack up a quick test for the combiners themselves
18:55Yoshimo: what exactly does the stuff from hwtest do?
18:56Yoshimo: compared to lets say piglit test suite or a unigine heaven benchmark
19:11mwk: Yoshimo: sends random commands to the GPU, compares results with a software model
19:11mwk: it's a reverse engineering tool
19:20nyef: mwk: For rasterizing commands, does it also check the contents of memory afterwards?
19:27mwk: nyef: that's the plan
19:27mwk: I only have a few rasterizing commands right now
19:27nyef: Okay, cool.
19:28mwk: I'm going to do them last, since there's a lot of things that need to be covered before you get to actual rasterization
19:29nyef: Yeah, that I can see.
19:30mwk: DMA engine setup, pre-draw checks, render surface setup... it's a big mess
19:30mwk: so far I only have a few limited rasterization tests, eg. testing only the blending part of the pipeline
19:37nyef: Hunh. auxg94.c and auxgm200.c are basically identical except for some register offsets?
19:47mwk: one day, I'll have to sit down and clean up all the names in envytools
19:48mwk: TLVERTEX_RHW, TLVERTEX_M, tlv_rhw, tlv_w... all the same thing
20:06sacarde: in archlinux with xf86-video-nouveau 1.0.13, I have error:
20:07sacarde: nouveau 0000:00:0d.0: bus: MMIO write of 00000000 FAULT at .....
20:07sp82: Hi all
20:07sp82: Hi sacarde
20:08sp82: what GPU do you have?
20:08sacarde: NVIDIA Corporation C61 [GeForce 6150SE nForce 430]
20:09sp82: GeForce 6150SE is a GPU?
20:10sacarde: graphical card
20:11sp82: sorry, I understand
20:12sp82: it's a GPU of NV40 family
20:13sp82: I'm here for a similar error on a GTX970
20:13sacarde: in alternative I use nvidia-304xx driver
20:15sp82: I would like to use Fedora25+Gnome3 on Wayland but the Monitor turn off after few seconds with the GTX970.
20:16sp82: I would like to compile the last nouveau driver and the other parts of the graphic stack but I can't find a tutorial/guide to do this.
20:18sp82: If someone have some tutorial to share please post an url.
20:24sacarde: https://nouveau.freedesktop.org/wiki/InstallNouveau/ ?
20:30Tomin: sp82: is it 4GB model?
20:33Tomin: there is a known issue and nouveau doesn't work with it. unless some patch (that I can't provide) is applied to disable part of the memory
20:43sp82: Yes is the 3.5GB+0.5GB model
20:44sp82: The worst Maxwell GPU I think
20:45sp82: With also other problems! on windows games hang out because a bug on the firmware that low the voltage before low the frequency in some scenes where the GPU utilization drop
20:46sp82: I'm tired of this orrible thing
20:47sp82: AMD Polaris GPU look really good right now!
20:47sp82: but I'm waiting Vega GPUs
20:49nyef: So, I'm thinking suspend, resume, log in via ssh, enable mmiotrace, load the blob, see what happens.
20:51nyef: If it manages to resume the panel, I need to take a look at the trace, particularly with respect to the AUX channel on whichever output it is.
20:52nyef: Oh, and I should also test by enabling mmiotrace, loading the blob, and then doing a suspend/resume cycle.
20:53nyef: Either way, waiting on building a kernel with mmiotrace that is compatible with the blob that I have available.
21:10sp82: Hi nyef, I will try to enable mmiotrace, but first I need to understand what it is! Like I said it's difficult to start build everything from source and try the lastest stuff without a beginner guide.
21:13nyef: sp82: Oh, sorry. I didn't mean for you. I've been trying to track down an issue with my display not coming back when I suspend-to-ram and resume.
21:14nyef: I'm currently figuring something under-documented, fiddly, and low-level.
21:17nyef: Meanwhile, I wait for stupid, slow kernel builds, for which I blame NFS.
21:17nyef: (Everything's slower with NFS!)
22:33hussam: imirkin: hi. this is somewhat offtopic but I don't know who else to ask. will a GPU get damaged if its temperature goes very low (like 20c) in a closed room?
22:34nyef: At that kind of temperature, I'd be worried about condensation.
22:35nyef: Oh, wait. Centigrade? Nevermind.
22:36hussam: yes. centigrade. the card's temperature is 50s to 60s in normal weather.
22:39nyef: For storage, at least, I wouldn't expect problems... And I'm not particularly certain that there'd be any issues with operating it at those temperatures, either (though if it's actually running it won't stay that cold for long!).
22:41nyef: At a certain point I'd start to worry about condensation frosting up the machine and then thawing, fan bearings seizing up due to the lubricant freezing, things like that. But that's fairly well down there in terms of temperature.
22:41nyef: And that's just general experience, not GPU-specific, so there could be other considerations I'm not aware of.
22:42hussam: ok, thank you nyef.
23:55nyef: ... "Invalid module format"?!? Aarrgghh!!