01:30 CapsAdmin: imirkin, i downloaded the edid file from my monitor and corrected the crc manually (which i assume should have the same effect as ignoring it). i tried to upload it using edid-rw and it seems successful but when i download it again it's wrong
01:31 CapsAdmin: i gave up and ended up using a vga cable instead (so no 120 hz :( )
01:31 CapsAdmin: i also tried the kernel option as suggested but that didn't seem to do anything either
01:32 CapsAdmin: demsg says DVI-I-1 has a bad checksum so i did *kernel option thing*DVI-I-1:*path to edid bin*
01:36 CapsAdmin: found lots of people with the same issue on google. seems to happen over time with some monitors
01:37 pq: CapsAdmin, are you saying that the kernel commandline option doesn't work for you?
01:37 CapsAdmin: nvidias solution seems to be ignoring checksums and whatnot. even on windows it wasn't recognized properly
01:37 CapsAdmin: wasn't recognized properly by windows, but the nvidia control panel recognizes it*
01:37 CapsAdmin: pq, yeah
01:38 pq: CapsAdmin, are you perhaps using an initramfs?
01:38 CapsAdmin: a what?
01:38 pq: initrd
01:38 CapsAdmin: how do i know?
01:38 CapsAdmin: or check
01:38 pq: look in your /boot where your kernels are
01:39 pq: are there files with initsomething in their name?
01:39 CapsAdmin: initrd
01:39 CapsAdmin: is initramfs a bootloader? im using grub
01:39 pq: mm, looking at /proc/cmdline should tell more precisely
01:39 CapsAdmin: i had to modify a grub file to add the kernel option thing
01:40 CapsAdmin: /proc/cmdline doesn't exist
01:40 pq: eh?
01:40 pq: and fyi: https://en.wikipedia.org/wiki/Initrd
01:41 pq: anyway, if you use initrd, maybe the edid file is not included there, which means the display driver may not find it when it loads.
01:44 CapsAdmin: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash drm_kms_helper.edid_firmware=DVI-I-1:lib/firmware/edid/viewsonic.bin"
01:45 CapsAdmin: in etc/default/grub
01:46 CapsAdmin: hmm i'll look into it later
01:46 CapsAdmin: thanks
01:47 pq: CapsAdmin, if you have to mention of initrd or initramfs in your grub config, then I'm pretty sure you are not using initrd.
01:47 pq: *no mention
01:47 pq: which would mean: nevermind :-)
01:48 pq: CapsAdmin, hm, are you sure that path is right?
01:49 pq: CapsAdmin, do you have a /lib/firmware/lib/firmware/edid/viewsonic.bin ?
01:50 CapsAdmin: yeah i saved it there (for some reason)
01:50 pq: ok
01:51 CapsAdmin: maybe DVI-I-1 was wrong?
01:51 CapsAdmin: i just copied it from the error messages about the EDID being wrong
01:51 CapsAdmin: maybe it's a lowercase L lol
01:51 pq: it doesn't immediately strike as wrong...
01:52 pq: if you got it from kernel logs, it should be right, I think
01:52 pq: X.org logs probably use a different naming
01:52 CapsAdmin: yeah i think xorg doesn't have the - symbol (forgot its name)
01:53 CapsAdmin: but since this is kernel i assume i should follow the kernel names
01:54 CapsAdmin: i'd rather just be able to flash the edid but that didn't seem to work. i could read and apparently i could write (there wasn't any errors) but it didn't seem to update
01:54 CapsAdmin: maybe i need to take it apart and do it or something
02:15 imirkin: CapsAdmin: iirc it was DP-3 that was failing for you
02:16 imirkin: CapsAdmin: also make sure that viewsonic.bin is available at the time that nouveau is loaded
02:16 pecisk: btw, opencl is shown as stalled on lot of generations - any ideas when work could be resumed?
02:16 imirkin: so if it's loaded from initrd, then it must be in the initrd
02:16 imirkin: pecisk: whenever someone resumes it, of course
02:17 pecisk: ahh lack of hackers
02:17 pmoreau: In a few years maybe given how fast I'm. :/
02:18 imirkin: i'm secretly hoping opencl will become irrelevant in the presence of ARB_compute_shader
02:18 pecisk: imirkin, you are hoping right
02:18 pecisk: but still lot of ports will use OpenCL
02:19 pecisk: what I have heard
02:19 pecisk: also - Mac
02:22 karolherbst: imirkin: why is that?
02:22 pecisk: pmoreau, how complex that code is?
02:22 karolherbst: I thought compute_shader and OpenCL have totoally different goals
02:23 pmoreau: pecisk: I'm trying to convert SPIR-V to NV50 IR, in order to take OpenCL/Cuda kernels in SPIR-V format and run them on Nouveau.
02:23 karolherbst: also computer_shader is single device only as far as I know
02:24 pmoreau: pecisk: But I have little knowledge of compilers, and it's my first use of nouveau_compiler, so it's taking time. :-)
02:24 imirkin: not sure what that's got to do with it
02:24 pecisk: isn't compute shaders MT though?
02:24 imirkin: MT?
02:25 karolherbst: imirkin: compute_shader was designed especially for GPUs and how OpenGL is used, that doesn't fit the needs you usually use OpenCL for
02:25 imirkin: karolherbst: how so? what's the difference?
02:25 karolherbst: also you don't want to implement OpenGL on CPUs, DSPs, FPGAs and so on
02:26 karolherbst: and OpenCL is mutli device by design
02:26 karolherbst: you can compute the same thing on multiple different devices at the same time with no hazzle
02:27 karolherbst: its also stated in the ARB_compute_shader spec why it does not and doesn't want to replace OpenCL
02:27 imirkin: so what i'm hearing is... if you plan on using opencl on a gpu, ARB_compute_shader is a great replacement
02:27 CapsAdmin: is there something like a PPA for mesa?
02:28 pecisk: judging by people doing ports to Mac and Linux OpenCL can be used as alternative for compute shaders..
02:28 karolherbst: imirkin: if you want to use it with OpenGL
02:28 karolherbst: outside OpenGL compute_shader makes no sense
02:28 imirkin: karolherbst: how so?
02:28 karolherbst: because you need a OpenGL context for compute_shader?
02:28 imirkin: karolherbst: does it make any more sense than, say, OpenCL?
02:28 imirkin: well you need *something* right?
02:28 imirkin: is an opengl context somehow worse than an opencl context?
02:29 karolherbst: its more specific
02:29 imirkin: so... just as good :)
02:29 karolherbst: not for every task
02:29 karolherbst: the thing is, with compute_shader you can't simply connect 50 different GPUs
02:30 karolherbst: and let them do the same thing
02:30 imirkin: how would you do such a thing with opencl?
02:30 pecisk: back to topic - OpenCL is used as alternative for shaders for many Macs ports due of OS X stuck with 4.1...so it might be that OpenCL is required for games more than we think so
02:30 karolherbst: imirkin: you don't care about that in opencl
02:30 karolherbst: you can use different OpenCL implementations at the same time within your application without the need to do anything about that
02:31 imirkin: why would you want that?
02:31 imirkin: also majority use-case is a single computation device like a gpu
02:31 karolherbst: because you have different devices
02:31 karolherbst: yeah, but I talk about the use cases where compute_shader can't replace OpenCL
02:31 imirkin: i'm sure they exist
02:31 imirkin: just as i'm sure there are use-cases that aren't well served by opencl
02:32 karolherbst: maybe on "normal" consumer devices it may become irrelevent
02:32 imirkin: pecisk: well, until someone puts work into it, it won't happen
02:32 karolherbst: but I am not sure how easy it is to use compute_shader in a non OpenGL application
02:32 pecisk: imirkin, I understand that
02:32 imirkin: pecisk: nouveau is *wildly* understaffed, so... not anytime soon without a serious infusion of talent
02:33 karolherbst: pecisk: which game does use OpenCL?
02:33 pecisk: karolherbst, afaik Feral and other porters use it a lot
02:33 karolherbst: they seem to like pain
02:34 pecisk: karolherbst, or Apple loves to torture them
02:34 pecisk: :)
02:35 karolherbst: yeah well, there are a handfull games needing more than GL 3.3
02:35 karolherbst: maybe because of Apple, maybe not
02:35 karolherbst: but I don't think OpenCL is the alternative you should use, when you are stuck with 4.1
02:36 karolherbst: its nice when you got two gpus though
02:37 karolherbst: because the you could use the weaker gpu for opencl and do the gl stuff on the stronger one
02:37 karolherbst: but besides that? I don't think there are any valid use cases
02:39 karolherbst: physx is already a pain on windows, because you can't just use it at max setting if you only have one gpu, because the gpu get overwhelmed by the tasks it has to do (maybe not for the really strong ones)
02:39 pecisk: karolherbst, they have two choices - do OpenGL with OpenCL or go Metal which also lacks things but have compute shaders
02:39 karolherbst: and then you get strange stutters, because the GL/DX part is already done, but the cuda stuff not
02:40 pecisk: karolherbst, phusx has profile for running on CPU too no?
02:40 pecisk: physx
02:40 karolherbst: on low
02:40 karolherbst: yes
02:40 karolherbst: but medium+ is gpu only
02:40 karolherbst: and "high" is only suggested if you have two gpus
02:41 pecisk: I see
02:42 karolherbst: but at least there is now a gpu based implementation for physx on linux now
02:43 karolherbst: don't know how the mac os x situation is tbh
02:50 pecisk: at least last few ports I have heard of have aimed for OGL 4.3 so it doesn't aim for Mac/Linux combo anymore, and most likely uses compute_shaders
02:51 pecisk: anyway, I wanted to say guys thank you for all hard work...I am just a user and people always will want more, but having Nvidia open source driver which is actually usable for many cases is awesome
02:54 imirkin: pecisk: feel free to point out any bugs you see... chances are no one else will :)
02:57 karolherbst: anyway, I could imagine that OpenCL on kepler+ is easier to implement than on older chips
04:13 laust: Hi, I am experiencing several issues, and not sure how to diagnose. I have saved some logs, and things seem to go wrong at "systemd-coredump[XXX]: Process YYY (Xorg) of user 1000 dumped core. I have a backtrace in another log, that ends on a segmentation fault. Should I file a bug, or have I missed something obvious?
04:18 pmoreau: laust: Could you paste the output of dmesg and the backtrace somewhere, please?
04:26 laust: pmoreau, not really dmesg, but I got something out of journalctl, and something out of Xorg.0.log. Here they are: http://paste2.org/Z78CWC7U and http://paste2.org/fJg88ABb
04:27 laust: I forgot to mention it's a Geforce GTX750Ti - Chipset: GM107 (NV117)
04:29 pmoreau: laust: So the function failing is OsLookupColor, which could be related to this message in journalctl I guess? "/usr/lib/colord/colord-sane: error while loading shared libraries: libsane.so.1: cannot open shared object file: No such file or directory"
04:29 laust: Some other symptoms are that some characters usually don't show (example: "fo" and "fr" in emacs menus and in icecat - it's been like that for a while now), and I can't start plasma5
04:30 laust: pmoreau, I don't know, but I can try disabling whatever wants to load it
04:30 pmoreau: As for characters disappearing, see https://bugs.freedesktop.org/show_bug.cgi?id=90932
04:31 pmoreau: You could as well try to install the missing library. :-)
04:34 laust: pmoreau, thanks for the bug, I'll try that. And right, I might as well add the missing library, removing what calls it is a good way to break something else.
04:35 pmoreau: :)
04:39 laust: should be ok now, I'll give it a try, be back later
05:13 laust: pmoreau, installing sane indeed makes the messages about libsane disappear. Changing the driver to modesetting enables starting plasma5. But I lose dual screen. Is that normal? I've tried different settings, but probably not all.
05:25 pmoreau: laust: Hum... I don't see why you would lose dual screen using modesetting, but I don't know much about modesetting either.
05:26 pmoreau: For the different settings, you tried using plasma5 config settings or xrandr?
05:30 laust: pmoreau, I basically only changed Driver = "nouveau" into Driver = "modesetting" in Section "Device" in 20-nouveau.conf. Then monitors are clones while with nouveau they're automatically different. I'll try changing with xrandr.
05:32 pq: laust, most likely "modesetting" uses different output names from "nouveau", which means your config needs adjusting.
05:33 laust: pq, how can I not have thought about that... checking right now, thanks
05:34 pq: because it's very surprising? :-p
05:44 laust: pmoreau, pq: indeed modesettings starts numbering at 0 while nouveau starts at 1 :-)
05:44 pmoreau: Eh eh!
05:44 pmoreau: So, dual screen is working back?
05:44 laust: yes!
05:45 laust: I should have thought of that myself
05:46 laust: It didn't fix my missing characters issue, so I'm still playing hangman. Not a big deal :-)
05:46 pmoreau: :D
05:46 laust: Thanks for the help with the other issue!
05:49 pmoreau: laust: You should subscribe to the bug report to get updates if it gets solved / are some patches to test.
05:49 tobijk: mh we should unify the naming then...
05:49 tobijk: or is the nvidia driver starting at 1 as well? :/
05:50 pmoreau: I don't remember... I would have said 0.
05:51 laust: pmoreau: good idea
05:52 laust: tobijk: I have no idea, haven't used the proprietary driver for a long while
05:53 tobijk: :)
06:00 laust: i'd rather use a less functional free driver than a is-it-really-fully-functional proprietary driver :-)
06:03 tobijk: laust: are you sure you dont have a ghost output around? :D
06:06 laust: tobijk: ghost output? :-)
06:07 tobijk: xrandr should show :D
06:07 laust: tobijk: that captures "fo" and "fr" specifically?
06:08 laust: tobijk: I have 2 other outputs (VGA and HDMI) but xrandr says they are disconnected
06:08 laust: which they are
06:08 tobijk: ok:)
06:09 pq: tobijk, the problem with changing output naming conventions in an old driver is that it will actively break user setups.
06:10 tobijk: right, still i think we should have a consistent scheme across the xf86* drivers
06:11 pq: my bet is every single one will say "we don't want to break existing setups"
06:11 pq: it would've been nice, but too late
06:13 pq: however, in cases where the existing naming scheme is already broken... cases where different outputs accidentally get identical names
06:13 pq: weston was recently patched, and there is a patch on the xorg-devel list to change "modesetting"
06:14 tobijk: mhm
06:14 pq: though if modesetting already gives DVI-D-# instead of DVI-#, then the patch has landed.
06:16 pq: weston and I think Enlightement/Wayland follow the kernel naming scheme to the letter, modesetting (old or new) deviate, and the rest of X.org drivers I don't know what scheme they use.
06:17 laust: pq: modesetting gave DVI-# here,
06:17 tobijk: laust: i guess it will be in xserver 1.18
06:18 laust: tobijk: I better keep that in mind then :-)
06:19 pq: the patch hasn't been acked as landed yet, so maybe it's not evne in git yet
06:20 tobijk: i just had a quick look there and havent found it
08:06 karolherbst: pecisk: around?
08:12 pecisk: karolherbst, yes, but not at my testing machine yet
08:12 pecisk: but you can tell me what you want me to do, I will do later
08:15 karolherbst: use the karlton_test branch and recompile
08:15 karolherbst: then you should have under /sys/kernel/debug/drm/0/ the pstate and a cstate file
08:15 karolherbst: go to 0f pstate
08:16 karolherbst: and echo values from 30 up to the highest entry inside cstate into cstate
08:16 karolherbst: and check from which entry the core clock doesn*t increase
08:16 karolherbst: or from which one you get the voltage error
08:16 karolherbst: I think every entry except the last one should work, but I am not sure about that
08:18 karolherbst: pecisk: the content of the cstate file should look like this: https://gist.github.com/karolherbst/6fad9921b21eb739be27
08:18 karolherbst: just with different entries
08:24 pecisk: ok, will do that later
08:26 karolherbst: thanks
08:34 karolherbst: if somebody could confirm those, that would be nice
08:43 pecisk: bb
08:47 Sleaker: hey seeing some wierd stuff with an NV46, it seemed to be working a couple days ago with Xorg, but dmesg now just dumps a bunch of DATA_ERROR PROTECTION_ERROR nstatus INVALID_STATE BAD ARGUMENT and then CACHE_ERROR - ch 0 [DRM] subc 0 mthd 0x000 data 0x8000000a messages
08:48 Sleaker: can't really find anything online for this. I'm on Ubuntu 14.04
08:48 Sleaker: dmesg then shows a 'GPU lockup - switching to software fbcon' and Xorg on the main display stops working.
08:48 karolherbst: Sleaker: did you or something else change anything?
08:48 karolherbst: like updates or anything
08:48 Sleaker: nope
08:49 Sleaker: we don't release driver/kernel updates yet
08:50 Sleaker: and after the lockup it just starts spamming dmesg with the 'failed to idle channel 0xcccc0000 messages
09:00 Sleaker: any thoughts karolherbst?
09:06 Sleaker: here's the call trace: http://pastebin.com/FDwaa7LB
09:17 karolherbst: ohh looks like a dead lock
09:18 karolherbst: or infinite wait for something
09:19 karolherbst: I think "push 0 buffer not in list" is the more important bit though
09:19 karolherbst: don't know that much about internals sadly, so I can't help here that much
09:20 Sleaker: I'm leaning toward hardware issue
09:29 Sleaker: that system hasn't had anything new installed on it for over a month and has been in use atleast 10 hours a day.
09:29 Sleaker: rebooted last night and then had that problem
09:29 karolherbst: could be bad luck though
09:34 karolherbst: Sleaker: do you get the issue several times or did you get it only once?
09:35 strawbs: hi. maxwell is badly supported, right? i cant get xv video output anymore, apparently there's no suitable X11 driver, some legacy thing got removed. and i cant get to desktop unless i use modesetting driver (xorg that is).
09:35 strawbs: anything i can do to at least use something other than software rendering for video?
09:36 strawbs: and proprietary is not an option
09:36 karolherbst: strawbs: modesetting driver
09:36 strawbs: which i would hope im using, since im on desktop...shouldnt that be part of my kernel?
09:36 karolherbst: there is a modesetting X driver, which can use glamor for hardware acceleration
09:36 strawbs: yea i tried glamor. i get an xorg error too
09:37 karolherbst: mhhh
09:37 karolherbst: then this is your real issue :)
09:37 strawbs: if this is a driver separate from linux kernel i probably dont have it installed
09:37 karolherbst: should be fine depending on the error that is
09:37 strawbs: ok
09:37 strawbs: it might also be my xorg which wasnt built with glamor maybe
09:37 karolherbst: do you have the error?
09:37 strawbs: 1 sec
09:38 imirkin: strawbs: what GPU do you have?
09:38 strawbs: its fine until: EGL_MESA_drm_image required. fails there
09:38 strawbs: imirkin: 980
09:39 imirkin: strawbs: no acceleration with nouveau possible, sorry
09:39 strawbs: imirkin: yea i read the note
09:39 karolherbst: strawbs: distribution?
09:39 strawbs: karolherbst: debian
09:39 imirkin: modesetting should provide you with (software) xv though
09:39 imirkin: maybe not though? not sure.
09:40 strawbs: imirkin: yea it used to, until some legacy thing got removed, and glamor never worked for me either so now i'm in a bad spot
09:40 karolherbst: strawbs: what exactly got removed?
09:41 imirkin: strawbs: well, the nouveau ddx would never have loaded for you
09:41 strawbs: karolherbst: i only read that mpv was using some legacy x11 driver, now its gone
09:41 imirkin: hmmmm.... does modesetting not support xshm or something?
09:42 karolherbst: sounds like xv
09:42 imirkin: strawbs: in any case, what changed exactly? are you saying that the nouveau ddx used to load for you?
09:42 strawbs: imirkin: nah
09:42 strawbs: give me a minute
09:43 strawbs: https://github.com/mpv-player/mpv/issues/2270
09:43 strawbs: i figured it was an mpv/whatever issue, but here is probably the best place to ask how i can avoid the issue
09:43 strawbs: karolherbst: can i build myself a glamor drm from source?
09:43 Sleaker: tanks karolherbst going to advise them to try a different gfx card.
09:44 Sleaker: thanks*
09:44 karolherbst: strawbs: this sounds like a system issue
09:44 imirkin: "That’s because mpv was falling back to the legacy X11 video output, which has been removed."
09:44 imirkin: it's a change the mpv that broke things for you, not nouveau
09:45 strawbs: imirkin: yea i understand
09:45 imirkin: -vo sdl should work fine though
09:45 Yoshimo: is https://www.phoronix.com/scan.php?page=news_item&px=Nouveau-Volt-GM107-Too something that one can help with remotely if in possesion of a 9xx card?
09:45 imirkin: Yoshimo: dunno... mupuf?
09:45 strawbs: karolherbst: so, i dont know anything about glamor. should this be part of xorg?
09:46 karolherbst: strawbs: doesn't matter for your card
09:46 strawbs: imirkin: yes, it does, but it's terrible, i get awful screen tearing
09:46 strawbs: karolherbst: oh, so i cant use glamor either?
09:46 imirkin: strawbs: it is. but glamor relies on having an opengl backend.
09:46 strawbs: ah right, ok
09:46 karolherbst: mhhh
09:46 strawbs: so i'm fucked
09:46 strawbs: :)
09:46 karolherbst: tearing prevention without proper driver support is kind of "messy"
09:46 karolherbst: which desktop environment are you using?
09:46 imirkin: pretty much yeah
09:46 imirkin: or you can use mplayer
09:46 imirkin: which works.
09:47 imirkin: unlike every other player, which in one form or another, doesn't work
09:47 strawbs: karolherbst: none, just a WM + compton
09:47 strawbs: imirkin: fair enough
09:47 karolherbst: usually the window compositor can take care about tearing prevention, but I doubt that will work on your setupt though :/
09:48 strawbs: yea. i'll try a few things, if it doesnt work i'll switch players i guess
09:48 strawbs: thanks
09:48 karolherbst: Yoshimo: yes, ping mupuf if you want to help :D
09:48 strawbs: so is maxwell support impossible via nouveau? because of some binary blob right?
09:49 Yoshimo: karolherbst: his nick indicates absence at the moment, but i'll try
09:49 karolherbst: mhhh not maxwell in general, but GM2xx
09:49 imirkin: strawbs: not impossible in theory. but in practice, GM20x is unsupported.
09:49 karolherbst: GM108 and GM107 should work?
09:49 strawbs: i see
09:49 imirkin: yeah, they kinda-sorta work, with a bunch of issues.
09:49 imirkin: i haven't really invested the time into fixing them because... lack of caring
09:49 imirkin: and/or time
09:50 strawbs: i had a decent setup with my previous card. but it broke and i got the logical equivalent
09:50 karolherbst: you should have bought a kepler instead :p
09:51 strawbs: twas the one that broke
09:51 strawbs: :p
09:51 karolherbst: then a nwe kepler
09:51 karolherbst: :D
09:51 strawbs: heh
09:51 imirkin: it's too late now, but for the best open source support, go with amd (or intel if it matches your needs)
09:51 karolherbst: but depends on what kind of kepler it was
09:51 strawbs: imirkin: i thought amd open source was terrible
09:51 karolherbst: *blob
09:51 imirkin: strawbs: it's all in the eye of the beholder...
09:52 imirkin: it's certainly not *perfect*
09:52 strawbs: i know one had a bad blob but great open source. i thought it were nvidia, maybe i got it mixed up
09:52 imirkin: but it has an actual team of paid individuals supporting it
09:52 strawbs: i see
09:52 karolherbst: strawbs: yes you got it mixed up
09:52 strawbs: ah fair enough
09:52 karolherbst: nvidia has pretty decent driver quality though
09:53 karolherbst: so if you don't care about free software, I think nvidia is still the better choice
09:53 karolherbst: allthough if you don't play games, then intel would be best
09:54 karolherbst: since haswell the intel gpus are pretty decent too
09:54 strawbs: mh
09:54 Yoshimo: sure is, hands down, butin case you want to go rogue and try some crazy things like gallium nine you have a problem with the original nvidia driver karol
09:54 karolherbst: strawbs: what kind of cpu do you have?
09:54 strawbs: karolherbst: ivy bridge-e, it has no igp
09:54 karolherbst: Yoshimo: well... witht he current state of gallium nine, I rather use the blob
09:55 Yoshimo: yea but helping ain't possible without nouveau and a decent framerate
09:55 karolherbst: I know
09:55 strawbs: i might return this card and get an amd equiv then
09:56 karolherbst: strawbs: or kepler ;)
09:56 karolherbst: or a new cpu
09:56 karolherbst: depend on if you really need a dedicated gpu
09:56 strawbs: well, kepler is a bit slow, i still play games on a separate install
09:56 karolherbst: I see
09:56 karolherbst: why is kepler slow?
09:56 strawbs: rarely but it does happen
09:56 strawbs: depends on the game. 780 didnt do well for me in witcher 3
09:57 karolherbst: yeah witcher 3...
09:57 karolherbst: resolution?
09:57 strawbs: then the vram started dying so it went
09:57 strawbs: 1440
09:57 karolherbst: yeah well...
09:58 karolherbst: most of the gpus won't do much usefull on 1440
09:58 imirkin: strawbs: do note that the very latest amd chips (fiji & co) aren't extremely well supported either. however that situation is very likely to improve in the near future.
09:58 imirkin: unlike the nvidia situation, which isn't likely to improve.
09:58 strawbs: karolherbst: true
09:58 strawbs: imirkin: yea, ok
09:59 strawbs: alright, thanks for the help guys
09:59 strawbs: :) bye
10:01 karolherbst: imirkin: so what if anything newer than GM20x won't work anymore?
10:02 imirkin: perhaps it'll give me some time to implement ARB_vertex_program support on nv20 :)
10:02 imirkin: and NV_texture_shader? i forget.
10:03 karolherbst: :D
10:33 Rarruga: Hi all
10:33 Rarruga: I have a question
10:34 Rarruga: I have two cards, a relatively new one and an old one, and I have three monitors
10:34 Rarruga: When I start Dota2 Reborn, it writes me to log:
10:34 Rarruga: DumpContextInfo: OpenGL vendor VMware, Inc.
10:35 Rarruga: DumpContextInfo: OpenGL renderer Gallium 0.4 on llvmpipe (LLVM 3.5, 256 bits)
10:35 imirkin: Rarruga: care to share which cards you have?
10:35 Rarruga: DumpContextInfo: Using OpenGL context version 3.3
10:35 Rarruga: second
10:36 Rarruga: EVGA GeForce GTX 580 FTW Hydro Copper 2
10:36 Rarruga: this is the first
10:36 imirkin: that's a GF110 right?
10:36 tobijk: Rarruga: you are using the software backend when it states llvmpipe, you are missing something...can you share dmesg and xorg log?
10:37 tobijk: (after putting out your second card)
10:37 Rarruga: second
10:37 Rarruga: the second one is an old card Quadro ... something
10:37 Rarruga: it is used only for one monitor
10:37 tobijk: Rarruga: you can use lspci to list them
10:38 Rarruga: ah, exactly: Quadro FX 560
10:38 Rarruga: so, dmesg, what should I see there?
10:39 tobijk: hopefully noueau loading and putting out some infos
10:39 Rarruga: do not want to spam here :)
10:39 tobijk: put it on pastebin or such service
10:39 Rarruga: sec
10:40 imirkin: ooh, GF110 + NV4B -- quite the anachronistic system
10:41 Rarruga: http://pastebin.com/2yaKn26d
10:41 imirkin: er, G73 i guess
10:41 tobijk: lets see
10:41 Rarruga: y, but I do not have other option to use three monitors.
10:42 imirkin: i know you're trying to help, but in the future, don't grep stuff out of the logs...
10:42 imirkin: also, please provide xorg log
10:42 Rarruga: ok, trying my best. Should I post also complete dmesg?
10:43 tobijk: please
10:43 imirkin: meh, i'll let you know based on xorg log
10:43 imirkin: i suspect there's something wrong in there
10:43 imirkin: like a leftover from blob install or something
10:43 tobijk: nvidia glx.so? likely
10:43 imirkin: that's my guess :)
10:45 Rarruga: http://pastebin.com/ickpu4fZ
10:45 Rarruga: Xorg.0.log here
10:45 Rarruga: I had Nvidia driver
10:45 Rarruga: before
10:45 Rarruga: and uninstalled it
10:46 Rarruga: it think :)
10:46 Rarruga: i think
10:47 Rarruga: I have also not really standard xorg.conf
10:47 Rarruga: from nvidia times
10:49 tobijk: looks ok on a first glance
10:49 Rarruga: hm
10:49 Rarruga: the system works fine
10:49 Rarruga: all monitors
10:49 Rarruga: but the game is slow like hell
10:49 tobijk: because it uses the cpu for the graphics
10:50 Rarruga: So I suspected it is started on the old card
10:50 Rarruga: Ah, ok
10:50 Rarruga: understand
10:50 tobijk: maybe steam does some fallback to it because the old card cant handle the needed gl version, dunno
10:51 Rarruga: I can force to start the game on different screens but this does not help
10:51 tobijk: can you run glxinfo for once
10:52 Rarruga: http://pastebin.com/ZXRFQG2s
10:52 tobijk: llvmpipe as well :/
10:53 Rarruga: should I post xorg.conf ?
10:55 tobijk: mh you can do that, but i dont think thats the problem...
10:58 Rarruga: http://pastebin.com/AKdKpZce
10:58 Rarruga: it has been created for Nvidia driver
10:58 Rarruga: but I just replaced Driver keyword
10:59 Rarruga: to use nouveau
11:01 tobijk: mh xinerama, i have somewhere in my mind that with it you cant have acceleration
11:01 tobijk: imirkin: -^ ?
11:02 Rarruga: this would be a pity
11:03 tobijk: a more modern way would to config it with xrandr
11:04 Rarruga: Looks like you are right: "Because the X server is single-threaded, rendering takes more time by the number of cards. The rendering speed in a Xinerama configuration is practically always worse than what the slowest card is able to achieve alone. Furthermore, Xinerama does not handle GLX, so 3D acceleration is disabled."
11:05 Rarruga: This is from http://nouveau.freedesktop.org/wiki/MultiMonitorDesktop/
11:05 tobijk: ah you found it :)
11:05 tobijk: use xrandr
11:05 Rarruga: But Nvidia drivers were fine
11:05 Rarruga: so I thought ...
11:05 Rarruga: Ok, thnaks you!
11:05 tobijk: they may have vendor specific implementations which enables xinerama to have 3d accel
11:06 Rarruga: thank you
11:06 tobijk: np
11:06 tobijk: you may stay and ask if something goes wrong though :)
11:06 Rarruga: I have to go. But be sure, will break my system and come to the channel soon. :)
11:21 imirkin: tobijk: fyi, xinerama = no accel
11:30 Wonka: I wish there was display hotplugging...
11:31 imirkin: there is...
11:31 imirkin: or you mean with xinerama?
11:31 imirkin: the whole design of xinerama is a static config
11:31 tobijk: i use hotplugging frequently
11:31 imirkin: xrandr is the dynamic thing
11:31 Wonka: nope, xrandr
11:31 tobijk: there is
11:31 Wonka: yeah, i want to hotplug a display on an usb gpu
11:32 imirkin: displaylink?
11:32 Wonka: yep
11:32 imirkin: UDL2 should be supported
11:32 imirkin: UDL3, however does some lame-ass encryption thing
11:32 imirkin: they have a userspace blob to enable it afaik
11:33 mjg59: imirkin: It's supported, but if you plug it in when you're already in an X session you can't extend that session to it
11:33 Wonka: last time I tried, I had to start an extra Xservee for udl2
11:33 Wonka: what mjg59 says
11:33 imirkin: mjg59: errrrr... why not?
11:34 imirkin: xorg should get a new device notification via udev
11:34 imirkin: and modesetting should be able to drive it as a GPU
11:34 imirkin: and then you just do output offloading, and you're done
11:39 mjg59: imirkin: Oh? Last time I played with this xrandr didn't have any support for gaining new displays at runtime
11:40 mjg59: Er s/displays/outputs/
11:43 imirkin: mjg59: "reverse prime" it's called
11:43 imirkin: render on main gpu, but display on secondary gpu
11:43 imirkin: which is an especially good idea when the secondary gpu is udl ;)
11:44 imirkin: reverse prime has been around since at least xorg 1.14 or so
11:45 imirkin: although perhaps the modesetting driver didn't support it, dunno
11:45 imirkin: pretty sure it does now though
11:49 mjg59: imirkin: Right, I know that, but I didn't think it supported new GPUs being added after X had started
12:00 broucari: Hi any news of #90976
12:11 pecisk: karolherbst: so I did what you asked. Stops at 50 as AC: core 1201 MHz memory 6007 MHz
12:12 pecisk: 50 out of 52
12:13 pecisk: stops at 51 to be correct
12:14 karolherbst: so 51 works?
12:14 karolherbst: or not
12:14 pecisk: 51 is where it fails
12:14 karolherbst: mhh okay, does it print the voltage in dmesg for 50?
12:14 pecisk: where I get failed to raise voltage
12:15 pecisk: karolherbst: yes
12:15 pecisk: karolherbst: sep 14 22:06:44 localhost.localdomain kernel: nouveau 0000:01:00.0: clk: set gpu to cstate: {gpc: 2404000, mem: 3004000, voltage: 64}
12:15 karolherbst: which one is getting set for 50?
12:15 karolherbst: I meant the uv value
12:15 karolherbst: could be that nouveau.debug=debug is required for that
12:16 pecisk: karolherbst: volt: set 1200000uv: 0
12:16 karolherbst: mhhh
12:17 karolherbst: this is wrong somehow
12:17 karolherbst: should be 1187500uv
12:17 pecisk: very strange
12:17 karolherbst: which voltage is getting set for 45?
12:20 pecisk: 1125000uv
12:20 pecisk: 1187500uv gets set for 49
12:20 karolherbst: okay, I have to check something
12:21 karolherbst: which one for 36?
12:21 pecisk: karolherbst: 1025000uv
12:22 karolherbst: mhhh
12:22 karolherbst: for 7?
12:23 karolherbst: should be 850000uv
12:24 pecisk: karolherbst: 37?
12:24 karolherbst: no, 7
12:25 pecisk: karolherbst: 862500uv
12:25 karolherbst: mhh okay
12:25 karolherbst: it's like always 12500uv too hight :/
12:25 karolherbst: *high
12:26 karolherbst: for 51 and 52 it may try to set it too high then
12:26 karolherbst: not sure though
12:27 pecisk: it feels that way, core clock max out at 1201
12:27 karolherbst: yeah
12:27 karolherbst: mhhh
12:28 karolherbst: there are others with the same or a similiar issue as well
12:28 karolherbst: so I think this should be fixed soon
12:28 karolherbst: don't really know if I can do that much about that, because voltage is handled a bit differently for me
12:32 pecisk: karolherbst: will you be able to make sure modes max out core clock when they can? :)
12:32 pecisk: t.i. for 0f/0e
12:34 karolherbst: its already done
12:34 karolherbst: in your case voltaging just fails so the clock won't change
12:34 pecisk: it's fixable right?
12:34 karolherbst: because with stock nouveau the pstate always sets to the highest cstate
12:34 karolherbst: it sure is
12:34 karolherbst: but the two highest cstates for you have some problems
12:35 karolherbst: so
12:35 karolherbst: but you can switch to 0f and 50 cstate and do some perf tests ;)
12:35 pecisk: heck sure I can :)
12:35 karolherbst: should be a huge difference compared to 07
12:35 karolherbst: and with huge I mean boost like 400%
12:36 pecisk: I need some good free good looking OpenGL app/game for this
12:36 karolherbst: 3x core clock and x5 mem clock should make a difference :D
12:37 karolherbst: ohh wait, compared to 0a the difference might be much smaller
12:37 karolherbst: mhh
13:21 mrnuke_i_: imirkin_: Not yet angry that things don't work, but I'm supposed to get that maxwell card today. Fingers crossed
13:22 imirkin_: the anger will follow shortly, don't worry
13:26 airlied: mjg59: we've supported it for at least 2 years :-P
13:27 airlied: though can't really handle actual GPUs, just USB ones
13:27 airlied: someday maybe I'll care enough to hotplug a real GPU mess
13:29 mjg59: airlied: \o/
13:29 karolherbst: I think I will write some patches with the only purpose to add some debugging/error messages
13:29 karolherbst: debugging these voltage issues without any messages is insane
13:30 mrnuke_i_: imirkin_: I still have a few hours before I get home. I'm giving you plenty of time to run and hide
13:44 imirkin_: airlied: btw, i didn't double-check this, but modesetting how has all the various features mario was asking for right?
13:44 imirkin_: s/how/now/
13:45 airlied: imirkin_: yes
13:45 imirkin_: starting with the (to-be-released) xorg 1.18?
13:47 airlied: imirkin_: yes
13:47 imirkin_: cool thanks
14:33 pecisk: imirkin_: for some reason Unreal Tournament 4 alpha lacks textures underl nouveau. Any ideas?
14:33 imirkin_: install libtxc_dxtn
14:34 imirkin_: otherwise you don't get s3tc textures
14:34 pecisk: duh
14:34 pecisk: right
14:34 pecisk: damn patents
14:48 imirkin_: pecisk: did installing libtxc_dxtn fix it?
14:49 imirkin_: there can be other reasons for texturing fail of course, but that's the most common one
14:51 pecisk: imirkin_: it did
14:52 imirkin_: ok cool
14:52 pecisk: ok, first time I heard air ventilation working for Nouveau driver
14:52 pecisk: it sure looks very impressive, fps jumps from 60 fps to 40 fps
14:52 pecisk: with all high (not epic)
14:53 imirkin_: that sounds playable
14:57 pecisk: it certainly is
14:57 pecisk: it looks very nice, and with high settings it's still goes on like tank...thumbs up man, thumbs up
15:02 imirkin_: cool :)
15:02 imirkin_: i guess nouveau is good for something then
15:05 pecisk: it clearly is now :)
15:07 imirkin_: pecisk: i forget if we showed you how to increase the PCIe link speed... if not, that might provide some small gains for some games
15:09 pecisk: no, you didn't
15:09 imirkin_: pecisk: pastebin 'lspci -vvn -d 10de:'
15:09 imirkin_: er
15:09 imirkin_: -vvnn
15:10 pecisk: imirkin_: just VGA adapter?
15:10 imirkin_: ya
15:12 pecisk: http://ur1.ca/ns957
15:12 imirkin_: as root, i guess
15:12 imirkin_: Capabilities: <access denied>
15:14 pecisk: http://ur1.ca/ns966
15:15 imirkin_: can you confirm that your motherboard supports PCIe v3?
15:15 pecisk: yes
15:15 imirkin_: k, give me a min
15:15 imirkin_: have to remember hwo this works
15:16 imirkin_: right. nvapeek 8c040
15:16 imirkin_: (nvapeek is part of envytools... need to get that if you don't have it already)
15:17 pecisk: imirkin_: no rush, I am going to get some shut eye...got some fun with UT4
15:17 pecisk: nvapeek gave me 0008c040: 80089000
15:17 pecisk: but see ya tomorrow :)
15:17 imirkin_: ok, that's expected
15:17 pecisk: thanks for all help
17:57 dylanetaft: Hey - is there any good way to capture information for a bug report for nouveau? I'm on the 4.3 rc1 kernel, GL stuff deadlocks the system pretty quickly and it reboots
17:58 dylanetaft: prior to 4.3 it was worse, there was lots of graphical corruption before rebooting
17:58 imirkin_: is this a new issue with 4.3?
17:58 dylanetaft: no.
17:58 imirkin_: what GPU do you have?
17:58 dylanetaft: NVS 140, pretty old
17:58 imirkin_: pastebin dmesg?
17:59 dylanetaft: It's empty
17:59 dylanetaft: I do have a kernel log running, nothing ends up in there prior to reboot
17:59 dylanetaft: on older kernels I'd start seeing messages like nouveau: memory address, hundreds of lines, graphics would start currupting, then reboot
17:59 imirkin_: can you pastebin the output of dmesg?
17:59 dylanetaft: yeah just a second
18:00 imirkin_: anyways, i suspect i know what the issue is
18:00 imirkin_: in that it happens to a lot of other people
18:00 imirkin_: but i have no idea what the cause is
18:00 dylanetaft: http://pastebin.com/7170VLYv
18:00 imirkin_: basically the command stream desync's
18:01 dylanetaft: Every other aspect of nouveau works better, xrender accel, etc. its faster everywhere else.
18:01 dylanetaft: so I'm hoping to run it
18:01 imirkin_: this is rather unlikely to help, but you could try booting with nouveau.config=PCRYPT=0
18:01 dylanetaft: yeah give me a min
18:02 imirkin_: some (but not all) NVS 140's are missing a PCRYPT engine
18:02 imirkin_: however yours doesn't appear to be one of those based on the dmesg
18:02 imirkin_: PCRYPT is used, among other things, as a background copy engine
18:02 imirkin_: errrrrr
18:02 imirkin_: gr. ben renamed everything
18:03 dylanetaft: hold off then?
18:03 dylanetaft: :)
18:03 imirkin_: yeah, sec
18:03 imirkin_: need to figure out what the new way is
18:03 dylanetaft: I gotta find where to put this, like 10 years ago I woulda edited grub.cfg but now everything is so complex
18:04 dylanetaft: maybe in modprobe config instead
18:04 Karlton: grub is still simple if you don't use the autogenerated config
18:05 dylanetaft: i'm using the autogen config
18:05 dylanetaft: its not humanly readable haha
18:06 dylanetaft: is that a custom module option? I can probably put it in /etc/modprobe.d right? nouveau is not built into my kernel, just a module
18:07 imirkin_: dylanetaft: nouveau.config=cipher=0
18:07 dylanetaft: thanks
18:08 imirkin_: or you can put something in modprobe.conf, but on the kernel cmdline is easier
18:13 dylanetaft: rebooting, brb
18:18 dylanetaft: Ok, trying again
18:18 imirkin_: wait
18:19 imirkin_: pastebin dmesg agian
18:19 imirkin_: want to make sure it worked
18:20 dylanetaft: http://pastebin.com/2zFrmGyx
18:20 dylanetaft: my hunch right now is that it's related to switching resolutions right now
18:21 dylanetaft: prior to 4.3 it was just always immediately unstable. right now games start, but if i try to change res in game it goes nots
18:21 imirkin_: nouveau 0000:01:00.0: DRM: MM: using M2MF for buffer copies
18:21 imirkin_: ok, so the cipher=0 bit worked
18:22 dylanetaft: ok, shall i try?
18:22 imirkin_: (before it said it was using PCRYPT)
18:22 imirkin_: yeah i guess
18:22 dylanetaft: is there a performance advantage to one or the other btw
18:22 imirkin_: i think so yeah
18:22 imirkin_: the other thing is that this was back when GPUs would desolder themselves from boards
18:22 imirkin_: so perhaps that's also what's going on
18:23 dylanetaft: oh dear god
18:23 imirkin_: in which case, stick it in the oven for a few minutes and it's good to go
18:23 dylanetaft: my screen is degrading into broken polygons
18:23 dylanetaft: all over the place
18:23 dylanetaft: let me restart the game before it crashes
18:24 imirkin_: can you grab dmesg?
18:24 dylanetaft: yes its loaded with crazy stuff
18:24 imirkin_: pastebin :)
18:24 imirkin_: i'd like to see the brand of craziness
18:24 dylanetaft: http://pastebin.com/kp2j4DiM
18:25 dylanetaft: trying again, launching it on my other monitor where it worked before
18:25 imirkin_: hmmmm
18:25 imirkin_: fb: trapped read at ff00ffff00
18:25 imirkin_: that seems like an odd virtual address ;)
18:25 imirkin_: i'm gonna go with "something's messed up"
18:26 imirkin_: fwiw that is not the brand of fail i was expecting to see
18:26 dylanetaft: ok, so my system didnt completely crash this time
18:26 dylanetaft: it does work on the primary monitor, slowly
18:27 dylanetaft: if i change resolution, the same thing happens, the window goes nuts, resizes, the aspect ratio looks all wrong, then parts of the game start getting drawn all over the screen
18:27 dylanetaft: um it feels like my GPU clocked down
18:27 dylanetaft: the system didnt crash but im watchin the screen redraw itself
18:28 imirkin_: probably an interrupt storm
18:28 dylanetaft: http://pastebin.com/gtw5nD4p
18:28 dylanetaft: yeah its getting slower and slower but nothing is running anymore
18:28 dylanetaft: gonna reboot i guess
18:29 dylanetaft: well, definitely an improvement over 4.2
18:30 dylanetaft: brb rebooting and removing that option i suppose
18:30 imirkin_: next step is stick it in the oven i guess ;)
18:30 dylanetaft: haha what
18:30 dylanetaft: to destroy it or reflow the solder?
18:30 imirkin_: the poor man's reflow soldering facility
18:30 dylanetaft: hahah
18:30 imirkin_: i prseume you don't have access to a real one
18:30 dylanetaft: it actually works fine with the proprietary driver, at least the 3d bits
18:31 dylanetaft: the 2d bits dont function as well
18:31 dylanetaft: i do have a rework station if it came down to that :p
18:31 dylanetaft: brb rebooting
18:31 imirkin_: is it in your kitchen?
18:31 dylanetaft: ha
18:31 dylanetaft: was very close to building the toaster oven + arduino one
18:35 imirkin_: anyways, it's entirely likely that there's something we're not handling properly that the blob does correctly, which in turn leads to all these error cases.
18:35 dylanetaft: is there anything I can do to help troubleshoot that? or not in particular? right now its pretty much 100% tied to resolution changes when the 3d bits are turned on
18:35 dylanetaft: and dual monitor issues
18:36 dylanetaft: ie the game starts on the primary monitor, on the secondary it just draws polygons all over
18:36 imirkin_: i mean, if you can figure out exactly what's going on, that sure would be helfpul
18:36 dylanetaft: if i change the res the system reboots
18:36 dylanetaft: at one point prior to the system rebooting it popped up a message about the kernel denying something and then a bunch of nouveau: memory addresses
18:36 imirkin_: but i don't have any great advice on how to achieve such an understanding
18:36 dylanetaft: i can try to get a screen cap on my phone
18:37 imirkin_: perhaps skeggsb would... but i bet he's traveling right now
18:50 dylanetaft: is the pstate stuff broken?
18:50 dylanetaft: if I try to write to pstate it says function not implemented
18:50 imirkin_: it's not broken
18:50 imirkin_: it's just not enabled for your chipset
18:51 dylanetaft: dang
18:52 dylanetaft: so it doesnt speed up when theres 3d rendering going on?
18:52 imirkin_: no
18:53 imirkin_: even if you had reclocking, it still wouldn't
18:53 imirkin_: there's no automatic reclocking at all
18:53 dylanetaft: unless you do it manually?
18:53 dylanetaft: yeah
18:53 imirkin_: it's coming though... slowly
18:59 dylanetaft: i'm totally looking at the source of the nouveau driver to see how unimplemented it really is
18:59 dylanetaft: im gonna blow up my GPU ;)
18:59 imirkin_: dylanetaft: well, it's slightly implemented
19:00 dylanetaft: if its a matter of like editing a table of device ids and seeing if it works post recompile...;)
19:00 imirkin_: and there are a few more bits here: https://github.com/RSpliet/kernel-nouveau-nv50-pm/commits/master
19:00 dylanetaft: oh neat, thanks
19:00 imirkin_: but... his code guards things on generations instead of guarding it on features
19:00 imirkin_: so i'm pretty sure it's wrong
19:01 imirkin_: but roy just doesn't have the inventory at hand right now to figure some of this stuff out
19:11 dylanetaft: dig dig dig....nvkm_clk_ctor ultimately ets called with allow_reclock per class of device...
19:18 dylanetaft: 0.369318] input: AT Translated Set 2 keyboard as /devices/platform/i8042/se
19:18 dylanetaft: whoops
19:18 dylanetaft: I found the code that sets what can be reclocked...g84.c :) only works with a single chipset it looks
19:19 dylanetaft: im just gonna change that to true and destroy everything
21:44 imirkin: gr. every time i go to try to fix some tiny little bug it becomes some huge thing that was wrong :(
21:45 airlied: all the easy bugs are fixed :-P
21:47 imirkin: turns out the way that we do resource invalidation is *totally* wrong
21:48 imirkin: and if it worked without blowing up, it was entirely coincidental
21:48 imirkin: sigh
21:54 imirkin: errrrr.... hrm.
21:54 imirkin: maybe it wasn't so broken
22:14 imirkin: and yet it is.
22:20 dylanetaft: hehe, i turned pstate on for my gpu, it does indeed work
22:28 imirkin: as in... it actually changes clock speeds?
22:28 imirkin: all without hanging?
22:28 dylanetaft: Yup!
22:28 dylanetaft: extra FPS in GLXGears, extra FPS in games
22:29 dylanetaft: if I do it when 3d stuff is running it gets flakey though
22:29 dylanetaft: best to do it in console
22:29 dylanetaft: I'm posting to the mailing list, there's a weird check that actually disables it for NVS140
22:29 dylanetaft: its enabled only for chipset 0xa0, which I think is just generic NV50?
22:30 dylanetaft: Ultimately it uses the nv50_clk_new_ code, for all similar cards
22:33 imirkin: 0xa0 is G200. yours is a G86
22:33 dylanetaft: Ahh
22:34 dylanetaft: How do you know what the chipset is? It looks like it does some reading of registers
22:34 dylanetaft: no way to tell after the fact unless you just "know" ?
22:35 imirkin: nvapeek 0
22:35 dylanetaft: Cool
22:39 dylanetaft: Heheh, i posted to the mailing list
22:40 imirkin: probably got caught in a filter if you're not subscribed
22:41 imirkin: anyways, getting it to be stable is the tricky bit
22:45 dylanetaft: I mean, it looks sort of brain dead, it's just writing some registers that deal with the clock rate. I imagine a proper solution would involve like telling the graphics card to kick everything out of vram and tell X to stop sending stuff to xrender etc
22:45 dylanetaft: i imagine it gets unstable if you change the card when it's busy..
22:45 dylanetaft: not even sure if that is possible with X
22:45 imirkin: no
22:45 imirkin: a script is composed
22:45 imirkin: which is executed by the gpu
22:46 imirkin: which among other things pauses all engines, etc
22:46 dylanetaft: oh i see
22:46 imirkin: there are also various subtleties wrt exactly how to configure the vram...
22:46 imirkin: what kind do you have btw? GDDR3?
22:46 dylanetaft: I think its GDDR3...
22:46 dylanetaft: It does all that today? The script?
22:47 imirkin: yea
22:47 imirkin: but we might not have quite figured out all the various cases it's supposed to do
22:47 imirkin: for any particular situation we can see what the blob generates
22:47 dylanetaft: I guess I didn't dig deep enough, I saw some bits where it was reading from registers for available clock rates and stuff, and those get sent to the gpu
22:47 imirkin: and we basically have to generate the same thing
22:47 imirkin: but it's not always clear why the blob does certain things
22:48 imirkin: look for "hwsq"
22:48 imirkin: although iirc in the code it's just done with ram_foo macros
22:48 imirkin: which in turn resolve to hwsq* for pre-gt215
22:48 imirkin: or... something
22:48 dylanetaft: gotcha i see it.../* prepare a hwsq script from which we'll perform the reclock */
22:49 dylanetaft: haha i love these comments
22:49 dylanetaft: "nfi what this is"
22:50 imirkin: at least we're honest :)
22:51 dylanetaft: is there like a toolkit that monitors what the binary driver does
22:52 dylanetaft: itd be cool if there was something end users like myself could run and submit traces or something
22:52 imirkin: mmiotrace
22:52 imirkin: and there's mmio.dumps@gmail.com
22:52 imirkin: it's almost as if we had thought of these things :)
22:54 dylanetaft: If I recorded flip flopping GPU speeds while running GLX gears..if that would turn anything up
22:54 dylanetaft: or the other issue, changing res while running 3d apps
22:54 imirkin: that's trickier... that actually might not show up in the mmiotrace, at least not fully
22:55 dylanetaft: ah
22:56 dylanetaft: Well, thanks for your help. I'm probably going to keep using the nouveau driver. The 3d is actually mostly in 4.3 for me as long as I don't switch res.
22:57 dylanetaft: mostly stable*
22:57 dylanetaft: 4.2 and 4.0 it definitely was not stable
22:58 dylanetaft: good night
23:07 dfooz_zzz: but like the thing im still a bit confused on - XOrg is single threaded, right? Cairo uses XRender uses EXA ultimately uses stuff in the DRI nouveau kernel module. That's all happening on one thread? GLX rendering too?
23:08 dfooz_zzz: Even if you send a script to the GPU to stop processing various stuff, there's no other threads hitting it telling it to do other stuff?
23:08 pq: single-threaded can be async, too. But yes, X.org is inherently single-threaded, sans stuff done in signal handlers.
23:09 airlied: 3D rendering does go via the X server though
23:09 dfooz_zzz: it does?
23:09 airlied: doesn't
23:09 airlied: sorry
23:09 dfooz_zzz: oh
23:10 dfooz_zzz: so that probably might explain why it goes unstable when I try to change the GPU clock when 3d apps are running
23:11 dfooz_zzz: nvidia might have some logic in the GLX code too, like a semaphore between GLX and the kernel driver
23:13 pq: everything hits the kernel driver anyway, that's the only guaranteed common point
23:15 dfooz_zzz: is there some sort of context switching for that, or can stuff be called asynchronously in the kernel driver?
23:15 pq: instability in your case might be just due to Nouveau not doing exactly the correct magic dance needed for reliable reclocking. Or is using a method that is inhenrently less reliable than what the blob does.
23:18 imirkin: pq: we use hwsq scripts now, so it should be theoretically as reliable
23:18 mrnuke: imirkin: So, no display whatsoever :)
23:18 imirkin: mrnuke: yay!
23:18 imirkin: mrnuke: there are some patches in 4.3-rc1 which help with displayport on gm107
23:19 mrnuke: oooh. need a fresher kernel then
23:19 mrnuke: alright
23:19 mrnuke: I'm on 4.04
23:20 mrnuke: display "not found"
23:20 dfooz_zzz: it just seems to be that you'd need to lock everything up while something like the clock is changing. like nothing else can happen in the driver while that section of code is running or it might destabilize the process.
23:21 dfooz_zzz: but i dont really know what I'm talking about.
23:21 imirkin: dfooz_zzz: yeah, that's precisely what the script does.
23:21 imirkin: at least in theory
23:21 dfooz_zzz: its telling the GPU to stop, but
23:21 dfooz_zzz: cant the driver if parts are running in other threads be sending other commands to the GPU in parallel?
23:21 dfooz_zzz: or is DRM and the kernel all synchronous and single threaded?
23:21 imirkin: well, the script just suspends all gpu activity
23:21 imirkin: so it doesn't matter how many threads you have
23:22 imirkin: it just pauses the FIFO
23:22 imirkin: which is the thing that processes commands
23:22 dfooz_zzz: right, its not taking into account that other commands could be sent to the GPU? ooh.
23:22 imirkin: it's questionable whether it properly *drains* commands currently executing though
23:22 dfooz_zzz: ahhhh.
23:23 imirkin: also there's a whole lot of subtlety going on with vram parameters
23:23 imirkin: which we might be getting variously wrong
23:23 dfooz_zzz: I get it. Thanks for explaining.
23:23 mrnuke: imirkin: however, to be 100% honest, I did not try the card in a system running coreboot yet
23:24 imirkin: mrnuke: probably good to start with something that at least might work
23:24 mrnuke: imirkin: I get BIOS screen display, and early vga, but once it loads up all the drivers, black screen
23:25 imirkin: is it hooked up via DP?
23:25 mrnuke: I only have DP outputs on this card :)
23:25 imirkin: so then you probably want the patches that went into 4.3-rc1
23:25 mrnuke: probably? I thought "certainly" :p
23:26 imirkin: these 4 commits: http://cgit.freedesktop.org/~darktama/nouveau/log/?id=690945ff3f49bdab115011cd449120db24c4be36
23:26 imirkin: how about "quite likely"
23:26 dfooz_zzz: I wonder if you arbritrarily add a sleep in there, if the commands could finish executing
23:27 dfooz_zzz: and if that works it gives a place to start to figure out how to properly wait for commands to finish
23:27 imirkin: dfooz_zzz: the thing to do is look at the script that the blob generates and the one we generate
23:27 dfooz_zzz: to see if thats even the issue
23:27 imirkin: and look for differences
23:27 dfooz_zzz: mmiotrace might capture that?
23:27 dfooz_zzz: ill maybe try and take a stab at that tomorrow
23:28 imirkin: yeah, it should be in the mmiotrace
23:28 imirkin: this is a good guide on how to do it: https://wiki.ubuntu.com/X/MMIOTracing
23:30 dfooz_zzz: Thanks. And if the g86 shows a different process for whats happening...it'd get added to a g86_clk_calc command probably in ./nvkm/subdev/clk/g84.c or something
23:30 imirkin: well, it wouldn't be g86-specific
23:30 imirkin: it'd be specific to something in your vbios
23:30 dfooz_zzz: oh, thats annoying.
23:31 imirkin: quite.
23:32 dfooz_zzz: It could still be added to a file as such, vbios probably isnt shared across generations of GPUs?
23:32 imirkin: vbios isn't shared across diff gpu's of the same type either
23:32 dfooz_zzz: im gonna have to figure out if theres some sort of vbios id then so .calc can be set to a function pointer based on bios
23:33 imirkin: it's full of tables though
23:33 imirkin: just need to figure out how to decode them