06:31night199uk: anyone can help with envytools/rnndb?
06:32night199uk: if i have a reg, e.g. in this case 0x614300, how do i look up details of that?
06:32night199uk: lookup 0x614300?
06:32night199uk: i know from nouveau source it’s displayport clock related
06:35prg_: need to specify the chipset with -a
06:36night199uk: e.g. NVD0?
06:36night199uk: what’s maxwell, something like nve0, right?
06:37prg_: e0 is kepler
06:37prg_: not sure what you'd put there for maxwell
06:37prg_: well, kepler started with e4 for some reason
06:38night199uk: [envytools]$ lookup -a NVE0 0x614300
06:38prg_: -a gm107 seems to work
06:38night199uk: PROM[0x4300] => 0
06:38night199uk: so nothing found, right?
06:39prg_: yeah, e0 doesn't exist
06:39night199uk: GM107 works better
06:39night199uk: lookup -a GM107 0x614300
06:39night199uk: PDISPLAY.CLOCK.SOR => 0
06:40night199uk: any way to get more details than that?
06:41prg_: there might be something at http://envytools.readthedocs.org/en/latest/
06:41prg_: but no idea, really
06:41night199uk: couldn’t find it there on a quick look
06:41night199uk: no worries, thanks
07:02mupuf: lookup -a GM107 0x614300 <value> will tell you more
07:03mupuf: you can also grep for SOR in the display-related xml file in rnndb
08:46jcapik: Hello everyone. I'm searching for someone, who knows whether it's possible to disable 3D in nouveau while keeping the 2D acceleration enabled
08:48imirkin: simplest way is to just remove nouveau_dri.so
08:48buhman: what does that actually accomplish?
08:48imirkin: presumably "3d" means "opengl", since 2d accel uses the 3d engine as well
08:49buhman: sounds like a terrible idea
08:49imirkin: or rather, there's a single engine, "graph" which handles all this junk
08:50imirkin: meh, i've long ago given up trying to understand why people do the weird things they do (or, most importantly, why they never lead off with their actual problem, but instead ask about the solution they've come up with)
08:50imirkin: but i'm always happy to hand out long lengths of rope to anyone asking for it
08:50jcapik: imirkin: My problem is that 3D crashes the whole X
08:51jcapik: imirkin: but when I start X with NoAccel, it makes X slow like shhhhh
08:51jcapik: imirkin: especially window moving takes saconds
08:51imirkin: do you have an enormous screen?
08:52jcapik: imirkin: two screens
08:52imirkin: do you have an enormous two screens?
08:52jcapik: imirkin: 3840 x 1080
08:52jcapik: = 2x FullHD
08:52imirkin: and are you using a compositor?
08:53jcapik: imirkin: not aware of
08:53imirkin: (and does that compositor use OpenGL)
08:53imirkin: are you using gnome?
08:53imirkin: or unity
08:53jcapik: imirkin: long time ago I remember I had to disable Composite in the xorg.conf
08:53jcapik: imirkin: but it is not there anymore
08:54jcapik: imirkin: Xfce with XFWM started via gdm
08:54imirkin: iirc xfce has an optional compositor
08:55imirkin: if you don't have accel and are using GL to composite, 3840x1080 is a lot of pixels even for llvmpipe
08:56jcapik: imirkin: well ... it behaves in a strange way .... some windows refresh quickly and some not
08:56imirkin: probably based on the size of the window?
08:56jcapik: imirkin: nope .... the same size
08:57imirkin: some other odd condition that's not immediately obvious then
08:57jcapik: imirkin: for example redrawing the content of konsole is fast .... but scrolling in pidgin takes ages
08:57imirkin: fwiw i've only very rarely had issues with opengl crashing things
08:58jcapik: imirkin: konsole is a KDE terminal app
08:58imirkin: that said, i only make light use of 3d
08:58jcapik: imirkin: in my case the 3D has strange colors and after few manipulations with the 3D object it leads to crashes
08:59imirkin: are you on ppc?
08:59jcapik: imirkin: x86_64
08:59imirkin: what gpu?
09:00jcapik: imirkin: 0f:00.0 VGA compatible controller : NVIDIA Corporation G96GL [Quadro FX 380] [10de:0658] (rev a1)
09:00imirkin: and a non-ancient kernel?
09:00imirkin: (i.e. not something dumb like 3.2)
09:01imirkin: right. that qualifies as non-ancient quite nicely :)
09:01jcapik: imirkin: ^^
09:02imirkin: ah, the infamous 406040 thing
09:03imirkin: anyways, if you want to run just that one application without nouveau's opengl impl, you can run it like LIBGL_ALWAYS_SOFTWARE=1 openscad
09:03jcapik: imirkin: I wanna kill the whole 3D if that's possible ....
09:03imirkin: yes, and as i mentioned earlier, just remove nouveau_dri.so
09:04jcapik: imirkin: would that keep the 2D accel ?
09:04imirkin: if by 2d accel you mean "X accel"
09:04jcapik: imirkin: ok thx ... gonna try
09:04imirkin: if an application is using opengl for 2d, then it won't be able to use nouveau for that
09:05imirkin: (like anything cairo-based, for example)
09:05imirkin: (like gtk3)
09:05jcapik: need to restart X
09:07jcapik: imirkin: Thanks .... it seems it does exactly what I need
09:08jcapik: imirkin: Would be nice if that could be configurable
09:08imirkin: jcapik: it is. configurable by not installing nouveau's opengl libs...
09:08jcapik: imirkin: removing files from the filesystem is a dirty hack .... I will have to do that with each update
09:09imirkin: jcapik: just don't install the relevant package
09:09imirkin: jcapik: it's also not something anyone really wants, nor something we'd encourage.
09:09jcapik: imirkin: = removing mesa-dri-drivers ?
09:09imirkin: s/anyone/a lot of people/
09:10imirkin: jcapik: oh, i guess fedora un-split-everything (or perhaps they never had it split)
09:10jcapik: imirkin: mesa drivers removal means removal of a lot of stuff
09:10jcapik: imirkin: tigervnc server for example
09:10imirkin: naturally :)
09:10imirkin: probably it needs opengl
09:11imirkin: in any case... sounds like a distro issue.
09:12jcapik: imirkin: need to leave .... thanks
09:13imirkin: skeggsb: that 406040 issue keeps coming up... i spent some time looking at it at one point, but never got any good ideas on how it's happening. it's a perfectly valid command, although i guess there's no subchan method 0x40. but i don't see how anything would even write that.
09:14imirkin: skeggsb: but lots of people have seen it on lots of nv50 hw
09:15imirkin: even i got it a couple of times... usually it's non-fatal, but sometimes it kills everything
09:15imirkin: (406040 == size 1, subchan 3, method 0x40)
09:19JethroTux: hello everybody
09:20JethroTux: i'm running nouveau driver with 01:00.0 VGA compatible controller: NVIDIA Corporation NV11M [GeForce2 Go] (rev b2)
09:20tobijk: oh ancient...
09:20JethroTux: after opening some text files xorg just freezes and I have to reboot
09:21JethroTux: this is the log file http://pastebin.com/CGA5QH67
09:21JethroTux: can anybody help? :S
09:22JethroTux: tobijk, yes, on an ancient travelmate 636LC :)
09:24JethroTux: I also tried changin' video resolutions through xrandr, but i still have the problem
09:25tobijk: that wont help at all i guess, the card just hangs up :/
09:26JethroTux: so what could it be? should the video card be damaged?
09:27JethroTux: maybe I could try switching to vesa and see what happens?
09:27tobijk: could, more likely the driver for this generation is, lets say not in a good shape
09:37imirkin_: bleh, he left. i was about to ask if he was sure it was freezing or maybe it was just slow :)
09:37imirkin_: seems like the ddx does something bad for nv11 though. not overly surprised tbh
09:38imirkin_: i should try to get my hands on one...
09:41imirkin_: hmmm... $13... not worth it. maybe if it were half that price.
10:46tstellar: Does nvidia hw support half (16-bit float) load / store ?
10:49imirkin_: pretty sure it does, but double-checking now
10:49imirkin_: er wait, what do you mean by that?
10:50imirkin_: are you talking about ARB_shader_image_load_store with rgba16f images?
10:50imirkin_: tstellar: --^
10:53tstellar: Are there fp16_fp32 conversion instructions?
10:54imirkin_: tstellar: just looked on gf100, and looks like yes
10:54imirkin_: tstellar: however i'm not sure that you can feed fp16 to regular alu instructions
10:54imirkin_: but there might be some "video" instructions that take fp16 as input
10:54tstellar: imirkin_: Probably not.
10:55tstellar: imirkin_: I mean for using with regular ALU instructions.
10:55imirkin_: i don't see anything documented, but that doesn't mean it doesn't exist... you can look for hints in the PTX ISA docs too
10:57imirkin_: tstellar: i only see f16 mentioned in float <-> int and float <-> float conversion functions
11:00imirkin_: tstellar: glanced at the ptx isa docs, they only talk about f16 as being loadable from memory and then converted to f32/f64. so i don't think (current) nvidia gpu's have a 16-bit alu path
11:01imirkin_: tstellar: however i think the Tegra X1 or its successor might...
14:06voxadam: My workstation's GPU keeps locking up and I'm trying to figure out why. It wasn't doing it with an older distro. The card in question is a 550 Ti (NVCF) on an x86_64 system running a 4.0.0-0.rc5 kernel.
14:06voxadam: I've disabled the PCE1 copy engine just like I had to do with my previous distro but it still locks up.
14:07imirkin_: voxadam: i think we removed the PCE1 stuff from GF116, so that shouldn't matter anymore
14:07voxadam: I'm typically still able to SSH into the box after it freezes. Actually, I'm connected to IRC using it right now.
14:08imirkin_: voxadam: do you have any logs or... something... after things go bad?
14:08voxadam: imirkin_: What kind of logs are you interested in?
14:08voxadam: I haven't finished enabling kdump.
14:08imirkin_: kdump is a little much
14:09imirkin_: dmesg should be enough
14:09imirkin_: hrmph, nothing
14:09imirkin_: how does the "lockup" manifest itself?
14:10voxadam: The display quits updating, the cursor corrupts, and I'm unable to switch to a text console.
14:12imirkin_: does cursor keep moving though?
14:12imirkin_: so it sounds like the display engine just craps itself
14:13imirkin_: and nouveau doesn't notice :(
14:13imirkin_: what sort of frequency are you seeing this with?
14:15voxadam: It happens frequently enough that trying to acomplish anthing using a GUI is impossible.
14:15imirkin_: can you translate that to units of time?
14:15voxadam: The machine locks up within 10 minutes of using X.
14:16voxadam: KDE Plasma 5 specifically.
14:16imirkin_: well, this is the first i'm hearing of this sort of thing =/
14:16imirkin_: there's an outstanding issue where libdrm-2.4.60 messes things up (although potentially due to no fault of its own)
14:17imirkin_: but that doesn't seem related to your current woes
14:17imirkin_: you might have to bisect i'm afraid :(
14:17voxadam: I'm running libdrm 2.4.59.
14:18voxadam: Part of me feels like ignorring the problem and buying a beter card.
14:20voxadam: Maybe and AMD. :)
14:20imirkin_: wise move
14:21imirkin_: nvidia is moving to mechanisms that will make open source implementations more difficult
14:21imirkin_: starting with the GM200 series
14:22imirkin_: there may be a future where we're able to use the nvidia blobs to operate it, but it's not like they guarantee an ABI or anything else
14:22imirkin_: and it won't be out of the box
14:23imirkin_: ben's playing with alternate ways of dealing with the issues, but they have significant perf impact
14:23voxadam: Nvidia should really quit being so hostile to the open source community.
14:24imirkin_: well, the latest problem is with their requirement of signed blobs to actually be able to operate the gpu in any meaningful way
14:24voxadam: Too bad that Intel has never been able to make a decent add-in GPU.
14:24imirkin_: they could create a service to sign nouveau-made blobs
14:24imirkin_: but that would require them to acknowledge nouveau as an acceptable way of driving desktop gpu's
14:25imirkin_: heh. iirc their last attempt was the i740 or whatever?
14:25RSpliet: imirkin_: there's some implementation difficulties with that too...
14:25imirkin_: RSpliet: with what?
14:25RSpliet: with a "signing service"
14:26imirkin_: right, it would be awkward for them to implement it
14:26imirkin_: but that's what it would take to be able to run nouveau properly
14:26RSpliet: no, in terms of responsibility
14:26RSpliet: who will get the firmwares signed
14:26RSpliet: what will compile them, in what form will they ship
14:26imirkin_: right. hence 'awkward'
14:27imirkin_: RSpliet: it's a signature though, so it'd go along with the fuc.h's that we ship already
14:27imirkin_: any fuc update would require a new signature from nvidia though
14:27imirkin_: and somehow they'd have to verify that the changes aren't the things they're trying to prevent in the first place
14:27imirkin_: which means dedicating resourcese/tc
14:59imirkin_: RSpliet: btw, how's nv50 reclocking going?
15:10voxadam__: imirkin: I managed to elicit some sort of error
15:10voxadam__: "[ 178.420490] nouveau E[ DRM] GPU lockup - switching to software fbcon"
15:10imirkin_: yay, it knows it messed up :)
15:10imirkin_: was there anything before that?
15:10imirkin_: perhaps at info or warning level
15:11voxadam__: Nothing relevant.
15:12imirkin_: bleh :(
15:14voxadam__: [ 654.990280] nouveau E[Xorg] failed to idle channel 0xcccc0002 [Xorg]
15:15imirkin_: that's a left-over of a lockup
15:15voxadam__: [ 671.991216] nouveau E[ PFIFO][0000:01:00.0] runlist update timeout
15:15imirkin_: ah there ya go. that's more interesting.
15:15voxadam__: I poked it with a stick and it responded.
15:15imirkin_: of course if that happens you're in serious trouble -- that should trigger the lockup detection i think
15:16voxadam__: That only happens after I do systemctl restart kdm
15:16imirkin_: yeah, that makes sense
15:16imirkin_: the gpu is locked up and we didn't unlock it
15:16imirkin_: so it stays broken
15:17voxadam__: I suppose that's reasonable.
15:22voxadam__: At least rebooting takes almost no time at all now that I finally got around to buying and SSD.
15:26imirkin_: voxadam__: if it's a recently-introduced issue, it'd be great to know what we did to tickle the issue
15:26imirkin_:hopes it's not a mesa change
15:28voxadam__: I'll have to mess around with it a little more. I'll pull the kernel that I was running before the distro change from the disk I was using prior to this SSD and see if it still locks.
15:50voxadam__: imirkin: I've noticed something odd... If I login to a Gnome session it doesn't freeze like it does in KDE Plasma 5.
15:50voxadam__: At least it hasn't yet.
16:17imirkin_: voxadam__: probably something it's doing in GL =/
16:20voxadam__: imirkin: You don't seem overjoyed at that possibility.
17:16voxadam__: I finally managed to lockup the GPU in Gnome. At least it took an hour this time.
17:17imirkin_: and yes, i'm underjoyed by the fact that doing stuff in GL can hang things, coz i'm the one that's been mucking with it
17:24voxadam__: It almost always seems like it locks when an an animated alpha blend is being done. The fact that the KDE devs and designers are far more enamored with the effect probably explains why KDE locks the thing so easily compared to Gnome.
23:29Weaselweb_: hi, I here have a "01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1)" (lspci) which is connected to two monitors using DVI and VGA.
23:29Weaselweb_: sometimes the DVI screen goes blank. I have to switch to a VT and then back to X to get my screen back. dmesg shows these entries http://pastebin.com/j0GA645K
23:30Weaselweb_: eh, http://pastebin.com/Ytswkc86 for this case
23:30Weaselweb_: but sometimes the screen comes back automatically which results in these dmesg entries: http://pastebin.com/j0GA645K
23:31Weaselweb_: any ideas? I have currently /sys/module/nouveau/parameters/debug: CLIENT=debug,PTHERM=info,I2C=info and CONFIG_NOUVEAU_DEBUG_DEFAULT=4