02:46 pmoreau: karolherbst: I didn't have a "using GB" message in my dmesg
02:46 pmoreau: Going to try your patch
02:53 pmoreau: karolherbst: It doesn't seem to be working. Do you print a message to confirm that you're using the patch?
03:16 pmoreau: karolherbst: Oh!! I think I missed one of the step when installing the patched version. Going to retry, and I added a message to be sure I was loading the correct one. ;-)
03:21 pmoreau: karolherbst: Oh!! It's alive!!! :-D
03:21 pmoreau: karolherbst: Good job fixing this one!
03:53 ntz: hello
03:53 ntz: simple Q:, reading this: https://nouveau.freedesktop.org/wiki/FeatureMatrix/
03:53 ntz: and my lspci says: ``01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [NVS 4200M] (rev a1)'' .... what kind is that according to the table please ?
03:55 RSpliet: ntz: the table headers (NVxx) are links that lead to a big page with codenames better explained
03:55 ntz: oh, gotcha https://nouveau.freedesktop.org/wiki/CodeNames/
03:55 RSpliet: exactly! ;-)
03:55 ntz: so according to this page it is: NVA5 (GT216)
03:55 ntz: perfect, thanks !!!
03:55 RSpliet: ... no, that's not how it works :-D
03:56 RSpliet: Quadro NVS 4200M is listed as NVD9
03:57 ntz: I'm asking because of neither nouveau neither nasty nvidia blob works .... I have in both distrorted screen but with some extend the DRI_PRIME method works for a window when Xserver runs on intel
03:57 karolherbst: pmoreau: nice :)
03:57 ntz: RSpliet: than my apologize, I thought I have 230m'
03:58 karolherbst: pmoreau: now I can start cleaning up the patch :D
03:58 RSpliet: ntz: your card should be well supported with nouveau albeit rather slow
03:59 ntz: well, I think that here's something rotten with dell implementation
04:00 ntz: RSpliet: may I ask for another question: is my assumption true, that if I have by default blacklisted a nouveau module that it saves a battery ?
04:01 ntz: heck :D
04:03 pmoreau: karolherbst: ;-)
04:15 RSpliet: ntz: I don't think that assumption is right, as there is no driver available to tell the GPU to suspend/power down
04:16 RSpliet: there's too much implementation details I'm unaware of to confirm what behaviour you might get, but I wouldn't be surprised if loading nouveau reduces power consumption
04:16 ntz: RSpliet: at least my powertop is "more" happy if no nvidia module is loaded
04:17 RSpliet: powertop doesn't measure performance, just lists everything that might be consuming power. If it doesn't detect your GPU (because no driver is loaded), it wouldn't recognise it as a potential power drain
04:18 ntz: that makes sense :D
04:18 ntz: indeed
04:18 RSpliet: I never played with optimus set-ups myself, so I know too little about all the details in the system, but the only reliable way to tell is by checking consumption through a power meter (either hardwired to your laptop while the battery is unplugged or some integrated thing you can access from software)
04:19 ntz: RSpliet: however I have some feeling that I've already in past googled out resolute confirmation that in case of nvidia devices saves blacklisting the driver battery life significantly
04:19 ntz: ok, fair
04:19 ntz: thanks much for your respones
04:19 RSpliet: keep in mind that device drivers mature faster than the internet. What was true a year ago might no longer be true today :-)
04:21 pmoreau: skeggsb, gnurou: Thank to your work, I can run the Titan X with Nouveau! :-)
04:21 pmoreau: Just missing CUDA support to be useful at work… O:-D
04:21 RSpliet: pmoreau: wow, good stuff!
04:21 RSpliet: heh, well, just fix OpenCL support and write your software properly :-P
04:21 pmoreau: :-D
04:22 karolherbst: ohh titan x is the maxwell one
04:22 pmoreau: We might be using CUDA features that aren't present in OpenCL, but I would have to check.
04:23 pq: ntz, maybe "switcheroo" is the thing you are looking for, I hear it should be able to power off GPUs, but I don't know if it needs an actual driver like nouveau to do it.
04:23 pmoreau: And well, I'm certainly years away from having all the OpenCL stuff I would need! :-D
04:23 pmoreau: karolherbst: Yep ;-)
04:24 ntz: pq: it's all terrible crap ... I now only need to resolve problem with my docking station .... I have on laptop chassis a vga out which works but on docking station is dvi-out which hardwired with nvidia gpu only so I presumed that when in office (and on ac power) I can use nvidia only gpu
04:24 ntz: **which is hardwired
04:25 ntz: but when I try to use nvidia only gpu I have completely distorded display - and with dirty nvidia blob too so I'm starting to think, that's something related to dell implememntation
04:26 ntz: when I use DRI_PRIME=1 it works
04:26 pq: I was only referring to your desire to save battery
04:27 ntz: I mean for given window so it leads me to thinking, that this nvidia is screwed up but not completely
04:27 ntz: pq: ah, fair
04:27 ntz: pq: I have normally nouveau blacklisted ....
04:28 ntz: # grep -rI nouveau /etc/modprobe.d/
04:28 ntz: /etc/modprobe.d/99-local.conf:#options nouveau vram_pushbuf=1
04:28 ntz: /etc/modprobe.d/50-blacklist.conf:blacklist nouveau
04:28 pq: but with switcheroo you could actually turn off the gpu, rather than let it idle
04:28 ntz: hmm ... thanks for pointing that out
04:28 pq: if it's not off already
04:28 ntz: I'll need to take a closer look at switcheroo then
04:28 pq: I think that might pay off, yeah :-)
04:29 pq: I believe turning off a GPU can cause it to disappear from the PCI bus, so maybe it's not off by default...
04:29 pq: or something, I'm just rambling
04:29 ntz: I don't think so
04:30 ntz: in regard to that I have visible nvidia gpu in lspci but no driver is loaded and nothing uses it all
04:31 pmoreau: Hum, it looks like I'm not using 3d accel…
04:32 pq: ntz, see what happens if you get switcheroo to actually switch it off :-)
04:32 pq: or to say it's off
04:33 ntz: pq: I'll test it before leaving office and will let you know about result
04:33 pmoreau: gnurou: Should there be any specific message saying it found the signed firmware or not (on GM200)?
04:33 RSpliet: pq: shouldn't prime take care of that? (who's the expert on this? mlankhorst?)
04:35 pmoreau: gnurou: I didn't seen any complaints in the dmesg, but when starting X I get that the screen isn't DRI2 capable.
04:36 pq: RSpliet, I have no idea, I thought prime was only about using gpus, not switching their power mode.
04:36 pmoreau: Same here, I don't think prime is changing power modes.
04:38 pmoreau: RSpliet: Nouveau is registering as a switcheroo client, to get the power mode switches. I don't remember it doing the same with prime.
04:39 pmoreau: Meh, I forgot… How do you solve this "[ 202.788] EGL_MESA_drm_image required. [ 202.788] (EE) modeset(0): glamor initialization failed" again?
04:43 karolherbst: pmoreau: is that on your titan?
04:43 pmoreau: Yep
04:45 pmoreau: (Using modeset)
05:02 gnurou: pmoreau: if you got no complain in the kernel logs and can see /dev/dri/renderD128, then you should be good
05:02 gnurou: pmoreau: I definitely could run Mesa programs with X (GLamor) and Mesa's current master
05:03 pmoreau: I do see renderD128.
05:03 pmoreau: You were using modeset as well as DDX, right?
05:03 gnurou: no, DDX will not work with GM2
05:03 gnurou: you must use modeset + GLamor
05:04 mupuf: which happens to be the default :)
05:04 pmoreau: Ok, didn't know modeset wasn't a ddx.
05:04 pmoreau: So then I messed something up, since GLamor isn't happy
05:05 mupuf: pmoreau: well, it is a device-independent ddx :D
05:05 mupuf: so, it is a DIX :D
05:06 pmoreau: :-D
05:06 mupuf: ddx == device-dependent X
05:06 mupuf: so... gnurou is right ... but that may be a little confusing
05:06 pmoreau: Ah, didn't really know the meaning of ddx, only that it was some middle thing between X and the driver
05:09 mupuf: well, the xf86-video ddx are not really in the middle of anything
05:09 mupuf: they just provide the 2D accel, XV support and call the right functions in the kernel to present the buffers
05:09 mupuf: oh, and cursor management too
05:34 gnurou: well, technically GLamor takes the place of a DDX, so it may still be correct to call it that way
05:35 gnurou: the *Nouveau* DDX, OTOH, will not work with Maxwell 2
05:35 gnurou: pmoreau: are you using Mesa git?
05:50 pmoreau_: gnurou: Yep, Mesa git as of two hours ago
05:51 pmoreau_: And yeah, I fully agree that xf86-video-nouveau isn't going to work, just wanted to be extra sure.
05:51 gnurou: mmm I had absolutely no problem with that configuration, so I'm surprised it doesn't work for you
05:51 pmoreau_: (And I tested to be even more sure: and got unknown chipset)
05:51 pmoreau_: :-/
05:52 gnurou: unknown chipset?
05:52 mupuf: gnurou: he is talking about the ddx
05:52 gnurou: ah ok
05:52 mupuf: when you force using nouveau, it says the chipset is unknown
05:52 gnurou: as expected
05:52 gnurou: pmoreau_: maybe try with a DRM program, like kmscube, to see if it renders?
05:52 mupuf: well, it is not the best user-friendly way of doing it, but it works
05:53 pmoreau_: I guess I could run in that scenario (no accel), if I failed to load the correct Nouveau module (i.e. the one from your secboot branch).
05:53 gnurou: if that doesn't work, please send me your dmesg so I can check if there is an issue with secure boot
05:53 gnurou: yeah exactly, which is why I would like to confirm with kmscube or something equally simple
05:54 pmoreau_: gnurou: Any specific parameters to pass? Debug, whatever, etc. ?
05:54 pmoreau_: Ok, will do that later. I rebooted to windows since I needed to work :-D
05:54 gnurou: the kernel should print an error if something goes wrong, so no
05:54 imirkin: pmoreau_: modesetting is a ddx :)
05:54 gnurou: pmoreau_: yoroshiku
05:54 imirkin: ddx is xf86-video-* :)
05:55 pmoreau_: imirkin: \o/
05:55 imirkin: in this case, modesetting.
05:55 gnurou: ah, so what is GLamor then? the other half of the DDX?
05:56 imirkin: glamor is a helpful library
05:56 pmoreau_: gnurou: I'll add a print message in your tree, just to be sure I loaded the correct module, and try again kmscube. :-)
05:56 imirkin: which provides X-ish drawing functions implemented with the help of GL
05:56 gnurou: pmoreau_: would be great, please let me know the outcome
05:56 gnurou:goes to sleep
05:57 imirkin: the modesetting DDX and radeon and amdgpu use it to provide acceleration of various X ops
05:58 pmoreau_: gnurou: oyasuminasai
05:58 gnurou: imirkin: ah, that's enlightening. thanks!
07:11 Fakeboost: Hello, is there some settings editor or configuration program for nouveau?
07:12 imirkin: not really... shouldn't be anything to configure...
07:15 Fakeboost: mm, i notice definition differences with the nvidia driver
07:20 mupuf: Fakeboost: oh, you can use xrandr for this
07:20 Fakeboost: great, how do i use it?
08:19 karolherbst: pmoreau_: I cleaned up the mmiotrace patch, do you want to test the new version?
08:19 pmoreau_: karolherbst: Maybe? :-)
08:20 karolherbst: pmoreau_: https://github.com/karolherbst/linux/commit/560ac3f796c8c64a2101c44a8f66a5bcfc739e55
08:20 pmoreau_: Well, probably not now. I'm wrapping things up before going home, but later, sure.
08:21 karolherbst: thanks a lot :)
08:21 karolherbst: I removed all my stupid switch statements :)
08:21 pmoreau_: :-D
08:22 karolherbst: yeah, the kernel already has macros for these, so the patch got a lot smaller now
08:22 pmoreau_: Eh eh eh!
08:23 pmoreau_: I guess checking for macros isn't the first thing that comes to mind (definitely not in my case)
08:23 karolherbst: so instead of using the page id, the kmmio code now uses the page_table base address and gets all the needed information from there (size as the only one?)
08:23 karolherbst: well, I was pretty sure while coding this, that there are macros, but I was too lazy to look them up
09:02 damex: nouveau can suspend videocard during optimus setup. is it still consuming something?
09:02 karolherbst: damex: it shouldn't
09:04 damex: okay, thanks ;p
10:04 karolherbst: mhh playing games while having apitrace running isn't much fun. Is there a way to reduce apitraces overhead?
10:06 mupuf: karolherbst: not really no :s
10:11 karolherbst: maybe I expect too much though, fullhd at highest settings :D
10:11 karolherbst: (and 2x msaa)
10:11 mupuf: that is not really what makes it slow
10:11 mupuf: it is the cpu-side
10:11 mupuf: and increasing the resolution does not change anything
10:13 karolherbst: ahh okay
10:13 karolherbst: I expected that maybe some synchronous opengl commands could take more time
10:18 karolherbst: mupuf: but more opengl commands make it more slow, right?
10:19 imirkin_: sure
10:19 imirkin_: but higher res doesn't mean more opengl commands
10:20 karolherbst: yeah but I also run the game at highest settings
10:20 imirkin_: yeah, just resolution doesn't matter
10:31 karolherbst: thing is, I have no clue what was causing my issue :/
10:42 karolherbst: Tom^: I think I notice your gun fire issue
10:43 Tom^: :<
14:26 Adis: Is anyone alive
14:27 imirkin_: only zombies. it's 28 days later.
14:27 karolherbst: *ruahgshawwr*
14:30 RSpliet:eats imirkin_'s brains and gains his knowledge
14:32 imirkin_: can't drink from an empty cup...
14:42 nv3x_fix: hello. i have made a test with nouveau and get a non propper working card.
14:43 nv3x_fix: an old geforce 2 with 32mb VRAM works fine with full-hd screen and can read out EDID. A geforce FC5200 with 128MB RAM fails to read EDID on VGA and give only reduces resolution on DVI
14:44 imirkin_: nv3x_fix: is it a large-resolution screen perchance?
14:44 nv3x_fix: full hd. just normal 1920x1080
14:45 imirkin_: yeah, that's large by those metrics
14:45 imirkin_: i think nv3x's TMDS is limited to 135mhz
14:45 nv3x_fix: imirkin_: geforce 3 ti 200 also works fine with 1920x1080. geforce 2 with 32mb also works fine
14:46 imirkin_: which even with a reduced-blanking mode thing doesn't get you 1920x1080
14:46 imirkin_: yes, i bet if you used a vga cable, it'd work
14:46 nv3x_fix: imirkin_: the card fails to read out EDID on VGA connector. this works with a 2MB PCI card from 1996 i tested before 10 minutes
14:46 imirkin_: wait, is this DVI or VGA?
14:46 imirkin_: the reduced resolution on DVI is expected
14:47 imirkin_: due to hw limitations of the digital transmitter
14:47 imirkin_: failure on VGA is unexpected
14:48 nv3x_fix: imirkin_: again. geforce 2 and geforce 3 works fine with VGA and full hd. geforce FX5200 fails to load EDID and thats why i get 1024x768
14:48 imirkin_: nv3x_fix: that it works on some other gpu's is irrelevant.
14:48 imirkin_: (ok, it's mildly relevant)
14:49 imirkin_: i have no idea why it'd fail to read EDID... is there anything odd about your setup?
14:49 imirkin_: perhaps you're using a DVI <-> VGA adapter?
14:51 nv3x_fix: strange. at this bootup i cant see the edid read error. but resolution is terrible. here the xorg output: http://pastebin.com/bHJ2agvH
14:51 nv3x_fix: the whole desktop is also rather slow. slower then on a geforce 3
14:51 imirkin_: [ 3.496259] nouveau [ DRM] allocated 1024x768 fb: 0x9000, bo f5c43800
14:52 imirkin_: yeah, so that's screwed
14:53 nv3x_fix: imirkin_: yes. can i help fixing?
14:53 imirkin_: you could answer my questions
14:53 imirkin_: like.. are you using a DVI <-> VGA adapter?
14:54 nv3x_fix: sorry, i missed them. no. My screen have separate DVI and VGA cables. the card itself have one vga, one TV-out, and one DVI connector. Now i am runnint on VGA cable to VGA connector
14:54 imirkin_: do you happen to be in posession of a DVI <-> VGA adapter?
14:55 imirkin_: if so, try plugging the vga cable into that, and sticking it onto the card's DVI output
14:55 nv3x_fix: what does "posession" mean? sorry, my english is not that good.
14:56 imirkin_: do you have one available to you?
14:56 nv3x_fix: if you mean "did you own a dvi->vga adapter?" then yes, i have one and can test it
14:56 imirkin_: right :)
14:57 nv3x_fix: ok, i power down now. see us in some minutes :)
15:03 nv3x-fix: imirkin: you was right. i got full-dh on the dvi connector of the card with a dvi->vga adapter and the vga adapter of the screen
15:04 imirkin_: ok, so it sounds like there's some issue with that VGA connector
15:04 imirkin_: perhaps the i2c bits aren't hooked up
15:04 imirkin_: or perhaps nouveau is driving them wrong
15:06 nv3x-fix: i connected now the DVI cable to DVI. Maybe you can tell me why i get only 1600x900. here is the xorg log: http://pastebin.com/9q42CY1y
15:06 imirkin_: nv3x-fix: because the TMDS hardware on nv3x only supports up to 135MHz pixel clocks
15:07 imirkin_: so the 1920x1080 mode gets thrown out... it's a 148mhz mode it seems
15:07 nv3x-fix: thats really strange for me to understand that at some poing a VGA connector was able to give a higher resolution then the "new" DVI connector
15:07 imirkin_: yep
15:08 imirkin_: but that's the reality
15:08 imirkin_: remember screens of this size were pretty rare back then
15:08 imirkin_: it was enough to drive 1600x1200 i think
15:09 glennk: took a while before DVI passed what VGA was capable of back then
15:10 imirkin_: nv3x-fix: take a look at http://www.nvidia.com/page/pg_20040109440047.html
15:10 imirkin_: "Dual RAMDACs (up to 400 MHz) for display resolutions up to and including 2048×1536 @ 85Hz" (that's the vga)
15:10 imirkin_: "DVI support for compatibility with nextgeneration flat panel displays with resolutions up to and including 1600×1200"
15:10 nv3x-fix: ok, so no fix possible. Maybe it were nice if you could add some xorg/dmesg output of nouveau for people like me that didnt know that. i think most people didnt know this fact
15:11 nv3x-fix: something like "EDID reports higher possible resolutution and nouveau detected VGA connector. Use VGA to get max possible resolution"
15:13 nv3x-fix: it would be really great if you could add this note to nouveau :)
15:14 imirkin_: that sort of recommendation would be tricky to do
15:14 RSpliet: nv3x-fix: to the best of my knowledge this is logged in the Xorg log already - when it's parsing the EDID it should warn about unsupported modes
15:14 glennk: there were two issues here? one was that the EDID wasn't readable over DVI?
15:15 imirkin_: glennk: EDID wasn't readable over the VGA connector
15:15 imirkin_: it's readable over the DVI connector
15:15 imirkin_: [i mean the physical port on the board]
15:15 glennk: the log seems to suggest the opposite?
15:15 imirkin_: glennk: well there's a DVI <-> VGA adapter plugged onto that DVI connector
15:16 glennk: connector DVI-I-1?
15:16 imirkin_: yes.
15:16 glennk: which is VGA signals really
15:16 nv3x-fix: glennk: no, the EDID was reported as not read once i boot with pure VGA cable to VGA connector of card. Then i turned off, turned on, get into this irc channel and saw in xorg some strange 1024x768 in xorg
15:17 imirkin_: glennk: sure. but there's a separate VGA-1 connector, and reading ddc over that didn't work
15:17 glennk: was looking at http://pastebin.com/bHJ2agvH
15:17 nv3x-fix: glennk: exactly like imirkin_ is telling. on DVI connector of the card with a dvi->vga adapter and the vga cable of the screen i get 1920x1080
15:19 imirkin_: glennk: yeah, but that's not a real EDID readout... that's the faked EDID that we provide when there is no real one
15:19 nv3x-fix: glennk: yes, this is the pastebin i posted. there is no warning of missing edid. but i also cant find the regular nouveau edid output i see normaly.
15:19 glennk: imirkin_, aha
15:21 nv3x-fix: imirkin_: strange is that on the first boot i didnt saved the logs from i saw red warnings in dmesg about missing edid. the time i post the pastebin (vga connector) there was no dmesg warnings any more
15:21 nv3x-fix: imirkin_: why did it show once dmesg warnings and then at an other boot none?
15:22 imirkin_: nv3x-fix: no clue
15:22 imirkin_: does it matter?
15:22 imirkin_: just be happy it's working :)
15:23 nv3x-fix: i am here to help fixing this problem and make nouveau better ;)
15:24 nv3x-fix: can i provide any logs to help fixing this problem?
15:24 imirkin_: i wouldn't know where to start, tbh
15:25 nv3x-fix: should i try first the closed source nvidia driver if i get propper resolution there with vga cable connected to vga port?
15:26 imirkin_: you could if you wanted. there's not a TON of interest around fixing up old hw though, so unless you were interested in fixing it yourself, it's unlikely to go too far
15:27 nv3x-fix: its just a bug for basic usage and i try to help fixing such bugs. i will try closed nvidia driver and then latest nouveau from latest kernel :)
15:28 imirkin_: nv3x-fix: i don't think anyone's opposed to fixing bugs, in fact, we encourage it. but these things take a certain amount of effort and knowledge, and there's only so much to go around.
15:33 nv3x-fix: imirkin_: thanks so far. when i have done all the tests and when its working (better) on closed nvidia driver i would fill up a bug
23:13 pmoreau: gnurou: kmscube works, but still no accel.
23:14 pmoreau: gnurou: have to go, will give you detais later