04:24 alexandernst: What is the state of re-clocking (even basic) for NVC0 (Fermi)? (GT620)
04:24 mupuf: nothing changed
04:25 alexandernst: so, no support yet? :(
04:27 alexandernst: is anybody working on it? Should I expect some support in the near future?
04:45 infinity0: alexandernst: the relevant code is here https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/nouveau/core/subdev/fb and no no-one is working on it
04:46 infinity0: although i just patched my kernel to allow user-level reclocking in https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/nouveau/core/subdev/clock and will test it some time tonight
04:46 infinity0: possibly the existing code might already be useful
04:46 infinity0: what card do you have?
04:46 alexandernst: a GT620
04:48 alexandernst: infinity0: can I help somehow?
04:48 infinity0: if you're using debian and have time to try it, you can change byte 114219 of /lib/modules/3.18.0-trunk-amd64/kernel/drivers/gpu/drm/nouveau/nouveau.ko from 0 to 1, restart, then do
04:48 alexandernst: nope, I'm on arch
04:49 infinity0: echo 0f > /sys/class/drm/card0/device/pstate
04:49 alexandernst: there is no pstate in that path
04:49 alexandernst: (kernel 3.18)
04:49 infinity0: do you even have a card0
04:49 alexandernst: yes
04:49 infinity0: and is that your gpu?
04:49 alexandernst: yes
04:50 alexandernst: I have no built-in GPU and 2 GT620 cards, so I have card0 and card1
04:50 mupuf: alexandernst: you need to boot nouveau with the pstate parameter set
04:50 infinity0: ok, i don't know what's up. i'm just a noob like yourself and only started looking into this yesterday
04:50 alexandernst: oh
04:50 alexandernst: ok, let me try it
04:50 mupuf: there will still be no memory reclocking
04:51 infinity0: but if you want to try what i'm trying, you can find the definition of nvc0_clock_ctor in your nouveau.ko by objdump -SF and gdb disassemble /mr (you'll need to install kernel debugging symbols)
04:51 infinity0: and figure out which byte to change from 0 to 1
04:51 infinity0: or just recompile your kernel, if you feel that's easier
04:51 mupuf: infinity0: let me tell you that you are insane :D
04:51 infinity0: kekekeke
04:52 mupuf: how can recomping a kernel be difficult? There are no dependencies
04:52 alexandernst: I think I'm confused. Do I need to patch my kernel AND enable pstate in kernel args, or just the second thing is enough?
04:53 infinity0: alexandernst: both. without patching you'll get this:
04:53 infinity0: $ echo 0f | sudo tee /sys/class/drm/card0/device/pstate
04:53 infinity0: tee: /sys/class/drm/card0/device/pstate: Function not implemented
04:53 infinity0: mupuf: i've never tried to compile linux before, but yes doing that is probably the best option
04:54 infinity0: since it's more flexible and you can change things more easily
04:54 infinity0: i was just lazy
04:54 mupuf: infinity0: you would be surprised how easy it is
04:54 infinity0: yeah i should do it at some point
04:54 alexandernst: ok, what patch should I apply?
04:55 infinity0: alexandernst: line 441 false->true, https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/nouveau/core/subdev/clock/nvc0.c?id=refs/tags/v3.18.7
04:56 infinity0: if it still doesn't work on your card (very likely), you can try to play with {ram,}nvc0.c in drivers/gpu/drm/nouveau/core/subdev/fb
05:00 Malinux: I have a geforce G 105M, running Ubuntu 14.04.1
05:00 Malinux: tried to use the nouveau-driver. I can't get higher resolution than 1280x800
05:01 Malinux: my display handle 1366x768, but I can't get that resolution
05:10 Malinux: correction. I get 1280x720 and not 1366x768, as I should have gotten :)
05:16 mupuf: Malinux: are you sure you are not using vesa?
05:16 mupuf: kernel and xorg logs please :)
05:17 Malinux: dmesg
05:17 Malinux: can't get higher resolution than 1280 x 800
05:17 Malinux: oi
05:17 Malinux: sorry
05:17 Malinux: dmesg | tail
05:17 Malinux: http://paste.ubuntu.com/10255653/
05:17 Malinux: there
05:18 Malinux: http://paste.ubuntu.com/10255674/
05:18 Malinux: thats: /var/log/Xorg.0.log
05:21 mupuf: Malinux: I want the full dmesg, please
05:21 mupuf: [ 676.871] (EE) [drm] KMS not enabled
05:21 Malinux: mupuf: ah, oki
05:21 mupuf: are you booting with the nomodeset option?
05:22 Malinux: not that I am aware of
05:22 mupuf: or maybe you have traces of the nvidia driver left?
05:22 Malinux: http://paste.ubuntu.com/10255734/
05:22 mupuf: lsmod
05:22 Malinux: full dmesg
05:22 Malinux: maybe. I could check lsmod
05:22 mupuf: the nouveau module is not loaded
05:22 mupuf: it may be blacklisted
05:22 Malinux: couldnt find properitary nvidia in lsmod
05:23 Malinux: anyway
05:23 Malinux: here it is
05:23 Malinux: http://paste.ubuntu.com/10255740/
05:23 Malinux: AHA
05:23 mupuf: Command line: BOOT_IMAGE=/boot/vmlinuz-3.13.0-45-generic root=UUID=c814c9ea-8492-48e3-b5e1-839076dcefc5 ro quiet splash nomodeset video=uvesafb:mode_option=1024x768-24,mtrr=3,scroll=ywrap --> I see a nomodeset here
05:23 Malinux: I tried to egrep nouveau in the modprobe.d directory, but couldn't find it, so belived it was not blacklisted
05:23 Malinux: aha, then I do have nomodeset enabled
05:24 mupuf: have a look at what is setting this parameter
05:24 buhman: O.o video=
05:24 Malinux: aha. I think I run this on the properitary driver to get a tty-terinal who looks good
05:24 Malinux: mupuf: I should remove the nomodeset and video=uvesafb-thing?
05:24 mupuf: yeah
05:24 mupuf: let nouveau handle everything
08:57 Malinux: mupuf: it worked to remove nomodeset :) thanx
09:17 Malinux: fy søren, denne maskinen var nice
09:17 Malinux: også var det bios med mest instillinger jeg har sett på noen laptop før :)
09:17 Malinux: og den store oppløsningen var litt uvant ja :)
09:17 Malinux: og det var bare å sette inn ssd og boote
09:17 Malinux: dvs. jeg gikk over til integrert grafikkmodus
09:18 Malinux: tenker å sjekke om jeg får installert drivere så den bytter til nvidiakortet om nødvendig
09:25 Tom^: lär dig ett riktigt språk istället, typ svenska.
09:39 rhn_mk1: joi: I noticed you've added some fglrx support, congrats
09:39 rhn_mk1: joi: if you remember, I used to have some problems with valgrind-mmt regarding missing memory accesses/ioctls
09:40 rhn_mk1: joi: fglrx seems to suffer from that, try comparing the HelloWorld example passed through mmt vs strace
09:49 joi: rhn_mk1: what should I trace? is glxinfo enough?
09:49 rhn_mk1: joi: actually, hold on... it might be a problem with my system
10:01 rhn_mk1: joi: I found some weird differences running the example "HelloWorld" from AMD APP SDK: http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/#
10:01 rhn_mk1: it's in samples/opencl/cl
10:04 mupuf: Malinux: great
10:10 Malinux: mupuf: yeah :)
10:13 rhn_mk1: looks like the order of calls and reads is just different
10:14 imirkin: iirc demmt doesn't print stuff quite when it happens
10:14 rhn_mk1: it makes sense if programs are multithreaded
10:16 imirkin: well it also looks for later events to make sense of earlier ones
10:45 joi: actually, I think write buffering is no longer needed and could be removed
11:11 joi: rhn_mk1: I see roughly the same number of ioctls
11:11 joi: so what's the problem?
11:11 joi: mmt: 448, strace: 463
11:12 rhn_mk1: joi: the problem was I didn't understand the output correctly, sorry about that
12:52 misteryJOE: yeah its basically yeah, when they want to defend all they need is guns and ammo, basically ukranians will need to be fed with guns, or if they loose the next target needs guns
13:00 misteryJOE: basically for us too if the article 5 does not work, then ammo and guns is needed
13:04 misteryJOE: it can be article 3 kamikaze is not needed, if its article 3 we need guns
13:18 misteryJOE: yeah surely, if ukranian military can not defend themselves, with guns they can, and if russians threatten with nukes, well they should be threattened back
13:23 misteryJOE: you know mofos i'm its what i am but this putin this one is crazy
13:24 misteryJOE: he wants to invade, and you know russians are being processed, this guy is crazy
13:33 misteryJOE: we can deal with russians without him, mofo initiates fights ill too those days around
13:34 misteryJOE: you know wrote a book how things ought to be
13:34 misteryJOE: another hitler what we gather
16:37 infinity0: ok i am going to try reclocking on fermi with that patched kernel
16:37 infinity0: brb, #yolo
21:54 AnotherLinuxUser: Hello, I have a question regarding enabling performance features in the nouveau driver.
21:57 AnotherLinuxUser: ... that is whether to put "nouveau.pstate=1" in my kernel command line.
21:57 imirkin: that feature enables the 'pstate' file which tells you the current clock setting
21:57 imirkin: and for certain card families, allows you to change the current clock setting
21:59 imirkin: (specifically on GKxxx, GT21x, and MCP7x)
21:59 AnotherLinuxUser: Ok... I will describe my set up in more details since I am uncertain whether is the way to go.
22:00 AnotherLinuxUser: I have a GeForce 7300 LE card (NV46) which is not in the families you listed, so the pstate does not seem to apply.
22:01 imirkin: ah, i didn't mention it
22:01 imirkin: but NV4x also has reclocking support :)
22:01 imirkin: i assumed nobody cared coz it was old
22:01 skeggsb: they also generally boot at near full speed anyway
22:02 AnotherLinuxUser: Oh... well, there is some hope.
22:02 AnotherLinuxUser: :)
22:03 AnotherLinuxUser: Anyway, I had just installed Fedora 21 on an AMD Athlon 64 bit cpu, which has this card and I have been having no end of grief trying to get nouveau working.
22:04 imirkin: remove libvdpau.so.* from your system
22:04 AnotherLinuxUser: Oh?... is that causing a problem.
22:05 imirkin: probably not yet
22:05 imirkin: but it will :)
22:05 imirkin: for reasons i've been too lazy to figure out, nv4x hangs *hard* when you try to use any vdpau on it, despite the fact that it doesn't actually advertise any hw decoding features
22:06 imirkin: for the same reasons of laziness, i haven't figured out how to disable vdpau on nv4x without breaking it for the rest of nouveau
22:08 AnotherLinuxUser: Is it sufficient to simply remove the actual libraries (or rename) or should I remove the packages?
22:09 imirkin: well, the _better_ way to go would be to remove the packages, but simply moving libvdpau_nouveau.so out of the way would be enough
22:10 imirkin: the grief that should cause is display hard hangs when trying to play back videos
22:10 imirkin: if you've been having different grief, it won't help with that
22:16 AnotherLinuxUser: Hmmm... well, the sequence of events are that I am able to get to the display manager graphical login screen (I simplified down to just the xdm, but it is applicable to gdm and lightdm) too... but as soon as I login to a gnome-session, there is a pause, mouse pointer vanishes, another pause, screen blanks to grey, mouse pointer reappears (if I move it) and then the screen hangs. I have been able to switch to an alternate
22:17 imirkin: try to avoid gnome-shell
22:18 imirkin: the nv30 gallium driver (which is used on nv4x as well) is sadly... lacking, to put it politely
22:18 AnotherLinuxUser: Ok, another thing to look at is to avoid the gnome-shell.
22:19 imirkin: if you can configure it not to do opengl-based compositing
22:19 imirkin: then you're probably good
22:20 AnotherLinuxUser: So if I simply disable the compositing... then I can retry without the libvdpau libraries?
22:20 mlankhorst: morning
22:20 mlankhorst: compositing's not the issue, but using opengl might be :P
22:21 imirkin: yeah, iirc there are other compositing options
22:21 imirkin: but using opengl to do so is likely not helping
22:22 mlankhorst: using xrender
22:22 AnotherLinuxUser: Ok... is there a way to simply disable opengl usage from compositing?
22:23 imirkin: as long as there are no follow-up questions, definitely yes :)
22:23 imirkin:uses WindowMaker
22:24 AnotherLinuxUser: Oh, am I asking too many questions? ;-)
22:26 imirkin: no, i just have no idea what the answer would be
22:27 imirkin: but based on the fact that i know that it's possible to use xrender for compositing, it would logically follow that there'd be a way to disable the opengl compositing stuff
22:28 airlied: gnome-shell doesn't use Xrender ever
22:29 imirkin: does it have the option not to use GL?
22:30 mlankhorst: I guess you could fall back to metacity?
22:30 imirkin: i've always gotten confused...
22:30 imirkin: metacity is a wm
22:30 imirkin: is gnome-shell a wm too?
22:31 tmpRAOF: Yup.
22:31 tmpRAOF: It's one of the shiny new WM-DE-Shelly things.
22:32 imirkin: so it's a single process that handles all of that at once?
22:32 mlankhorst: just like ubuntu with compiz? :P
22:32 imirkin: i.e. root window, window decorations, and compositing?
22:32 tmpRAOF: Yup. That's the way things go these days.
22:32 imirkin: so all that we need now is rename 'gnome-shell' to 'systemd', and we're good!
22:33 tmpRAOF: For bonus giggles, the wayland version is obviously the display server, too :)
22:33 imirkin: [couldn't resist]
22:33 mlankhorst: come on even fluxbox would do that if it had compositing :P
22:33 imirkin: some day i'll understand wtf compositing is
22:34 mlankhorst: composite extension = move windows offscreen and redirect input iirc
22:34 tmpRAOF: Alpha blending, mainly.
22:34 mlankhorst: it allows you to render screens in your own way
22:34 imirkin: so what's the output to the process with the composite extension?
22:34 imirkin: is it all the window pixmaps?
22:34 imirkin: or is it just the root pixmap?
22:34 mlankhorst: I guess it outputs to root or something
22:34 mlankhorst: or a non-composited window
22:35 imirkin: and is it the compositor's problem to get the thing displayed, or does it hand a pixmap back to the X server?
22:35 tmpRAOF: Either the Composite Overlay Window or the root window, yeah.
22:35 mlankhorst: imirkin: it depends, you can use OpenGL through texture-from-pixmap extension
22:35 mlankhorst: and then you just use flips
22:36 imirkin: hm ok
22:36 imirkin: i'll have to have a closer look at some point
22:37 mlankhorst: texture-from-pixmap works through dri2, you get a flink to the front buffer you could use..
22:38 imirkin: i wouldn't be terribly surprised if buffer sharing were b0rked on nv30
22:38 mlankhorst: I would be..
22:39 imirkin: AnotherLinuxUser: can you grab dmesg after you get the issues and put it up?
22:41 mlankhorst: buffer sharing is common to all of nouveau, how can it be messed up on a single card?
22:41 imirkin: mlankhorst: no gpu vm. and each driver has its own impl of resource_from_fd
22:42 imirkin: and depending on how that resource is created, it can trip up the driver. it makes various assumptions about the passed-in resource
22:43 AnotherLinuxUser: Ok, I will go to the affected machine and reboot.
22:47 AnotherLinuxUser: @imirkin: Ok... the affected machine is now hanging and I dumped 'dmesg' to a logfile... how would you like me to get it to you
22:47 imirkin: AnotherLinuxUser: pastebin or a competing service would be ideal
22:57 AnotherLinuxUser: Sorry, never used pastebin before... can I send the file via CLI through pastebin.com?
22:58 imirkin: some distros ship a 'pastebinit' tool
22:58 imirkin: some other ones may be friendlier to tools...
23:07 AnotherLinuxUser: @imirkin: ok, install pastebinit and did pastebinit -a AnotherLinuxUser -i dmesg.log
23:09 imirkin: it should have spat out a link
23:09 AnotherLinuxUser: I just got "http://fpaste.org/"
23:10 imirkin: uhm
23:11 imirkin: sounds like the tool stopped working or something
23:40 AnotherLinuxUser: Sorry for the delay @imirkin... I had to reboot into VESA mode and I have a url for you http://url.ca/jqsui
23:40 imirkin: The server can not find the requested page:
23:42 AnotherLinuxUser: Sorry... it must be http://ur1.ca/jqsui
23:43 imirkin: hrmph
23:43 imirkin: and this was taken after the graphics hang?
23:43 imirkin: skeggsb: btw -- note how it's not booting to the highest (and only) perf level
23:46 AnotherLinuxUser: @imirkin: Yes, after the login hangs, I switched to vt2, logged in as root, dumped dmesg into a logfile.
23:47 imirkin: AnotherLinuxUser: hmmmmmmmmmm.
23:47 imirkin: sorry, no great ideas offhand
23:48 imirkin: i assumed it was some sort of major fail
23:48 imirkin: which would have shown up in dmesg
23:48 imirkin: oh, so i threw in a bit of an easter egg into the latest nv30 driver...
23:48 imirkin: if you have mismatching color and depth formats
23:49 imirkin: then it will just not bind the depth buffer and move on
23:49 AnotherLinuxUser: Yes, so did I... the only things I saw are the warning about TMDS not stubbed and the error about DVI-I-1 encoder not found to turn it on.
23:49 imirkin: so if gnome-shell asks for such a lame configuration
23:49 imirkin: (e.g. rgba8 color buffer + 16-bit zs buffer)
23:50 imirkin: then it will have lots-a-fail
23:50 imirkin: (the previous situation wasn't substantially better -- hw errors and so on)
23:50 imirkin: whereas i "fixed the glitch"
23:51 AnotherLinuxUser: @imirkin: Well, I confined the 16 bpp manually, because I wanted to use the highest VESA mode possible for the frame buffer consoles.
23:52 imirkin: "confined"?
23:53 AnotherLinuxUser: @imirkin: in the kernel command line parameters and the xorg.conf.d config files I set a default color depth of 16 bits.
23:53 imirkin: you also get the same issue with rgb565 + z24 of course
23:54 imirkin: hmmm.... can you not do that and see if that "fixes" it? i doubt that's it, but who knows
23:55 AnotherLinuxUser: @imirkin: I will go to 24 bits and retest...
23:56 imirkin: do whatever the default is
23:56 imirkin: i.e. 32 bits i guess... i forget if selecting "24" in x is the same
23:57 imirkin: no semi-modern card supports a packed 24-bit format