00:16 Tom^: imirkin: http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/nouveau/nouveau_driver.h#n72 arent these duplicate const declerations kinda unnecessery? :p
00:17 imirkin: yes and no
00:17 imirkin: what the author actually meant was "const char *const"
00:17 imirkin: so... as written, no. but with the original intent, yes :)
00:18 Tom^: oh i see
00:18 imirkin: feel free to send a patch
00:21 imirkin: time for sleep though... bbl
02:20 hakzsam: imirkin, compute in priority
05:46 damex: so i loaded nvidia with intel instead of nouveau plus intel. no gf119m audio device ;(
06:21 kugel: hello. I'm experiencing poor performance (my impression) even through the fps are alright. do you have any hints? I'm on karolherbst reclock branch
06:21 kugel: either on how to measure this or a workaround
06:23 kugel: game is dota 2
06:29 kugel: the fps reported in game are around 40-50 fps but it feels like 15-20. the same reported fps feel fluent under windows and the binary driver
06:30 kugel: fwiw, I'm playing in windowed mode in gnome 3, since I'm getting flickering cursor in full screen mode, this is another major problem
08:09 imirkin: kugel: i assume you have a redirecting compositor enabled in gnome 3, which isn't great for gaming. normally it disables itself when there's a full-screen application, but you can also try disabling it separately. hopefully that's something that gnome 3 lets you do.
08:41 kugel: actually the flickering in full screen is only when I enable PRIME. are there known issues with it?
08:41 imirkin: kugel: PRIME or reverse-PRIME?
08:41 imirkin: i.e. are you slaving a screen on a secondary gpu, or are you offloading rendering to a secondary gpu?
08:43 kugel: imirkin: PRIME, however with discrete GPU as primary
08:43 kugel: (I've got a notebook-with-external-gpu setup)
08:44 imirkin: kugel: external gpu? like on a pci-express expander thingie?
08:45 kugel: yea, expresscard adapter
08:47 imirkin: and what gpu is primary?
08:48 imirkin: Tom^: pushed this out: http://cgit.freedesktop.org/mesa/mesa/commit/?id=bf34748b39a8ae81f314db083eb73bb0be4e9c1d
08:48 Tom^: nice
08:48 Tom^: i got another thing for you too
08:49 kugel: imirkin: gf 650 ti
08:49 imirkin: and what gpu are you offloading to?
08:49 Tom^: imirkin: https://gist.github.com/anonymous/323a9077a78349b1a4d9
08:49 glennk: aren't those pcie expanders really bandwidth limited?
08:50 Tom^: imirkin: otherwise it warns about being uninitialized.
08:50 kugel: I'm running karolherbst's reclock branch plus a patch to ramp the voltage, so that pstate=0f works fine
08:50 imirkin: Tom^: it is wrong.
08:50 Tom^: is it?
08:50 imirkin: Tom^: it is.
08:50 Tom^: ;_;
08:51 imirkin: Tom^: or conversely, explain to me how it is right
08:52 Tom^: imirkin: "nv30/nv30_context.c:44:41: warning: variable 'nv30' is uninitialized when used here [-Wuninitialized]" "nv30 = container_of(push->user_priv, nv30, bufctx);" , the second argument passed generates a compiler warning about being uninitalized otherwise.
08:52 imirkin: container_of doesn't care about the value of nv30.
08:52 Tom^: sure, but the compiler thinks it does :P
08:52 Tom^: ugly warnings
08:53 karolherbst: imirkin: but the value can be uninitialized even after container_of
08:53 imirkin: the compiler is wrong.
08:53 imirkin: karolherbst: nv30 = result-of-container_of
08:53 imirkin: Tom^: if you want to rewrite it somehow that's fine with me, but i don't want to go around adding = 0 initializers all over the place for no reason.
08:53 karolherbst: where is container_of defined?
08:54 kugel: karolherbst: hey. your suggestion from the ml works fine
08:54 karolherbst: kugel: the upvolting?
08:54 kugel: year
08:54 kugel: yeah*
08:54 karolherbst: k
08:54 Tom^: imirkin: hehe sure, i was just looking at various compiler warnings, thought to silence them
08:54 karolherbst: just make sure your gpu doesn't get too hot
08:54 karolherbst: also power consumption _might_ be a problem
08:54 karolherbst: I don't think the card will consume too much power though
08:54 kugel: sensors doesn't go above 45°
08:55 karolherbst: I bet unigine heaven may change that real quick
08:55 imirkin: kugel: so your primary gpu is a 650Ti? that's inside the laptop?
08:55 kugel: no, outside under the desk
08:55 imirkin: kugel: and that's what's driving the screens?
08:55 karolherbst: imirkin: I guess his display is connected to the 650 ti
08:56 imirkin: kugel: and then you're trying to offload from that to... what?
08:56 kugel: that's right
08:56 kugel: the egpu shall render to the laptop's display as well
08:56 karolherbst: that's reverse prime
08:57 imirkin: right, but that 650Ti isn't connected to the laptop display
08:57 imirkin: so what's driving the laptop display?
08:57 kugel: intel
08:57 imirkin: got it. this is *very* uncommon setup
08:57 imirkin: let's say i don't believe you -- mind pastebinning your xorg log?
08:59 kugel: http://pastebin.com/7fm45ZBe
09:00 imirkin: kugel: neat :)
09:00 imirkin: you weren't lying
09:01 imirkin: and so the problem is when displaying on the nvidia-attached screen or the intel-attached screen?
09:05 glennk: just pushing 1920x1080@60Hz pixels will just about saturate a single 5GT/s pcie link unless i'm mistaken
09:20 karolherbst: glennk: mhh I think a 2.5 link is fast enough for that though
09:21 karolherbst: 2.8GBit/s are needed for that?
09:22 glennk: not sure how you are arriving at that number
09:22 karolherbst: pixel per seconds * 24
09:22 glennk: 60 hz, not 24
09:22 karolherbst: 24 is bit per pixel
09:22 karolherbst: 1920*1080*60*24 / 1024 / 1024 / 1024
09:23 glennk: 4 bytes/pixel, not 3
09:23 karolherbst: ahh
09:23 karolherbst: then 3.7GB/s
09:23 karolherbst: *bit
09:23 glennk: which is too much for a 2.5 link isn't it?
09:23 karolherbst: yeah 2 2.5 lanes or 1 5.0 lane should be enough
09:23 karolherbst: 2.5GT/s per lane
09:23 glennk: afaik those laptop ports only have a single lane
09:23 karolherbst: if you have x16 2.5 you get 40 Gbit/s
09:24 karolherbst: ohh those express cards
09:24 karolherbst: kugel: is is express card or something else?
09:24 karolherbst: I thought they go up to 4 lanes
09:25 karolherbst: ohh no, that was thunderbolt
09:25 karolherbst: express card is really slow :O
09:25 karolherbst: 3.2 Gbit/s with the fastest thing
09:25 karolherbst: glennk: you are right, express card is obviously the bottleneck
09:39 Misanthropos: whats that karolherbst patch? I have a gtx 650Ti and issues with some games running in pstate 0f mode in gentoo. mesa 11.1.0 / kernel 4.4.0-rc7 / xf86-video-nouveau-9999
09:39 Misanthropos: would that patch help avoid freezing the system?
09:40 kugel: imirkin: the problem is when displaying on the nvidia-attached screen
09:40 karolherbst: Misanthropos: most likely
09:41 karolherbst: Misanthropos: I assume you can reclock to 0f but it sometimes freezes?
09:41 Misanthropos: indeed
09:41 Misanthropos: depends on the game though
09:41 karolherbst: yeah, then the gpu needs a higher voltage
09:41 karolherbst: most likely
09:41 Tom^: imirkin: but http://cgit.freedesktop.org/mesa/mesa/tree/src/util/list.h#n146 the comment says sample must be initialized or else the result is undefined. :o
09:41 karolherbst: I never wrote such a patch, but the change is trivial
09:42 karolherbst: Misanthropos: replace info.min with info.max in drm/nouveau/nvkm/subdev/volt/base.c:nvkm_volt_map
09:42 Misanthropos: omw :D
09:42 imirkin: Tom^: so send a patch changing it to read "the compiler does totally bogus things and instead of fixing the compiler, we caved and wrote bogus code here"
09:42 kugel: imirkin, karolherbst, karolherbst: the expresscard is a bottleneck, yes, running only at 2.5GT/s (could be 5.0GT/s with a newer adapter, though). I have to use a external display directly attached to the nvidia to get any useful performance
09:42 Tom^: imirkin: =D
09:43 karolherbst: kugel: yeah, then you will also have issues using the internal screen
09:43 kugel: Misanthropos: heh, you've got the same card as me :-)
09:43 imirkin: Tom^: for whatever reason, many people's inclinations is to pander to broken tools by breaking their own stuff. my inclination is to stop using the tool or getting it fixed.
09:44 Tom^: oh idk, i barely know how that defenition works. i just got curious :p
09:44 kugel: karolherbst: i want only the desktop (and perhaps irssi) on the internal screen, shouldn't make be a big deal. I can do that fine under windows
09:44 Misanthropos: kugel - and you can offload opengl to that card, while using intel normally? did i get that right?
09:44 karolherbst: kugel: maybe windows does compression on the data
09:45 karolherbst: or reduces the display rate or something
09:45 imirkin: well the internal screen is only 1366x768, not 1920x1080
09:45 imirkin: so it doesn't saturate the whole link
09:45 karolherbst: ohhh
09:45 kugel: i think so, the nvidia optimus thingy is doing it
09:45 kugel: but there should be only traffic on the link when the contents change, no?
09:45 karolherbst: I thought optimus is a mobile chip only thing
09:46 karolherbst: mhhhh
09:46 karolherbst: if you are intelligent, yes
09:46 kugel: anyway I did get good performance in dota 2 with this setup, it's just the cursor blinking/flashing that's unworkable
09:46 karolherbst: I doubt that prime does that or windows though
09:46 karolherbst: Misanthropos: he has an external gpu
09:46 kugel: pcie is bidirectional so the game performace shouldnt suffer a lot from traffic in the other direction
09:46 kugel: iiuc
09:48 karolherbst: imirkin: by the way: the compiler warning is right in container_of
09:48 karolherbst: #define container_of(ptr, sample, member)
09:48 karolherbst: (void *)((char *)(ptr) ((char *)&(sample)->member - (char *)(sample)))
09:49 imirkin: karolherbst: so then the solution is to fix container_of. the solution is *not* to add a 0 initializer
09:49 imirkin: adding initializers is the *last* resort
09:50 karolherbst: something is fishy though :O
09:52 karolherbst: imirkin: comment above container_of: 'sample' MUST be initialized, or else the result is undefined!
09:53 karolherbst: sooo
09:53 karolherbst: nv30 must be initialized
09:53 imirkin: the comment is wrong.
09:53 karolherbst: ohh k
09:53 imirkin: having to initialize before using container_of is idiotic
09:54 imirkin: if the macro requires it, then the macro is broken
09:57 Tom^: is having initializers generally frowned upon?
10:00 karolherbst: Tom^: it generates additional instructions if not optimized away by the compiler
10:00 Tom^: ah
10:00 karolherbst: especially in C++
10:00 karolherbst: you can have constructor calls and stuff
10:01 karolherbst: like std::string str; str = "blah"; // 1 constructor, 1 copy assignment ;)
10:01 Tom^: mm
10:02 imirkin: initializing something that could be left uninitialized is a sign of failure.
10:02 karolherbst: well it depends though
10:03 karolherbst: for example int error = 0; .... ; return error;
10:03 imirkin: if error is initialized in all paths, then you should leave off the initializer
10:04 karolherbst: not really
10:04 karolherbst: because if no error happens you want it to be 0
10:04 imirkin: otherwise you'll accidentally return 0 when you meant to return an error
10:04 imirkin: it depends on what the algo calls for
10:04 karolherbst: okay, then we call it statusCode :D
10:04 imirkin: if you really do want to only set error in a few situations
10:04 imirkin: then an initializer up-front is fine
10:05 karolherbst: yeah, it depends. Sometimes you can reduce the code a bit by putting a value at initialization time
10:06 imirkin: and that's fine
10:06 imirkin: what's not fine is if you don't need it
10:06 imirkin: and then all of a sudden some idiotic compiler warning tells you "oh, i can't figure out that this is actually totally fine"
10:06 Tom^: =D
10:06 karolherbst: yeah well, but from the look of that macro it seems not fine :/
10:06 imirkin: which you solve by slapping an initializer on there
10:06 karolherbst: but the macro somehow doesn't make much sense to me anyway
10:06 imirkin: karolherbst: what's the scenario?
10:06 imirkin: karolherbst: what could the compiler do to mess it up?
10:07 karolherbst: - (char *)nv30
10:07 imirkin: ... and what's wrong with that?
10:07 karolherbst: well if nv30 isn't initialized it could be anything
10:07 imirkin: what's the problem with that?
10:07 imirkin: what value could nv30 have that would cause that thing to not work?
10:08 kugel: so nobody has an idea why the in-game cursor blinks/flashes quickly in a PRIME setup? the cursor is fine on the desktop
10:08 imirkin: kugel: if it were flickering on your internal screen, i'd say it made sense
10:08 imirkin: kugel: since hw cursor is disabled for reverse-prime screens
10:08 karolherbst: imirkin: ohh now I see it
10:08 imirkin: karolherbst: :)
10:09 karolherbst: (ptr*) &nv30->some_member - (ptr*)nv30
10:09 karolherbst: without the *
10:09 karolherbst: :D
10:09 karolherbst: k
10:09 karolherbst: mhhh
10:10 kugel: imirkin: right, this is on the nvidia-attached screen, should be hw cursor, but enforcing sw cursor (via xorg.conf) didnt make a difference
10:11 karolherbst: imirkin: gcc bug about this would be a fun discussion :D
10:11 kugel: Misanthropos: I can confirm that karolherbst's reclock branch + the voltage patch gives stable 0f pstate. however, my setup is special with much better cooling for the card so you have to carefully watch the sensors when doing the voltage change (can give you a diff if you want=
10:11 karolherbst: kugel: the bigger issue is power consumption though
10:11 karolherbst: but it shouldn't matter that much with those cards
10:11 imirkin: karolherbst: they'd quote some idiotic language spec that lets them do whatever they want whenever they want
10:12 karolherbst: because they are pretty close to the max voltage anyway
10:12 karolherbst: imirkin: well technically they are correct, because who guarentees that both reads of nv30 give the same value?
10:12 imirkin: reality.
10:12 karolherbst: maybe on some exotic archs funny stuff coul happen :D
10:12 kugel: oh right. my card has a separate psu just for itself so I think I'm fine
10:13 karolherbst: kugel: yeah well, I was more talking about the power you get out of the pcie bus + pins
10:13 karolherbst: you can't get unlimited through it
10:13 imirkin: karolherbst: variables can't change between successive reads unless they're volatile
10:13 imirkin: [and are pointers]
10:13 Misanthropos: kugel: just applied the patch and compiling the kernel. i will keep an eye on the temperature! thanks
10:13 karolherbst: imirkin: even if they are not initialized?
10:14 kugel: Misanthropos: in case you didn't know, the sensors tool gives the infos (I run "watch -d -n 0,5 sensors")
10:14 karolherbst: I would guess this falls under undefined behaviour
10:14 karolherbst: I ask in the gcc IRC channel :D
10:15 imirkin: karolherbst: they'll tell you i'm an idiot
10:15 kugel: can't the macro just use offsetof which should be supported by gcc?
10:15 imirkin: karolherbst: and that i haven't read the specs
10:15 imirkin: kugel: does MSVC support that?
10:15 Tom^: before you go in to deep, i dont know if this warns on gcc.
10:15 Tom^: its on clang
10:16 kugel: don't know, but gives MSVC that warning? the macro defintition could be inside #ifdef __GNUC__
10:16 karolherbst: Tom^: ohhhhhh
10:16 karolherbst: you should tell me before :D
10:18 imirkin: kugel: could be. i don't care how people resolve it. i just care how they *don't* resolve it, and that's by adding pointless initializers in my code :)
10:19 kugel: clang probably supports offsetof as well
10:19 kugel: i think offsetof is part of c11 or even earlier
10:20 Tom^: imirkin: =D i will not suggest such sin again.
10:20 karolherbst: Tom^: yeah on gcc there is no warning
10:20 karolherbst: imirkin: they suggest to use offsetof
10:20 imirkin: kugel: MSVC barely implements C99
10:20 imirkin: kugel: aka they don't even support all of C99
10:20 imirkin: kugel: so i wouldn't hold out too much hope for C11
10:20 kugel: MSVC can use the current version of the macro
10:22 kugel: also I was not aware that windows/msvc is even still a thing of interest for mesa
10:23 karolherbst: imirkin: mhhh
10:24 karolherbst: imirkin: I think the code is wrong in either case
10:24 imirkin: [and maybe new MSVC has it all, but the MSVC 2008 or whatever that vmware uses is crap.]
10:24 karolherbst: because you really access that pointer and deference it
10:24 karolherbst: and if the pointer is anyway, it could point to some illegal memory area
10:24 imirkin: karolherbst: and then take a reference of the deref
10:24 imirkin: karolherbst: so nothing is dereferenced and you just do a lea instruction
10:25 imirkin: (load effective address)
10:25 karolherbst: if the compiler is smart, yes
10:25 imirkin: compiler is smart.
10:28 karolherbst: okay, so they say it could blow up :/
10:32 karolherbst: and they really suggest to use offsetof or __builtin_offsetof if the former isn't available
10:34 Misanthropos: so that seemed to fix it indeed. temperature still below 55C
10:34 Misanthropos: thank you :)
10:34 karolherbst: Misanthropos: well power consumption is the bigger issue here ;)
10:34 karolherbst: but as long as your PSU is strong enough it should be fine
10:34 Tom^: karolherbst: i havent blown up anything on my 780ti yet. so meh. xD
10:34 imirkin: enjoy! and please report any bugs you might see... not a lot of the developers actually play games.
10:35 Tom^: i can gladly report 7 days to die works flawless on nouveau and mesa.
10:35 karolherbst: Tom^: well your gpu is drivver at highest voltage anyway
10:35 karolherbst: *driven
10:35 karolherbst: imirkin: even msvc 2003 .NET has offsetof
10:43 orbea: imirkin: what was that x264 error your were talking about? I'm experiencing some videos hiccupping iregularly, like the video goes back a fraction of a second. Its not consistent.
10:43 imirkin: orbea: that sounds like a frame ordering issue... which is weird.
10:43 imirkin: orbea: i meant much more straight-up corruption... like macroblocks being messed up
10:43 orbea: ah, I haven't seen that
10:44 imirkin: orbea: frame ordering means that something is terribly wrong though =/
10:44 orbea: :\ It could of been just that series, I will keep an eye out for it in more videos
10:44 karolherbst: orbea: is that with prime?
10:44 orbea: prime?
10:45 karolherbst: gpu offloading
10:45 imirkin: oh yeah, if you're using DRI_PRIME=1 i could imagine that :)
10:45 orbea:wonders where to look if he's doing that
10:45 imirkin: if you don't know, then you're not :)
10:45 karolherbst: then you don't :D
10:46 karolherbst: who can edit http://nouveau.freedesktop.org/wiki/Optimus/ by the way?
10:46 imirkin: karolherbst: i can, but you should just get an account
10:46 imirkin: iirc i can just add wiki accounts.... somehow
10:47 orbea: yea, I haven't added anything other than nouveau.pstate=1 to my boot
10:47 karolherbst: under known issue there should be something like: strange tearing lines or bad frame ordering: please check that tearing preventions/vsync is enabled on both sides, window manager and the application you are running
10:47 karolherbst: something like that
10:48 karolherbst: I have not enough insight though to write a good enough part of it
11:03 kugel: karolherbst: btw, is my vbios helpful at all?
11:04 karolherbst: a little bit :)
11:04 karolherbst: it is a special case I didn't see before
11:04 karolherbst: your vbios doens't state your base or boost clock
11:04 karolherbst: also you only have three cstates
11:04 karolherbst: where a normal vbios has more like 40 or more
11:05 kugel: interesting
11:05 kugel: i wonder if I can overclock this thing?
11:06 kugel: it's so cool (temperature) there should be a lot of room
11:07 kugel: i used to overclock it under windows but don't know how to do it with nouveau (if it's possible at all)
11:08 orbea: yea, other videos have the hiccups too if using vppau hardware acceleration
11:08 orbea: i am using the mpv git which could be another factor...
11:14 imirkin: orbea: if the decoding acceleration can't keep up
11:14 imirkin: orbea: you might be seeing stale frames
11:15 imirkin: orbea: try clocking up if it's a high-bandwidth video?
11:28 orbea:look into that in a momemnt
11:43 karolherbst: kugel: temperature isn't the only issue
11:44 karolherbst: there is a hard limit of voltage
11:44 karolherbst: and you can't have the voltage be too low
11:44 karolherbst: otherwise your gpu crashes
11:45 karolherbst: but overclocking with nouveau is quite easy, you just modify your vbios a bit, upload (not flashed, so it is gone after reboot) and nouveau sees the new information
11:45 karolherbst: allthough you could just mess with the gpu regs directly and change the core multipliers
11:56 mawrick: I have a dual monitor setup with a 30" and a 17" monitor, I am having problems getting the nouveau driver to display 2560x1600 on the Dell (flickering), is there any ways to resolve this ? (I have an older Nvidia 8800 gts card), I have gotten nvidia drivers working, but seem to be a bit unstable, so was hoping to give nouveau a try.
11:56 mawrick: I see in the freedesktop site it says something about VBIOS
11:59 karolherbst: mawrick: does a lower resolution help with the problem?
11:59 mawrick: Yea, I\m able to get it to display 1920x1200
12:00 mawrick: (with the nvidia drivers I can get the 2560x1600 to work, but have experienced a few issues, so wanted to try out if I can get nouveau to work )
12:01 karolherbst: mhhh, I think imirkin knows something maybe then
12:01 imirkin: mawrick: 8800 GTS as in the original G80?
12:01 imirkin: mawrick: or is it a G92?
12:02 mawrick: I would think original G80 / its quite old
12:02 karolherbst: dmesg will tell you
12:02 karolherbst: there should be a line like "nouveau 0000:01:00.0: NVIDIA GK106 (0e6200a1)"
12:02 karolherbst: just for your gpu
12:02 mawrick: How would I get it to display only info about card ?
12:03 karolherbst: dmesg | greap nouveau
12:03 karolherbst: ...
12:03 karolherbst: dmesg | grep nouveau
12:03 mawrick: 2.404090] nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x450300a3
12:03 mawrick: [ 2.404096] nouveau [ DEVICE][0000:01:00.0] Chipset: G80 (NV50)
12:03 mawrick: [ 2.404099] nouveau [ DEVICE][0000:01:00.0] Family : NV50
12:03 mawrick: [ 2.516128] nouveau [ VBIOS][0000:01:00.0] using image from PRAMIN
12:03 karolherbst: yeah not everything ;)
12:03 karolherbst: ohh okay
12:03 karolherbst: G80 that is
12:06 imirkin: mawrick: so you're one of the few, the proud, still using that gpu :)
12:07 imirkin: mawrick: i was kinda hoping none of those existed anymore
12:07 imirkin: mawrick: pastebin your xorg log
12:08 imirkin: in general nouveau support for G80 isn't *super*... there are a bunch of things they do poorly, and our code doesn't super-duper handle
12:08 imirkin: G84+ is much better
12:08 imirkin: although things like modesetting should be working just fine
12:09 mawrick: Probably gona build a new pc in a while (this one is as you see getting really old.....) - but was on a live fedora cd just now, any idea where it stores the log ?
12:10 mawrick: (quite new to linux in general)
12:11 imirkin: mawrick: i think new fedora uses systemd so... who knows. i certainly don't.
12:12 mawrick: ahh, ok, I have debian stretch installed, but now have the nvidia drivers and I think that is on systemd as well ?
12:13 mawrick: Is there anything I should take into consideration if buying new graphic cards today when it comes to compability and high res or do newer GPU\s generally work well with nouveau ?
12:17 imirkin: mawrick: GTX 9xx gpu's basically don't work at all with nouveau right now
12:17 imirkin: mawrick: that's the "new" GM20x series
12:17 imirkin: (not so new anymore)
12:18 imirkin: mawrick: you're going to get the best support out of nouveau today with kepler GPUs
12:18 imirkin: mawrick: generally GTX 600 and 700-series. but not all -- some of those are fermi, and GTX 750 is maxwell.
12:19 imirkin: mawrick: 2560x1600 should work on the G80 though if you're using dual-link DVI-D. if you're using HDMI you might need to pass some extra kernel params to make that happen.
12:21 mawrick: ok, I have a the monitors hooked up via 2 dvi cables., but I\v tried quite a few different distros, Mint, Debina, Fedora, and all of them seem to give this flickering on the 30" while display on the 17"
12:22 imirkin: mawrick: are they DVI-D cables? and is it a dual-link connector?
12:22 imirkin: mawrick: the xorg log should provide hints as to what's going on
12:24 mawrick: I must admitt, I thought dvi was dvi, but googling now I see there is quite a few "versions" so guess I will have to disconnect the cables and have a proper look here......
12:26 imirkin: mawrick: well if it works in windows, it should also work in linux. but if you're being clever, like using an hdmi cable with hdmi <-> dvi-d adapters on either end, then you can end up fooling the various logic into doing illegal things.
12:26 mawrick: (I will check this out) / but if I understand you correctly it should more or less work out of the box without any modification ?
12:27 imirkin: should - yes.
12:27 mawrick: yea, no here is only cables from the monitors to the graphic card
12:27 mawrick: and it does work both on windows and linux with the nvidia drivers
12:28 mawrick: but experienced a bit of "tearing" and lockups on linux with the nvidia drivers, though I'm not 100% sure it's only due to the drivers.....
12:34 mawrick: imirkin, I was able to create a log in fedora, pasted it here: http://pastebin.com/HbdBFixT
12:37 imirkin: mawrick: hmmm... it appears to be perfectly happy to use the 2560x1600 mode. and it's 268mhz, which is well under the 330mhz maximum for dual-link dvi
12:38 imirkin: mawrick: i guess the remaining explanation is that the G80 is clocked low on boot and can't handle the scanout... seems unlikely though. can you pastebin dmesg?
12:39 imirkin: i don't think G80s really had multiple perf levels, although tbh i'm not sure.
12:40 mawrick: dmesg: http://pastebin.com/bdd9E8t0
12:40 imirkin: [ 2.594343] nouveau [ CLK][0000:01:00.0] 20: core 513 MHz shader 1188 MHz memory 792 MHz
12:40 imirkin: [ 2.594373] nouveau [ CLK][0000:01:00.0] --: core 198 MHz shader 1188 MHz memory 396 MHz
12:40 imirkin: oh bother.
12:41 imirkin: memory is pretty slowly clocked on boot :(
12:41 imirkin: i could imagine that not being sufficient for a 2560x1600 + 1280x1024 screen =/
12:42 mawrick: any way to change that or is it down to the card ?
12:42 imirkin: not with nouveau, at least not for now
12:42 mawrick: (I actually have a 8800 gtx sitting in another pc maybe I should try that instead.....)
12:42 kugel: karolherbst: thanks. how would I modify and upload it?
12:42 n7025: imirkin: any news about this bug? https://bugs.freedesktop.org/show_bug.cgi?id=93557
12:42 imirkin: n7025: if there were news, they'd be in that bug :)
12:43 imirkin: n7025: skeggsb should be getting in to work right about now, probably has a bunch to catch up on after the holidays... give him a little time :)
12:43 n7025: imirkin: you looked at the assembler code and toight some other dev probably would directly know where the problem could be
12:44 n7025: ah, yes, skeggsb was the nickname you told
12:44 imirkin: er, by which i mean... in a few hours. i keep getting the time in his tz wrong.
12:44 kugel: karolherbst: though i'd rather help making things stable, if I can. the cursor thing bugs me
12:45 n7025: karolherbst: sadly the hardware i liked to use for giving you access to the computer seems to be dead :(
12:45 mawrick: imirkin, Thanks for the tips and help!, appreciated
12:46 imirkin: mawrick: yeah sorry it's not better news =/
12:46 imirkin: mawrick: if you'd like to help with getting things better, you could do a mmiotrace of your card
12:46 imirkin: mawrick: with the nvidia drivers so that we can see what bits they're twiddling to get memory up
12:46 n7025: karolherbst: i tried to install a buch of software. all the packages that are normaly installed when you need to compile a kernel. Running "make" inside of nouveau/drm still fails :(
12:47 n7025: imirkin: did you know what distro skeggsb is prefering/using?
12:47 mawrick: That I can do is that a program I need to run or ?
12:47 imirkin: mawrick: https://wiki.ubuntu.com/X/MMIOTracing
12:48 imirkin: although if you're a linux newbie that might be a bit tricky to get going...
12:51 mawrick: I'l see what I can do, I have been doing a bit of linux, and "computer wise" I grew up with c64/amiga so used to trying out a bit of different stuff, I'l get back to you on this when I'v tried (might be a little while as most likely head away for work for a few weeks so not sure if I manage before I travel)
12:52 mawrick: (not implying linux was C64.....lol....)
12:52 karolherbst: kugel: read the envytools documentation :D
12:53 karolherbst: kugel: yeah the reclocking stuff is for the most part figured out now, maybe there will be some kind of reclocking. I could imagine that we would reduce the voltage per clock and don't go above the clocks the vbios provides
12:53 karolherbst: that would already work for most of the kepler cards
12:53 karolherbst: n7025: ohh
12:54 karolherbst: n7025: I guess the build directory is somehow messed up
12:55 karolherbst: n7025: well I bet he uses fedora hehe :D
12:58 n7025: karolherbst: did you have some patch i should test?
12:58 karolherbst: no, I would just inspect the contents of the variables inside that function
12:59 karolherbst: and check what exactly is odd
12:59 karolherbst: just put some printks in it
12:59 n7025: karolherbst: and did you have some changes already i should try to compile?
12:59 karolherbst: no
13:08 orbea: is there a way to pass a docdir to cmake when building envytools? I don't want to use usr/share/doc/envytools/, I could just use mv, but I don't likethat
13:09 orbea: i dont see anything relevent in cmake -LAH | less
13:12 karolherbst: orbea: you don't need to install it
13:12 karolherbst: just call the binaries inside it
13:13 karolherbst: or use a package to install it
13:16 orbea: kind of solved my question, -DDOC_PATH=
13:16 orbea: but it misses usr/share/doc/envytools/README-nva
13:16 orbea: karolherbst: I prefer managing programs with slackbuilds on my system
13:18 karolherbst: orbea: well or just call the stuff inside your build directoriy, that's also fine
13:20 jarnos: imirkin, I think I got the trace file now. It is about 10GB large.
13:20 jarnos: imirkin, using apitrace
13:22 imirkin: jarnos: ouch :(
13:22 imirkin: jarnos: does replaying it hit the original issue?
13:27 orbea: karolherbst: its much simpler to manage updating it and such with makepkg here on slackware, I worked around it, kind of silly, but w/e http://dpaste.com/25VY8NS
13:29 jarnos: imirkin, I seem to have an old version of apitrace--gl-frontend (3.0+git 20121018) which does not have replay command. There is also a apitrace-gl-tracers package in ubuntu; maybe that should be installed, too?
13:29 imirkin: jarnos: glretrace
13:30 imirkin: jarnos: or 'apitrace replay'
13:34 jarnos: imirkin, I tried to say that the latter does not work by my version of apitrace. glretrace gives segmentation fault (core dumped).
13:34 imirkin: sad
13:34 imirkin: i don't even know when apitrace 3.0 is from
13:34 imirkin: the current version is 7.1 or so
13:35 imirkin: although starting with 6.0 it requires Qt5 =/
13:35 imirkin: anyone around with a GM10x plugged in?
13:41 mooch: okay, i'm still trying to figure out how to get the win9x drivers
13:41 mooch: working
13:42 mooch: in my riva tnt emulator
13:44 jarnos: imirkin, I suppose it is from 2012-10-18 as the name suggests.
13:45 jarnos: imirkin, do you happen to know, if newer apitrace can replay the old trace?
13:46 imirkin: jarnos: it ought to
13:46 mooch: hey, can someone figure out how to trace all the accesses made to the nvidia card while windows is initializing the drivers?
13:46 mooch: i kinda need this info
13:47 imirkin: mooch: if you're using your emulated card, should just be a question of adding a few prints?
13:47 mooch: no, i mean, off a real car
13:47 mooch: *card
13:47 mooch: i don't have a real card, and i can't afford one
13:47 mooch: any card before g80 with win9x drivers should work tbh
13:48 imirkin: yes... riva tnt's are quite pricey :p
13:48 mooch: well, that and i have 0 dollars
13:50 mooch: imirkin: are there any real mode access registers other than 3d0 and 3d4 index 38?
13:50 imirkin: no clue
13:50 mooch: because win9x writes to index 38 repeatedly without writing to 3d0
13:52 jarnos: imirkin, repositories of the ubuntu release seem to have some "qt5" packages.
13:55 orbea: imirkin: qt5 doesn't require qt5, only the gui frontend does, I didn't find it very useful and it will happily build without the gui if there is not qt5
13:55 orbea: err apitrace doesn't require qt5
13:55 imirkin: oh right. good point.
13:55 imirkin: the frontend is quite useful for debugging
13:56 orbea: ah, i guess I haven't used it that much
13:56 orbea: btw I added your envytools to my tiny slackbuilds-git repo :P https://notabug.org/orbea/SlackBuilds-git/src/master/envytools
13:59 karolherbst: mhh one could think that some distribution care about packager and would make it easier to write such stuff :/
13:59 orbea: that is why I like distros with simple build scripts, slackware and crux are great examples
14:00 karolherbst: ... no?
14:00 karolherbst: how is that script simple=
14:00 orbea: most of it is a template
14:00 karolherbst: and you did forget the dependencies
14:01 orbea: In slackware you don't usually document dependencies unless its not included in the official slackware set of packages
14:01 karolherbst: that's even worse if it's a template
14:01 karolherbst: orbea: imagine, what would happen if there should be a compiler flag added globally for every package
14:01 karolherbst: orbea: I bet pcieaccess is in the official set?
14:01 orbea: Its meant for use with gcc
14:02 karolherbst: and libX11
14:03 orbea: libx11 is, still trying to figure out about pcieaccess, didn't complain about missing deps
14:03 karolherbst: lspci uses it
14:04 karolherbst: so I would assume it is there somewhere
14:04 orbea: libpciaccess?
14:04 karolherbst: yeah sounds about right
14:06 karolherbst: or you could simply look at the gentoo ebuild: https://github.com/gentoo-mirror/x11/blob/master/x11-misc/envytools/envytools-9999.ebuild The deps are listed there quite nicely depending on the feature you enable
14:06 karolherbst: ohh libxml2 too
14:07 orbea: libxml2 is in slackware current
14:08 orbea: as is vdpau
14:08 karolherbst: k
14:08 orbea: the envytools github page lists deps well too
14:08 karolherbst: ahh nice
14:08 orbea: gentoo does handle deps pretty differently than slackware
14:08 karolherbst: yeah, there is a high overhead for a feature not currently implemented :D
14:09 karolherbst: well maybe it comes in the future
14:09 karolherbst: anyway, I thought that list would be usefull though
14:10 orbea: anyways, my little notabug repo is not official by any means, I just find it handy to manage my few git scripts there
14:12 karolherbst: yeah I fully understand, it is just that maybe somebody finds it and if it doesn't work for whatever reasons, like it builds but a feature is not build because a dep is missing or whatever ;)
14:12 karolherbst: but maybe you could try to let it be upstreamed
14:14 orbea: if someone is running slackware current and have a full install it should work, even with my far than non-full install it works. If they removed something that it needs than I'm going to assume they know what they're doing
14:15 orbea: and im not sure anyone else is really making git based slackbuilds, SBo is only stable packages
14:15 karolherbst: well it would be still nice to have envytools packages :)
14:19 mawrick: imirkin, Got some traces for you if you want ? (did athe 3 examples in that link you gave me but was unable to !quit" the nvidia settings, so had to shutdown the pc, so that log file might be corrupt), but maybe it's good enough with the two others ? (glx gears and the xinit "sleep 10" ) ?
14:20 imirkin: yeah... you only have one perf level
14:20 imirkin: so as long as you have a valid trace
14:20 imirkin: it should be fine
14:20 imirkin: the trace should be on the order of 50MB
14:20 imirkin: (could be 30... could be 100... but if it's like 10K you did it wrong)
14:21 mawrick: 77 and 100 Megs
14:22 imirkin: that soudns right. xz -9 should get them down considerably
14:30 mawrick: Do you want all 3 files or ?
14:31 mawrick: (Packed them now in xv but packed them individualy)
14:31 mawrick: xz
14:31 imirkin: mawrick: i suspect just one would be enough
14:32 mawrick: Just send them to you here or ?
14:32 imirkin: mawrick: mmio.dumps@gmail.com
14:32 imirkin: mawrick: or upload somewhere
14:34 mawrick: Ok, I'l send them to that mail (I can send the 2 I know is ok - one with only xinit and one with glxgears
14:36 imirkin: just... please make sure they're compressed. and preferably send as individual files, not tar'd or something
14:36 imirkin: i.e. if you have foobar.log, just do xz -9 foobar.log
14:36 imirkin: which should make a foobar.log.xz and send that
14:38 mawrick: Yea, they are total 10 meg, comes in 2 individual files I did xz -z l* so they come as logfile01.xz and logfile02.xz
14:38 imirkin: excellent
14:39 imirkin: -9 makes it compress a lot better fyi
14:39 imirkin: [but slower]
14:39 mawrick: ahh, ok, never used xz before - but thanks for the info, the files are sent however....:)
14:39 mawrick: hehe
14:40 mooch: okay, does anybody know what crtc reg index 29 does?
14:40 mawrick: btw, I did have to startx first, then exit to console, stop sddm and shutdown nvidia drivers before starting the trace, but don't expect it have to be done via the "safe mode" when booting ?
14:41 imirkin: mawrick: ohhhh
14:41 imirkin: mawrick: no, it has to be from a clean boot
14:41 imirkin: mawrick: otherwise it'll already be at the right clock level
14:42 mawrick: ahhh, then it might be a problem, as it seem that it just "hanged" when I tried from clean boot
14:42 mawrick: (when I tried to startx
14:42 imirkin: it just takes a while
14:42 imirkin: give it a few minutes
14:42 imirkin: yeah i don't see any HWSQ scripts in there
14:42 imirkin: [which are used to reclock]
14:43 mawrick: ahh, ok, I'l do that then, I'l get back to you, sorry for the trouble :)
14:43 imirkin: no worries
14:44 mawrick: I'l do only the one trace with the glgears then
14:44 karolherbst: imirkin: I noticed that when an application has a high cpu load, I get some frame ordering issues :/
14:44 mawrick: brb
14:46 karolherbst: also it seems a bit to lag behind :/
15:10 mawrick: imirkin, Tried to give it roughly 10 minutes now, but there is only a black screen on the main display (it says it enters "power saving mode", but it stays on), also it seem to generate a log file, but I have to do a hard reboot - any other things I could try ?
15:11 imirkin: mawrick: nah... that file may be sufficient
15:11 imirkin: mawrick: just need to see the HWSQ script it generates
15:11 imirkin: [and some surrounding bits]
15:11 mawrick: also while doing lsmod § grep nvidia once I boot into recovery mode it says:
15:11 mawrick: nvidia <some numbers> 0
15:11 mawrick: drm <some numbers> 2 nvidia
15:11 orbea: mawrick: if you have another pc or laptop you can ssh in and look at logs or reboot it that way
15:11 imirkin: well, as long as nvidia doesn't *actually* load, it's fine
15:12 orbea: assuming it gets past init?
15:14 mawrick: I don't think it loads, I only come straight to shell, and second monitor does not "light" up....:)
15:14 mawrick: (nvidia that is)
15:14 mawrick: I'l send you the one I got and you can have a look
15:16 mawrick: Send to the email.
15:21 mawrick: imirkin, I can try again if the file doesn't contain what you need - but will have to be another day, it's getting late over here :)
15:21 imirkin: mawrick: thanks
15:22 imirkin: mawrick: it has some HWSQ scripts
15:22 imirkin: the values seem familiar
15:23 mawrick: Sound good :) - just give me a shout if you need anything else from this card if I can be of any help.
15:23 imirkin: RSpliet: http://hastebin.com/ijesuxakod.md
15:23 imirkin: RSpliet: so i guess 2d0 gets written even on G80, so much for my theory
15:24 imirkin: er wait, my theory was about da0, not 2d0.
15:28 imirkin: mawrick: oh also please provide your vbios... if you load nouveau it should be in /sys/kernel/debug/dri/0/vbios.rom, otherwise you can use nvagetbios from envytools
15:30 mawrick: I need to remove the nouveau blacklist then ? (or any other ways to do it ?
15:31 RSpliet: imirkin: that's a rather short script. No timings, no memory controller reconfiguration... nothing :-P
15:31 imirkin: blacklist just applies to what's loaded on boot
15:31 imirkin: RSpliet: are you sad about this? :)
15:32 imirkin: RSpliet: the full trace is at mmio.dumps
15:32 RSpliet: imirkin: if it's this simple, nouveau can most likely already handle it... but I don't think it's this simple
15:33 imirkin: RSpliet: i see just one read from MEM_TIMINGS
15:33 imirkin: [0] 299.279258 MMIO32 R 0x100228 0x0208080b PFB.MEM_TIMINGS_2 => { UNK28 = 0 | tCWL = 0x2 | UNK20 = 0 | 0x8080b }
15:33 imirkin: and that's all there is.
15:33 RSpliet: yeah. that's to obtain the tCWL
15:33 imirkin: [it also reads 100200 & co...]
15:34 RSpliet: I guess this card has an empty timing table then
15:34 RSpliet: think I added support for that case for pmoreaus G94
15:34 imirkin: this is a G80 :)
15:34 RSpliet: but... it doesn't handle emptiness in the rest of the table
15:35 RSpliet: correct, *a* G80 ;-)
15:35 imirkin: *the* G80 :p
15:35 imirkin: this is back before there was a ton of variations
15:35 imirkin: there are like 4 variations of G80
15:36 RSpliet: OEM vendors *could* use different RAM chips (although most likely all GDDR...3?, but from different vendors)
15:36 mawrick: Where can I find that nvagetbios? /I presume it's a tool for dumping the bios ?
15:36 RSpliet:prays GDDR2 away
15:36 RSpliet: mawrick: envytools
15:36 imirkin: RSpliet: G80 was DDR3-only
15:36 orbea: mawrick: https://github.com/envytools/envytools/
15:38 RSpliet: imirkin: I assume you mean GDDR3?
15:38 imirkin: RSpliet: check the vbios repo... mwk's nv50 barely does anything in the HWSQ, mupuf's doesn't even have anything
15:38 imirkin: RSpliet: yes.
15:38 imirkin: RSpliet: the whole "don't come up at full clocks" thing became a fad later
15:39 RSpliet: I know, earlier cards were simpler
15:40 RSpliet: I've seen Geforce 6xxx's with a few timing entries in it's tables (used)
15:41 RSpliet: I'm betting G84 is a bigger pita than G80
15:41 mawrick: imirkin, I'l have a look at that tomorrow (I presime there isn't a binary there that will run directly on debian ?) (it's getting late here....:) )
15:41 RSpliet: but since working backwards, I need to know which features not to use :-P
15:43 imirkin: mawrick: if you load nouveau, you can just get it out of sysfs
15:43 n7025: karolherbst: i am compiling now kernel 4.4-rc7. seems to work. what changes would you like to test?
15:44 imirkin: n7025: include the patch that skeggsb updated your bug with.
15:44 mawrick: can I load that now that the nvidia-drivers are loaded? (not quite sure how, without removing nvidia-driver and that blacklisting again (as you see quite new to Linux ;) )
15:44 n7025: imirkin: ah, have missed that. thanks. lets lest
15:44 imirkin: mawrick: no, you'd have to reboot
15:45 imirkin: mawrick: depends on the specific driver version, but starting with 330.x (iirc) nvidia started doing something to the display subsystem that we couldn't undo
15:45 imirkin: so nouveau loads fine but the screen never updates
15:46 mawrick: but how do I choose to load the noucau instead of nvidia now that nvidia is installed (can I edit parameters in grub for this or)?
15:47 imirkin: oh... dunno how your distro handles it
15:48 mawrick: Ok, but I can figure it out tomow, I'l get back to you with that vbios info
15:48 mawrick: or maybe I can load the live cd again ?
15:48 mawrick: then I should load nouveau
15:54 imirkin: skeggsb: if a pushbuf submit fails... what's the state of the pushbuf? do i just keep doing PUSH_DATA() and so on and submit again and it'll be fine?
15:54 imirkin: skeggsb: or do i need to recreate the nouveau_pushbuf object?
15:54 skeggsb: it *should* be like it never happened at all
15:54 skeggsb: on the hw side
15:55 skeggsb: hm, for libdrm it'll be in the same state as it was before the submit
15:55 imirkin: meaning what?
15:55 skeggsb: so yes, you probably need a way to reset that, or, just recreate it i guess
15:55 imirkin: ok
15:58 Mawrick: imirkin, I\v sent you the VBIOS on the email address
15:59 imirkin: awesome thanks
16:00 Mawrick: np :) - if you want traces/bios from the 8800 gtx I have laying around I can make that another day
16:00 imirkin: RSpliet: http://hastebin.com/uticelegof.xml
16:11 imirkin: hm perhaps that trace wasn't entirely successful -- i see it running silly hwsq scripts ad-infinitum
16:11 imirkin: not sure if that's normal
16:13 orbea: imirkin: how do I clock up with nouveau? I'm not getting very far searching for documentation
16:14 imirkin: orbea: boot with nouveau.pstate=1
16:14 imirkin: orbea: and then echo <the pstate> > /sys/class/drm/card0/device/pstate
16:14 imirkin: you can figure out a list of valid values for "the pstate" by cat'ing that file
16:15 orbea: oh, Im already booting with that, tahnks
16:16 imirkin: orbea: depending on your gpu and kernel version it may or may not hang the gpu
16:17 orbea: i compileda 4.3.3 kernel today, it still was having the video glitches with it
16:17 imirkin: ah, 4.3 doesn't have some of the patches iirc
16:17 imirkin: so don't go to the highest level, as that will definitely hang your gpu
16:18 orbea: should I have gone up to 4.4?
16:18 imirkin: but you could try the middle level
16:42 orbea: imirkin: this is my pstate file: http://dpaste.com/1CP84HM I tried 0a first, seemed to work, but video still hiccuped, then I tried 0d and got an immediate black screen and frozen keyboard, couldn't even ssh in...
16:47 imirkin: orbea: yeah, 0a would be the thing that works with 4.3
16:49 karolherbst: well I guess nouveau also sets the core voltage too low as with many other cards :/
16:49 karolherbst: especially on Ti cards this is a common problem
16:56 Tom^: is it possible to make the pstate file user editable?
16:57 Tom^: was thinking of keybinding them to F10 - F12 :p
16:57 imirkin: Tom^: with configfs sure, but there are a *ton* of parameters that would have to be adjusted
16:57 karolherbst: right
16:58 karolherbst: my only "safe" idea is to have an adjustable voltage offset
16:58 karolherbst: if you lower the voltage, you get higher cstates
16:58 Tom^: imirkin: i meant in a more unofficial way. ;)
16:58 karolherbst: if you raise it, you get slower cstates
16:58 Tom^: on my machine
16:58 imirkin: Tom^: sure, edit your vbios, and tell nouveau to load that instead of the one on your gpu
16:59 karolherbst: skeggsb: what do you think about an option to modify a voltage offset used for cstate voltage calculation?
17:00 orbea: Tom^: you could add the commands to your sudoers file...
17:00 karolherbst: or I could simply finish the dynamic reclock work :/
17:00 skeggsb: karolherbst: in a branch, sure. not keen on adding hacks to upstream code, where effort could be spent figuring out how to properly do something instead.. we have enough problems :P
17:00 skeggsb: karolherbst: i'm reviewing your various branches today btw
17:01 skeggsb: (as in, right now)
17:01 karolherbst: skeggsb: well I am pretty sure how all the kepler stuff works now by the way
17:01 karolherbst: skeggsb: the vbios contains cstate with clocks much higher the blob even uses
17:01 karolherbst: and those cstates have higher voltages, even about the "1.2V" limit of most cards
17:01 karolherbst: so with an offest you could move some cstates from being invalid to being valid for that card
17:01 karolherbst: or the other way around to increase stability
17:02 karolherbst: skeggsb: ahh nice thanks
17:02 Tom^: orbea: mmh indeed.
17:02 karolherbst: please the pcie stuff first :D
17:02 karolherbst: mhh or maybe the volt branch
17:02 karolherbst: this is fairly easy
17:02 skeggsb: or we can not do something that "shouldn't" be allowed, if the binary driver uses those clocks, we should instead figure out under what circumstances and implement that instead
17:03 skeggsb: if it doesn't, we probably shouldn't either
17:03 skeggsb: users who want to do otherwise can go through the effort to take that risk themselves
17:03 karolherbst: skeggsb: on the binary driver you can just increase the clcoks with coolbits enabled
17:03 karolherbst: as in an offset
17:03 karolherbst: which is basically the same
17:03 karolherbst: the voltage doesn*t get adjusted
17:04 skeggsb: i'm guessing it gets adjusted to the max allowed though, if it was lower?
17:04 karolherbst: so same voltage for 600MHz and 600 + 100MHz on the binary driver
17:04 karolherbst: skeggsb: nope, it just uses the same cstate + freq offset
17:04 karolherbst: +-135MHz for kepler
17:05 karolherbst: so if the max cstate would be 862MHz and you would get 1V, you would get 1V for 862MHz + 135MHz too
17:05 karolherbst: or 1V for 862MHz - 135MHz
17:05 karolherbst: or maybe 0.9V for 727+135MHtz
17:05 karolherbst: totally unsafe :D
17:06 skeggsb: yes, sorry, that's what i meant, max (valid, taking into account voltage limits) cstate voltage, not max voltage itself
17:06 karolherbst: so it may or may not crash your gpu
17:06 karolherbst: ahh right
17:06 karolherbst: yeah well, we could also allowed a clock offset
17:06 karolherbst: *allow
17:06 Tom^: imirkin: oh wait nouveau can load a vbios from the hdd, without flashing the card?
17:06 imirkin: Tom^: sure
17:06 Tom^: neat
17:06 imirkin: Tom^: nouveau.config=something
17:07 skeggsb: yes, allowing over-clocking, could be possible at some point.. but.. well, i would *strongly* prefer to not add any such things upstream until we make the defaults work properly
17:07 karolherbst: yeah
17:07 skeggsb: starting such work in a branch until that time would be fine though
17:07 karolherbst: mupuf and I planned to take care of the fsrm and power budget stuff first
17:08 karolherbst: and then my stable_kepler_reclocking branch and kepler should be good to go then
17:08 skeggsb: something i think would be a really good step is properly using the "voltage map" table values.. i suspect it'll be something similar to what gk20a does, but using the bios table coefficients instead of its hardcoded ones
17:08 karolherbst: ahh right
17:08 karolherbst: we have to choose the right voltage too
17:08 karolherbst: skeggsb: yes, the min value is too low for some cards
17:08 karolherbst: skeggsb: but I have something real nice for ya
17:08 skeggsb: well, we do the completely wrong thing
17:08 imirkin: Tom^: nouveau.config=NvBios=foo where foo gets loaded using request_firmware (i.e. it should live in /lib/firmware or whatever)
17:09 Tom^: imirkin: cool, gonna have to try fiddle with that
17:09 karolherbst: skeggsb: https://i.imgur.com/Q1lfK6d.png
17:09 karolherbst: bottom line is ming voltage
17:09 karolherbst: top line is max voltage
17:10 karolherbst: lines in the middle are the voltages used by the blob for each tempearture
17:10 karolherbst: nouveau would use the bottom line currently
17:10 skeggsb: yep
17:11 karolherbst: but I think I removed the data though :/
17:11 karolherbst: by accident
17:12 karolherbst: skeggsb: I am sure that if nouveau would use the middle value it would be enough already
17:12 karolherbst: skeggsb: anyway I plan to rewrite the nvkm_volt_map function in some way, not sure which one though
17:13 karolherbst: maybe nvkm_volt_map_min and nvkm_volt_map_max and then add a temperature parameter to nvkm_volt_map?
17:16 karolherbst: skeggsb: you could look over the stuff in this order: hwmon, fsrm_kepler, pcie_speed, pdaemon_counters.
17:16 karolherbst: the last one is a bit well, unstable :/
18:04 Tom^: karolherbst: i call this pstatectl. https://gist.github.com/anonymous/7d2335d06bcbd7e8aed6 now just to add to sudoers and its user editable! and fetchable with libnotify support! :P
18:05 karolherbst: :D
18:20 Tom^: priceless, all 3 states bound to F10 - F12, print current with F9.
19:05 Tom^: imirkin: this perhaps doesnt affect nouveau much but , TGSI_OPCODE_DP2A is initialized two times here, line 1521 and 1564 http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/nir/tgsi_to_nir.c#n1521
19:12 karolherbst: mhhh weird
19:12 karolherbst: I can't offload vdpau playback on the nvidia card :/
19:13 karolherbst: ohh right, I think can't do DRI3 offloading yet
19:13 karolherbst: ...
19:30 karolherbst: imirkin: okay, so vdpau on nouveau isn't as bad as I thought
19:31 karolherbst: a 4k video gives 100% load on the nvidia gpu, just so that it plays with 100% speed :/
19:34 karolherbst: skeggsb: I guess you have no clue why vdpau playback on nouveau is slower than on nvidia?
19:35 karolherbst: 14 vs 34 seconds :/
19:35 karolherbst: for a 14 second long 4k h.264 video
19:40 skeggsb: i haven't looked too in detail to the vdec code, but, if i had to guess off the top of my head: assuming clocks are equal, we likely don't pipeline stuff across the multiple channels very well
19:40 skeggsb: with implicit sync, the kernel doesn't make that easy, but, it is possible to do if userspace tries hard enough
19:41 skeggsb: (lie to the kernel about buffer usage, and manage any sync that's needed yourself)
19:41 karolherbst: mhh
19:41 karolherbst: well nvidia does the right thing somehow using the same kernel :D
19:42 skeggsb: nvidia have a different kernel module :P
19:42 karolherbst: right
19:42 karolherbst: anyway, the difference is rather big
19:42 skeggsb: yes, my first suspect would be that we stall the pipeline a lot more
19:42 karolherbst: mhh
19:42 karolherbst: any idea hot to detect those stalls?
19:42 skeggsb: second would be we don't use the ms* engines correctly
19:42 karolherbst: *how
19:43 karolherbst: sadly my kernel messes up while mmiotracing nvidia :/ so I can't create new traces
19:43 skeggsb: look for any places where a buffer passes from msvld -> mspdec -> msppp -> whatever we do scaling with (gr?), where the same buffers are are referenced
19:44 karolherbst: ohhh right, I could read the loud out for each engine seperatly
19:44 karolherbst: !
19:44 karolherbst: *load
19:47 karolherbst: uhhh
19:47 karolherbst: changing pdaemon counter config while heavly load hangs the gpu...
19:48 karolherbst: https://gist.github.com/karolherbst/89b87df34af676b4b6b7
19:48 skeggsb: that's... surprising
19:48 karolherbst: or
19:48 karolherbst: it was just vdpau
19:48 karolherbst: or something else
19:50 karolherbst: noooo, now I have a refcount of 1 on nouveau...
19:50 karolherbst: well does killing an x server might do that? :D
19:50 karolherbst: ahh systemd-logind has a ref
19:50 karolherbst: ...
19:53 karolherbst: ohh I guess it was the pmu messing up again
19:54 karolherbst: so PVLD nearly always generates 100% loads
19:59 karolherbst: skeggsb: PVLD is under too high load already
19:59 karolherbst: so I guess something is messed up there
20:48 karolherbst: https://gist.github.com/karolherbst/c9474cc16a1e93331cc6 can't that be somehow optimized
20:48 karolherbst: ?
20:48 karolherbst: like mov u32 $r4 $r63
21:51 karolherbst: okay
21:51 karolherbst: the 4k playback is totally broken
22:00 imirkin: karolherbst: please provide the full shader you got that from
22:00 karolherbst: NV50_PROG_DEBUG=1 ?
22:00 imirkin: ya
22:00 karolherbst: or another value
22:01 karolherbst: one thing I noticed though: if I have a 4k resoltuion through xrandr, it looks different
22:05 mupuf: karolherbst: the min and max values are misnomers, we already figured this out
22:05 karolherbst: ohh right
22:06 karolherbst: imirkin: added
22:06 mupuf: I did not think of checking out the code for the gk20a, sounds like a good idea!
22:06 imirkin: ?
22:07 karolherbst: imirkin: ohh I thought you read the bug?
22:07 karolherbst: ahhhhhhh
22:07 karolherbst: still in the bug
22:07 karolherbst: imirkin: https://bugs.freedesktop.org/attachment.cgi?id=120788
22:07 skeggsb: mupuf: yeah, if you look at the cvb coefficient tables, they look strikingly similar to what we see in the vbios..
22:07 imirkin: oh, i assumed the thing about the mov was unrelated
22:07 karolherbst: nah, it is the stuff I get while playing that 4k video through vdpau
22:08 karolherbst: just noticed that there might be optimization potential
22:08 karolherbst: search for 25: mov u16 $r9 0x0000 (8) in the attachment
22:09 imirkin: ohhhhh that is sad.
22:09 imirkin: i totally know why it happens too.
22:09 karolherbst: because the one is u16 and the other u32?
22:09 karolherbst: :D
22:09 karolherbst: or you mean why the playback is messed up
22:09 imirkin: the extra mov =]
22:10 imirkin: it gets inserted during RA
22:10 imirkin: ugh
22:10 karolherbst: :D
22:10 karolherbst: fun
22:11 karolherbst: finally I got xpra running again
22:11 karolherbst: other videos seems to play nice though
22:12 karolherbst: well I didn't test other 4k videos
22:15 karolherbst: imirkin: maybe nouveau just doesn't handle videos bigger than fullhd well enough?
22:15 imirkin: conceivable.
22:15 imirkin: could also be *that* video that's broken
22:16 karolherbst: it works cpu decoded
22:17 imirkin: sure
22:17 imirkin: i just mean it could be doing something odd to trip out the nouveau stuff
22:17 imirkin: and nothing to do with resolution
22:17 karolherbst: ahh k, will try with nvidia
22:17 imirkin: i'm sure it'll work
22:17 karolherbst: because i didn't checke the output there
22:17 karolherbst: ohh okay
22:17 imirkin: try a diff video with nouveau :)
22:17 karolherbst: all other videos are working
22:17 karolherbst: ahh you mean 4k videos
22:17 karolherbst: k
22:18 imirkin: nouveau has to-be-determined bugs in h264 decoding
22:18 imirkin: that 4k video could well be triggering one of them
22:19 karolherbst: okay
22:20 karolherbst: then I would reencode the video
22:22 imirkin: seriously? you can't find another 4k video?
22:23 karolherbst: well these are like 14 seconds videos
22:23 karolherbst: but now mplayer crashes :D
22:24 imirkin: karolherbst: http://cinemartin.com/cinec/hoid/samples/
22:24 imirkin: (search for avc)
22:24 karolherbst: ohh good, a small video
22:24 karolherbst: I only found big ones :/
22:25 imirkin: karolherbst: http://www.elementaltechnologies.com/resources/4k-test-sequences
22:25 karolherbst: yeah these I found
22:26 karolherbst: the cactus and the mobile one doesn't work
22:26 karolherbst: and the mb video crashes mplayer :/
22:28 karolherbst: hey, its nouveau fault :)
22:29 karolherbst: imirkin: https://bugs.freedesktop.org/attachment.cgi?id=120789
22:30 imirkin: ret = nouveau_bo_new(dec->bitplane_bo->device, NOUVEAU_BO_VRAM, 0, bsp_size, &cfg, &tmp_bo);
22:30 imirkin: p dec->bitplane_bo ?
22:30 karolherbst: 0
22:31 imirkin: inconceivable.
22:31 karolherbst: well :D
22:31 imirkin: :)
22:31 karolherbst: I could give you that video, it is just 900MB :D
22:31 karolherbst: (and 14 seconds long)
22:32 imirkin: well, we allocate bitplane_bo for everything *except* h264
22:32 imirkin: so at least that bit makes sense
22:32 imirkin: i dunno whose genius idea it was to use dec->bitplane_bo->device there
22:33 karolherbst: mlankhor1t :p
22:33 karolherbst: http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c?id=f6afed7076a6ef446dbec7cb10c8f8c60efafccd
22:34 imirkin: karolherbst: dec->client->device
22:35 imirkin: karolherbst: similarly in the place above it too
22:35 imirkin: or below it
22:37 karolherbst: okay, no crash anymore
22:38 imirkin: yay
22:38 karolherbst: all videos still broken
22:38 karolherbst: the crashing ones too
22:40 karolherbst: I will reduce the resolution until something changes
22:41 imirkin: karolherbst: yeah dunno what would cause the breakage
22:44 karolherbst: imirkin: same encoding options, just lower resolution: works
22:45 karolherbst: imirkin: 2500x1250 works too :)
22:46 imirkin: i'm guessing 2k vertical won't though
22:47 karolherbst: 3000x1500 also worked. k
22:47 skeggsb: what chipset are we talking here?
22:47 karolherbst: trying now 2k vert
22:47 karolherbst: nve6
22:47 imirkin: skeggsb: GK106
22:47 imirkin: skeggsb: should do 4k decoding afaik
22:47 karolherbst: blob plays at full speed
22:48 karolherbst: didn't check if the image was okay though
22:48 karolherbst: imirkin: 3900x1922 also works :D
22:48 skeggsb: what profile?
22:48 karolherbst: baseline 3.0
22:49 karolherbst: encoded with 3900x1900 and it works
22:49 imirkin: you can't go over 4096 width
22:49 skeggsb: o Maximum width or height: 128 macroblocks (2048 pixels) for feature
22:49 skeggsb: set C, 252 macroblocks (4032 pixels) wide by 255 macroblocks (4080
22:49 skeggsb: pixels) high for feature set D, 256 macroblocks (4096 pixels) for
22:49 skeggsb: feature set E.
22:49 skeggsb: 'D' is what's relevant here I believe
22:50 karolherbst: maybe ffmpeg messes up
22:50 karolherbst: imirkin: I have a working 3840x2018 video though
22:50 karolherbst: getting closer though
22:50 imirkin: 2018 != 2k
22:50 imirkin: 2k = 2048
22:51 karolherbst: well 4k is 3840x2160
22:51 karolherbst: ahhhh
22:51 karolherbst: that what you mean by 2k :D
22:51 imirkin: 2k vertical = 2048 vertical
22:52 karolherbst: wokring 3840x2082 one
22:52 karolherbst: but it doesn't fell so good anymore
22:53 karolherbst: speed is good though
22:53 karolherbst: well more or less
22:53 karolherbst: okay
22:53 karolherbst: that's a good video
22:53 karolherbst: the start is fine
22:54 karolherbst: playback seed also good
22:54 karolherbst: but after 3 or 4 seconds artifacts are starting to appear the the playback speed messe sup
22:54 imirkin: we're probably overflowing some buffer? dunno
22:54 karolherbst: it is better on 0f pstate
22:55 karolherbst: yeah
22:55 karolherbst: if the clock is a bit higher the stuff works better
23:06 karolherbst: maybe this stuff happens when the engine is overloaded?
23:17 karolherbst: imirkin: pvld load jumps pretty high when the artifects appear
23:17 karolherbst: 25% => 100%
23:17 imirkin: coincidence? :)
23:18 karolherbst: allthough nothing much happens otherwise
23:18 karolherbst: :D
23:18 karolherbst: now also testing with high profile 4.2
23:18 karolherbst: works with lower res wihtout issues
23:18 karolherbst: 3500x2000 is totally fine
23:19 karolherbst: well at 07 pstate that is
23:19 karolherbst: also it isn't related to the vert resolution
23:20 karolherbst: 3800x1800 also shows artefacts
23:20 imirkin: heh ok
23:20 karolherbst: even if a 3400x1800 won't
23:20 imirkin: bitrate probably... dunno
23:20 imirkin: anyways, i'm out
23:20 karolherbst: mhh
23:20 karolherbst: no
23:20 karolherbst: the bitrate is even higher at the start
23:20 karolherbst: and the issues come later
23:21 karolherbst: if the bitrate would be important, a 3.0 profile video shouldn't cause issues
23:22 imirkin: maybe inter_bo needs to be larger
23:22 karolherbst: mhhh
23:22 karolherbst: I could try that out
23:22 karolherbst: what shall I do?
23:22 imirkin: ret = nouveau_bo_new(screen->device, NOUVEAU_BO_VRAM,
23:22 imirkin: 0x100, 4 << 20, &cfg, &dec->inter_bo[0]);
23:22 imirkin: make that 16 << 20
23:22 karolherbst: in nouveau_buffer?
23:22 karolherbst: or wherE?
23:22 imirkin: nvc0_video.c
23:23 karolherbst: mhhhh
23:23 karolherbst: 100% playback speed
23:24 karolherbst: but xpra crashed
23:24 karolherbst: soo I didn't see what happend :D
23:24 karolherbst: yeah much better
23:24 karolherbst: testing the original files
23:25 karolherbst: I saw minor artefacts though
23:25 karolherbst: but nothing serious
23:25 karolherbst: so that helped
23:25 imirkin: cool
23:25 imirkin: i guess we need to size it based on... something
23:26 karolherbst: K-ness * 4 :D
23:26 imirkin:&
23:27 karolherbst: ohhh
23:27 karolherbst: right for 4k I might want to upclock the video engine :D
23:27 karolherbst: yep, with 0f, 100% palyback speed for full 4k video
23:28 karolherbst: now 4.2 high profile 4k :)
23:28 karolherbst: ohh wait
23:28 karolherbst: there is 5.2
23:30 karolherbst: k, no big deal :)
23:30 karolherbst: imirkin: so with that one fixed, nouveau should be able to play 4k videos :)