00:37 sobukus:is between rock and a hard place
00:38 imirkin: get some dynamite and blast your way out
00:38 sobukus: I'm trying to rebuild things with ati and nouveau drivers. xf86-video-ati requires glamor from xorg-xserver, but nouveau build breaks when it finds that glamor and tries to use it.
00:38 sobukus: nouveau_glamor.c:166:7: warning: implicit declaration of function ‘glamor_glyphs_init’ [-Wimplicit-function-declaration]
00:38 sobukus: nouveau_glamor.c:220:27: error: ‘GLAMOR_INVERTED_Y_AXIS’ undeclared (first use in this function) if (!glamor_init(screen, GLAMOR_INVERTED_Y_AXIS |
00:39 imirkin: just disable glamor during build
00:39 imirkin: i think you can do that... --disable-glamor
00:39 imirkin: maybe.
00:39 sobukus: imirkin: I had the zaphod setup working, but I got other trouble with Xorg (I removed *cough* hal just recently).
00:40 imirkin: xorg no longer uses hal since a while ago
00:40 sobukus: That's the thing: I don't see --disable-glamor; it's using it if it finds the glamor header.
00:40 sobukus: I also removed some *kits.
00:40 imirkin: yeah, just manually go in and remove the HAVE_GLAMOR define in config.h
00:41 sobukus: Anyway, xorg stopped configuring evdev input ... and I needed to rebuild some stuff because of gcc5 upgrade. So I figured I should do a consistent rebuild.
00:41 sobukus: imirkin: I guess I'll patch the configure.ac instead.
00:42 imirkin: that works too
00:43 sobukus: I've read at phoronix that glamor support has been removed actually, is that reverted?
00:44 imirkin: sobukus: no, just not pushed
00:47 sobukus: Ah, OK, so I'm avantgarde for disabling it;-)
00:47 imirkin: it wouldn't be enabled anyways for you
00:47 imirkin: unless you forced it on
00:47 sobukus: Well, it would have been built (if it didn't fail to build).
00:49 sobukus: But I broke something, either via *kit removal, kernel update (current stable 4.1.5), rebuilds … startx just hangs after adding dri devices.
00:50 sobukus: [ 2871.247] (II) xfree86: Adding drm device (/dev/dri/card1)
00:50 sobukus: [ 2871.247] (II) xfree86: Adding drm device (/dev/dri/card0)
00:50 sobukus: And long time nothing after that:-/
00:55 sobukus: It seems to work better when booting into linux 3.15.8 again.
01:12 sobukus: Ah! I found out why my input devices didn't work with xorg from git: That didn't install /usr/share/X11/xorg.conf.d/10-evdev.conf!
01:12 sobukus: dunno why
02:26 karolherbst: ohhh
02:28 karolherbst: okay next step: predicting refclock for target freq
02:44 karolherbst: either the blob downclocks memory even if you upclock in nvidia-settings or nouveau calculates the clocks slightly wrong
02:47 karolherbst: no, the blob is just stupid sometimes
02:47 karolherbst: I think their algorithm is just somehow right and we might be able to do better
02:48 karolherbst: 4008MHz and ~4058MHz using the same values for both PLLs
02:49 karolherbst: and clocks in between are calculated by nouveau either <4008 or >4008
02:49 karolherbst: anyway, i know now which refclocks are nice
02:50 karolherbst: start at N=26 and go until N=2b, then increase P by 1
02:50 karolherbst: for P=5 ; P<8
02:53 karolherbst: actually start at N=25
02:59 karolherbst: https://gist.github.com/karolherbst/a5dd956189a533ff3e6d#file-blob-values-for-pll-csv
03:05 karolherbst: really , my alsa is messed up ...
03:33 RSpliet: imirkin: did you not say something about Maxwell being too expensive for users to own them
03:33 RSpliet: ...
03:34 RSpliet: http://videocardz.com/57298/nvidia-geforce-gtx-950-coming-august-20th
06:27 ilios: Is there an way to extract cuda assembly from cubin file using envytools?
06:27 mwk: ilios: not yet
06:27 mwk: you're talking about an ELF cubin file, right?
06:28 ilios: Yes.
06:28 mwk: you have to manually figure out the start & size of the code section
06:28 mwk: then pass them to envydis as skip/size parameters
06:28 mwk: you can use readelf for the first step
06:28 ilios: thank you for suggestion!
06:29 ilios: Is readelf compatible with cubin ELF?
06:31 mwk: yes
06:31 mwk: well
06:32 mwk: compatbile enough
06:47 karolherbst: who has the most knowledge about DRI_PRIME frame synchronisation? mlankhorst?
06:52 ilios: Does anyone have suggestion to terminate CUDA kernel which got stuck in an endless loop? kill -9 and CTRL-C do not work.
07:23 karolherbst: mupuf: ping
07:24 karolherbst: imirkin_ RSpliet : https://github.com/karolherbst/nouveau/commit/90f819da64b90494cf3f71e65f17459aa45b22a7
07:24 karolherbst: this should work on all kepler gddr5 cards with crystal = 27MHz
07:25 karolherbst: its still hacky, but not limited to my card anymore
07:26 karolherbst: now I just need some cards to test this on :/
07:29 mupuf_: karolherbst: pong
07:30 mupuf: karolherbst: what is this?
07:31 karolherbst: stable 0f gddr5 reclock
07:31 karolherbst: at least for me
07:31 mupuf: what is the M table?
07:31 karolherbst: it may also work on other keplers and maybe there is a more serious issue
07:32 karolherbst: mhh, name is really badly choosen
07:32 karolherbst: ...
07:33 karolherbst: basically it calculates a refclock and a multiplier nearest to the requested clock
07:33 mupuf: and what is PLL2_CLK_TABLE?
07:33 karolherbst: PLL2_CLK_TABLE contains refclocks used by the blob
07:33 mupuf: ah
07:33 karolherbst: yeah
07:33 mupuf: interesting ideas
07:33 karolherbst: yeah
07:33 karolherbst: blob does the same somehow
07:33 karolherbst: usually the PLL2 is used for clocks below 2400MHz
07:34 karolherbst: and produces clocks like 800MHz or 1600MHz or whatever
07:34 karolherbst: the clocks for the lower pstates
07:34 karolherbst: but for 0f
07:34 karolherbst: this PLL produces much lower clocks
07:34 karolherbst: usually between 150MHz and 250MHz
07:34 karolherbst: and the scond PLL only multiplies
07:34 karolherbst: nouveau did this before: use old pstate state
07:35 karolherbst: and figure out a N/M/P combination to fit the requested clock
07:35 karolherbst: but
07:35 karolherbst: anything with M!=1 hangs the gpu
07:35 karolherbst: also this restricts produced clocks a lot
07:36 karolherbst: like I got 4050MHz for 0f instead of 4008
07:36 mupuf: so, PLL2.M should be 1?
07:36 karolherbst: yeah
07:36 karolherbst: blob always uses 1
07:36 mupuf: is it documented in the pll limits table in the vbios?
07:36 karolherbst: here is a nice table: https://gist.github.com/karolherbst/a5dd956189a533ff3e6d#file-blob-values-for-pll-csv
07:36 karolherbst: mhhh
07:36 karolherbst: we don't know yet
07:37 karolherbst: imirkin_ tried to find it, but I think he didn't find anything usefull
07:37 RSpliet: "we"? :-P
07:37 karolherbst: :p
07:37 karolherbst: imirkin_ helped me here :p
07:37 RSpliet: no, this is not in the PLL limits table to the best of my knowledge
07:37 karolherbst: no its not
07:37 karolherbst: I did this table
07:37 karolherbst: its the stuff the blob uses
07:37 karolherbst: not all of the values
07:37 karolherbst: but most of them
07:37 mupuf: nice
07:38 karolherbst: also the hex values are kind of a pattern
07:38 karolherbst: start with P=7 and N=25. increase N until 2a, then drop N to 25 and set P-1
07:38 karolherbst: don't know where to start or how to stop
07:39 karolherbst: but both 0x72501 and 0x52b01 are used by the blob
07:39 karolherbst: and like 95% of all values in between in that table
07:39 karolherbst: and the reflocks in that table are the PLL2_CLK_TABLE in the patch
07:40 mupuf: well, that looks like a good job
07:40 karolherbst: the blob algorithm used in the binary is buggy though. sometimes increasing the clock in nvidia-settings actually lead to lower clocks or much higher, or same pll values like other requested clocks
07:40 mupuf: want me to plug a kepler on reator for you to check your findings?
07:40 mupuf: I can plug too
07:40 karolherbst: yeah
07:40 mupuf: two
07:40 karolherbst: yeah
07:40 karolherbst: would be nice
07:40 karolherbst: both with gddr5 please :D
07:41 mupuf: hopefully both my nve6 and e7 are GDDR5
07:41 karolherbst: yeah
07:41 karolherbst: my patch only looks from the lower bound though
07:41 karolherbst: but thats not important yet
07:41 karolherbst: get 3961 instead of 4008, but so what
07:42 karolherbst: mhh
07:42 karolherbst: but it should have picked 3993 ...
07:42 karolherbst: checking
07:44 karolherbst: ohh half clocks, always forget this
07:45 mupuf: as long as you do not set any frequency higher that the one requested, you should be safe
07:45 karolherbst: yeah
07:45 karolherbst: but the blob sets a higher, too
07:45 karolherbst: I think I will improve that with a upper check too
07:45 karolherbst: don't know yet what makes more sense
07:46 mupuf: try to fix the current clock selection systeme instead of re-inventing yours too :)
07:46 karolherbst: well
07:47 karolherbst: the blob does something similiar as the patch does
07:47 karolherbst: its really jumpy with the reg vales and always searches for the nearest stuff
07:48 karolherbst: will be funny testing it on reator
07:48 karolherbst: what kind of gl applications are there installed?
07:50 karolherbst: mupuf: funy though, the blob doesn't mind if I set my mem clock to 8500MHz (4008 stock 0f and +4008 should be "max")
07:51 mupuf: karolherbst: xonotic is enough :D
07:51 karolherbst: okay
07:51 karolherbst: but I won't see anything :O
07:51 karolherbst: do you have a webcam or something? :D
07:51 mupuf: nope, sorry
07:52 karolherbst: I think vnc should be easier though anyway
07:52 mupuf: yeah, vnc could make sense
07:52 mupuf: i have a good connection
07:52 karolherbst: or X over ssh?
07:52 karolherbst: or vgl?
07:52 mupuf: X over ssh won't show you the desktop
07:52 karolherbst: ohh okay
07:52 mupuf: not that there is any
07:53 karolherbst: then maybe vgl
07:53 mupuf: same
07:53 karolherbst: don't know how vnc handles gl
07:53 karolherbst: yeah but with vgl I would be able to do some gl stuff
07:53 mupuf: well, X redirection should work, just terribly slow
07:53 karolherbst: yepp
07:53 mupuf: should be ok for visual checking of the result
07:53 karolherbst: but I think I won't need to see anything to test stability
07:54 karolherbst: dmesg will print stuff if something goes wrong
07:54 mupuf: nope, and you do not need to check for stability
07:54 mupuf: just make the same tables on those two cards
07:54 karolherbst: the tables are the same
07:55 karolherbst: checked alread reg values with two cards and the pll stuff is the same
08:03 mupuf: well, more checking is never a bad idea :D
08:03 karolherbst: right
08:03 mupuf: and if you oculd manage to generate the table, it would be nice
08:03 karolherbst: but then I need the blob running
08:03 karolherbst: and nvidia-settings :/
08:03 karolherbst: and have to set different mem clocks
08:05 karolherbst: mhh
08:05 karolherbst: but if I think about that, there is nothing card specific in there anyway...
08:05 karolherbst: this table should work for clocks up to 14GHz
08:06 karolherbst: and I don't use it, because calculating the pll is trivial enough
08:09 mwk: mupuf:
08:09 mwk: karolherbst:
08:09 karolherbst: ?
08:09 mwk: ping about PR 17
08:10 mwk: good to merge?
08:10 karolherbst: fine by me if the rename is fine
08:10 mwk: sure is
08:19 karolherbst: imirkin_: ohh mesa was built with -Og here :/
08:19 karolherbst: but this shouldn't change performance that much
08:19 mupuf: unless you were cpu limited
08:21 karolherbst: which I doubt a little, but who knows
08:21 mupuf: you can use the gallium HUD to check it out
08:24 karolherbst: yeah I want to find performance problems anyway. got like 62% blob performance in unigine heaven :/
08:24 karolherbst: and what about those kepler cards?
08:29 mupuf: what do you mean?
08:33 karolherbst: I thoguht you wanted to check if these are gddr5 cards
08:33 mupuf:is still at wor
08:34 karolherbst: ahhh okay
08:34 karolherbst: didn't know that
08:34 karolherbst: what cards are ther ein currently?
08:34 karolherbst: a fermin or tesla one?
08:34 karolherbst: *fermi
08:34 mupuf: well, it seems like I am always out after work anyway. I guess I am enjoying the summer while it lasts
08:35 mupuf: IIRC, it is a GM107 and G80
08:36 karolherbst: mhh
08:36 karolherbst: was thnking ahout to check which cards do have these: https://github.com/karolherbst/envytools/commit/0e05adf392ef3a564a62271ccbc690a703b94cb5
08:37 mupuf: well, how about checking that here? http://ng.0x04.net/~mwk/scans/
08:37 mupuf: mwk: ^^ this server seems down in some way
09:18 karolherbst: okay, no change with optimies mesa and without debug support
09:18 karolherbst: *optmised
09:18 karolherbst: still only 62% blob performance
09:19 karolherbst: some nice tricks how to get more performance out of mesa :p
09:21 karolherbst: ohh wait
09:22 karolherbst: mupuf: did you ever found any reg related to gpu load? Or any idea how the blob calculates loads?
10:27 mwk: mupuf: that server has been decomissioned, look at http://0x04.net/~mwk/scans/
10:28 mwk: perhaps I should set up a redirect...
10:36 karolherbst: nice thanks
10:37 karolherbst: its already in PTHERM-CF
10:38 karolherbst: mwk: do you have a fermi card running?
10:43 karolherbst: nope I was wrong
10:43 karolherbst: D9 is the first one
11:00 Hauke: imirkin_: ok I will send ben a mail
11:01 Hauke: there are some other checks like if (pixel_lock > 165MHz) in the code they probably also have top be changed for other grahics cards
11:11 karolherbst: well I guess I have to check temp to get gpu load :D
11:17 karolherbst: my gpu fan is surprisingly good
11:18 imirkin_: Hauke: he came back from vacation, and i mentioned your patches to him, hopefully he'll have a gander. he's in a middle of a pretty significant rewrite, so you should expect delays
11:18 karolherbst: how "hot" is 77°C with default clocks?
11:18 imirkin_: it's toasty
11:19 imirkin_: you don't have a dedicated fan, so it's all system controlled...
11:19 RSpliet: mmm, 77 is warm in a laptop, but the GPU can handle it
11:19 karolherbst: I have a dedicated gpu fan
11:20 karolherbst: or what do you mean
11:20 imirkin_: karolherbst: are you sure?
11:20 karolherbst: I have two fans, yes
11:20 imirkin_: normally there is no dedicated fan on laptops
11:20 karolherbst: I opend the laptop many times
11:21 imirkin_: is that fan connected to the gpu though
11:21 karolherbst: mhhh
11:21 imirkin_: or the system fan control thingie?
11:21 karolherbst: don't really know
11:21 RSpliet: wow, that laptop has it's own fanclub... *bah dum*
11:21 karolherbst: its getting louder when the gpu gets hotter
11:21 karolherbst: and it turns off, when the gpu is off
11:21 imirkin_: ok, that means something is working
11:21 imirkin_: let's not worry about what ;)
11:22 karolherbst: 80°C now, but unigine is using 100% gpu :D
11:22 karolherbst: want to have the maximum value and see how high nouveau pushes the card
11:22 imirkin_: oh, yeah, unigine will put some load on the thing
11:22 imirkin_: that temp seems low then :)
11:22 karolherbst: and if the card is like 5°C cooler wich neaveau, then something should be wrong
11:22 karolherbst: yeah, its under full load
11:22 imirkin_: i thought you meant idling with base clocks
11:22 karolherbst: no ...
11:23 karolherbst: then I would be worried
11:23 karolherbst: idle is around 50
11:23 karolherbst: but the laptop is pretty well done in general
11:23 karolherbst: cpu and gpu have different heatsinks and fans
11:24 karolherbst: okay, 80°c seems to be the max value
11:24 RSpliet: well done indeed if it's at 80 degrees, not medium rare; keep in mind that nouveau temperature management is limited
11:24 RSpliet: the blob would clock down when it gets too warm, nouveau doesn't do that
11:24 karolherbst: yeah I know, but this is for performance testing
11:25 karolherbst: I will clock up now and see how it goes
11:25 karolherbst: what is a "critical" value?
11:25 karolherbst: 110?
11:25 RSpliet: your vbios would know
11:25 karolherbst: nvidia-settings shows only yellow bars
11:25 karolherbst: so I think I am fine
11:26 imirkin_: critical is when the gpu automatically calls the fire department
11:27 karolherbst: what?
11:27 karolherbst: I clocked at +125 and the fan is getting even louder?
11:28 karolherbst: how insane
11:28 RSpliet: imirkin_: well, they'll drop that feature now that they've sold their modem department
11:29 karolherbst: mhh
11:29 karolherbst: the gpu got unstable
11:29 karolherbst: but reached only 85°C
11:30 RSpliet: mupuf: did you not RE the temperature table for kepler?
11:30 kb9vqf: karolherbst: 85C is only 13C below the max temp
11:30 karolherbst: this was with blob
11:30 RSpliet: have you not implemented that in nvbios?
11:31 karolherbst: kb9vqf: well I clocked my gpu core from 862 max to 997 max
11:31 kb9vqf: karolherbst: BTW did you get anywhere on the reclocking?
11:32 karolherbst: yes
11:32 kb9vqf: coold
11:32 karolherbst: I have a patch I would like to test on other cards
11:32 kb9vqf: still running nouveau here, unlike the blob my machine didn't lock up overnight
11:36 karolherbst: yep, 81°C max at stock clocks
11:36 karolherbst: now nouveau
11:36 tobijk: isnt the a bit high?
11:36 tobijk: *that
11:36 kb9vqf: tobijk: No
11:36 karolherbst: at full load?
11:37 kb9vqf: Kepler is rated to 98C IIRC
11:37 kb9vqf: and a lot of the other cards can safely reach 105C
11:37 tobijk: well at stock clocks aka boot clocks? :/
11:38 karolherbst: 0f clocks
11:38 kb9vqf: tobijk: That depends on the laptop's cooling strategy mostly
11:38 tobijk: ah 0f clocks :)
11:38 karolherbst: with +135MHt core clocks I got to 85°C
11:38 karolherbst: sadly I can't go higher
11:39 tobijk: never measured mine ;-)
11:39 karolherbst: okay, here we go
11:40 tobijk: should be the same if you drive it with the same voltage...
11:40 karolherbst: sure?
11:40 karolherbst: but I think blob may revolt
11:41 tobijk: meh
11:41 karolherbst: I can only change max clocks, the blob does everything else
11:41 karolherbst: but if you think about it: 862 is stock 0f and going up to 997 is pretty intense sometimes
11:42 karolherbst: imirkin_: somethins is really wrong
11:42 karolherbst: I mean like really really
11:42 imirkin_: with 8x msaa? i was able to repro on my fermi btw
11:42 imirkin_: *no clue* why it happens
11:42 karolherbst: nice
11:43 karolherbst: nouveau only hits 70°C
11:43 imirkin_: but i took the opportunity to look at some of the dumb msaa test failurse we have
11:43 imirkin_: and might rewrite the 3d blitter
11:43 imirkin_: now that i understand wtf it's doing
11:43 imirkin_: unlike last time i tried fixing it
11:43 karolherbst: because of the video?
11:43 karolherbst: or just because more knowledge
11:44 imirkin_: more knowledge
11:44 karolherbst: okay
11:44 karolherbst: somehow nouveau doesn't put the card under full load
11:44 tobijk: i hoped for an awesome video :D
11:44 karolherbst: 10°C cooler than blob
11:44 karolherbst: tobijk: wait there is one
11:44 imirkin_: like i understand how GL (and the hw) works now. that makes it a lot more apparent what it's doing.
11:45 karolherbst: tobijk: http://www.filebin.ca/2CPAnOjuzVUh/out.mp4
11:45 tobijk: imirkin_: if you got time later, you can review my glsl patch i have send a few min ago
11:45 karolherbst: imirkin_: any idea why nouveau doesn't put enough pressure on the card?
11:45 karolherbst: 10°C is a lot
11:46 karolherbst: may explain perf difference too
11:46 karolherbst: could increase voltage and see how it goes
11:49 tobijk: karolherbst: nice effects you got there in Heaven :D
11:49 tobijk: 8x MSAA?
11:49 karolherbst: yes
11:50 tobijk: i can even repro it :/
11:50 karolherbst: okay
11:51 karolherbst: I increases voltage like the blob did
11:51 karolherbst: still no heat
11:51 karolherbst: stuck at 73 now
11:51 karolherbst: still 8 °C to go
11:52 imirkin_: push!
11:52 imirkin_: harder! faster!
11:52 karolherbst: how?
11:52 karolherbst: I didn't implement overclocking yet :D
11:52 tobijk: maybe they are batching up commands and get better througput that way
11:52 karolherbst: maybe
11:52 imirkin_: if you want to do it like mupuf does, get a hair dryer. should get you the last 8C and beyond
11:52 karolherbst: :D
11:52 tobijk: ~_~
11:53 Yoshimo3743: is heat a good thing? or are you lacking performance as well?
11:53 karolherbst: gpu boost 2.0 maybe?
11:53 karolherbst: Yoshimo3743: nouveau compare to blob
11:53 karolherbst: I get only 62% perf in unigine
11:53 Yoshimo3743: then the heat isn't necessarily a bad sign
11:53 karolherbst: the fan isn't as loud as with te blob too
11:53 karolherbst: I am sure it is
11:54 karolherbst: under unigine the gpu is under full load
11:54 karolherbst: so the heat goes up a lot
11:54 karolherbst: under nouveau... not so much as it seems
11:54 tobijk: have you reclocked the link? :>
11:54 karolherbst: yes
11:54 karolherbst: everything on max
11:55 tobijk: mhm
11:55 karolherbst: maybe nouveau has a different bottleneck
11:55 karolherbst: nvidia said something about 10% pcie link usage
11:55 karolherbst: so I don't think this is an issue on nouveau either
11:55 tobijk: karolherbst: one is the compiler for sure
11:55 karolherbst: but gpu load was at 100%
11:55 karolherbst: well
11:55 tobijk: but imirkin_ is working on it day and night :D
11:56 karolherbst: if we just assume the driver pushes stuff fast enough into the gpu
11:56 imirkin_: nouveau's entirely untuned for this stuff
11:56 karolherbst: then even with a bad compiler the gpu should produce more heat
11:56 imirkin_: i'm pretty happy it draws triangles
11:56 imirkin_: well, with a bad compiler you get a ton of stalls
11:57 karolherbst: ohhh
11:57 karolherbst: bad istruction ordering?
11:57 tobijk: we fetch more thnigs out of vram
11:57 karolherbst: I see
11:57 karolherbst: so higher mem clock may help
11:57 karolherbst: I can do that
11:58 imirkin_: there are also various quality things on texturing
11:58 tobijk: karolherbst: plus we may have more instructions in the shader programs compared to nvidia as we fail to collapse them as effectively
12:00 karolherbst: I hope nouveau is fine with a high mem clock...
12:02 tobijk: lets melt the mem off the board :D
12:02 karolherbst: its just +500
12:03 tobijk: so ~10%? mhm
12:03 karolherbst: yeah
12:04 karolherbst: doesn't change much
12:04 karolherbst: like nothing
12:05 tobijk: i'd guess around 1% improvment
12:05 karolherbst: if vram is the bottleneck?
12:05 tobijk: but that is just a made up alue
12:05 Hauke: imirkin_: thanks
12:05 tobijk: we may fetch more, but only every x cycles
12:05 karolherbst: the difference is really high
12:06 karolherbst: tobijk: 7 fps at 0a
12:06 karolherbst: 12 fps at 0f
12:06 karolherbst: core clock stays the same
12:06 karolherbst: mem goes from 1620 to 4570 now
12:07 karolherbst: did I just reclock my memory to a custom value with nouveau? ...
12:08 tobijk: well you'd have to tell us! :D
12:09 karolherbst: ohh at 73 now
12:09 karolherbst: mhh
12:09 karolherbst: I was there before
12:09 karolherbst: silly me
12:10 karolherbst: yep, nothing changes
12:10 karolherbst: kb9vqf: up to trying out a patch?
12:11 karolherbst: or does anybody else want a kepler gddr5 pstate 0f stuff patch?
12:12 karolherbst: would be nice to test a live desktop system with that
12:12 tobijk: let me just exchange my ddr3 to gddr5, sec ;-)
12:12 karolherbst: ice
12:12 karolherbst: nice
12:12 karolherbst: which card?
12:12 tobijk: nve7
12:13 karolherbst: okay
12:13 tobijk: but i can already go to 0f
12:13 karolherbst: stable?
12:13 tobijk: mh mostly, sometimes it hangs after some time
12:13 karolherbst: okay
12:14 karolherbst: we should try one thing though before
12:14 tobijk: but it got waaaaaaaaay better, when i started here it did hang instantly :>
12:14 karolherbst: I need the pstate output after switching to 0f
12:14 kb9vqf: karolherbst: I'd be willing to give it a go this evening
12:14 karolherbst: mhh
12:14 karolherbst: this evening means?
12:15 karolherbst: I don't know where you live ;)
12:15 kb9vqf: ah, in 6 hours or so
12:15 karolherbst: then I should sleep alredy
12:15 karolherbst: "should"
12:15 tobijk: karolherbst: cant you just cat pstate after reclocking?
12:15 tobijk: is that too slow? :O
12:16 karolherbst: ?
12:16 karolherbst: I would like to now your mem clock after 0f change
12:16 karolherbst: and what your "stock" mem clock should be
12:16 kb9vqf: that's easy: stock here was 6008
12:16 karolherbst: like for me it should be 4008 but nouveau clocked to 4050
12:17 karolherbst: tobijk: what is too slow?
12:17 tobijk: never mind
12:17 tobijk: my clocks with ddr3 max out at 1800
12:17 karolherbst: ohh
12:17 karolherbst: mhhh
12:18 karolherbst: this is interessting
12:18 karolherbst: does ddr3 with nouveau cap at 2.4GHz or something?
12:18 tobijk: and i did just hang my card again
12:18 karolherbst: :D
12:18 karolherbst: tobijk: try this: https://github.com/karolherbst/nouveau/commit/2188c57c321f0dc73de1e7db323c70fc566b8efd
12:19 kb9vqf: karolherbst: can you get me the patch so I can start the kernel compile?
12:19 karolherbst: .patch
12:19 karolherbst: but I wouild need dmesg after 0f change
12:19 kb9vqf: oh wait, that's the link above, yes?
12:19 tobijk_: and the rest of my system :/
12:19 karolherbst: not that something messes up
12:20 karolherbst: ...
12:20 karolherbst: talking about a lot more stable
12:20 karolherbst: if you are up to: https://github.com/karolherbst/nouveau/commit/2188c57c321f0dc73de1e7db323c70fc566b8efd
12:20 karolherbst: but spoiler ahaead
12:20 karolherbst: if anything is strange
12:20 tobijk_: reclocking while the card sleeps is a major problem for me ;-)
12:20 karolherbst: crystal clock or PLL values or anything
12:20 karolherbst: it may clock to an insane value
12:20 karolherbst: I highly doubt that
12:20 karolherbst: but who knows
12:20 kb9vqf: well, I'll stand by on the reset button
12:21 kb9vqf: easy enough
12:21 karolherbst: wait I give you something first
12:21 kb9vqf: but will be ~6 hours before I can test that
12:21 karolherbst: the kernel will print stuff like that after swithcing to 0f: https://gist.github.com/karolherbst/54fc4395b21e00c76f45
12:21 karolherbst: clk * N shouldn't be that much off
12:22 karolherbst: from what was requested
12:22 kb9vqf: ok, will save dmesg output for you
12:23 karolherbst: also a cat pstate after the change should tell you the current clock
12:23 kb9vqf: karolherbst: I'm going to apply that to a stock 4.1.3 kernel; will that work?
12:23 karolherbst: and if this is fine, then its usually save to proceed
12:23 karolherbst: should work
12:23 kb9vqf: ok
12:23 karolherbst: but you need to cd ito the nouveau directory
12:23 karolherbst: I think
12:23 kb9vqf: yeah, I know that ;-)
12:23 karolherbst: I use the nouveau tree though
12:24 karolherbst: tobijk_: your status?
12:24 tobijk_: karolherbst: btw i dont think that patch changes anything for me, ddr3 reclock is fine
12:24 karolherbst: ahh
12:24 karolherbst: yeah
12:24 karolherbst: I meant gddr5
12:24 tobijk_: 0f: core 270-708 MHz memory 1800 MHz AC DC *
12:24 tobijk_: sad :D
12:24 karolherbst: :D
12:24 karolherbst: yeah
12:24 karolherbst: this is sad
12:25 karolherbst: mhh
12:25 karolherbst: I thought you had a gddr5 card
12:25 karolherbst: I guess I didn't saw the joke
12:25 tobijk_: i tried to make a joke, seems that was not good enough...
12:25 imirkin_: kb9vqf: fyi the reclocking situation with actual desktop gpu's is trickier, we don't do something quite right with display properly
12:25 karolherbst: yep, it may not change anything
12:26 karolherbst: maybe its a little bit more stable
12:26 karolherbst: maybe its a lot more stbale
12:26 karolherbst: who knows
12:26 kb9vqf: imirkin_: And this something that's done wrong doesn't affect the 0x7 --> 0xa transition?
12:26 imirkin_: kb9vqf: apparently not as much
12:27 imirkin_: perhaps it switches something internally to get to the speeds that 0f needs
12:27 imirkin_: ben was talking about futzing with the isohub
12:27 kb9vqf: what is the isohub?
12:29 imirkin_: some sort of hub for memory transactions presumably
12:29 imirkin_: isochronous or so? dunno.
12:29 imirkin_: he called it that, i just repeat :)
12:30 kb9vqf: ok, I think I might know approcimately the technology in play
12:30 kb9vqf: *approximately
12:30 RSpliet: ah, yes, that's the them
12:30 RSpliet: *term
12:30 RSpliet: I think I caught Andy Ritger calling it that
12:30 RSpliet: and I recall the NISO-hub being the line buffer...
12:30 RSpliet: (non-iso hub)
12:32 kb9vqf: well, it's still woth a try. if things are being clocked wrong it won't work at all, and I'd be happy with just being able to increase performance to 0xf once after bootup :-)
12:32 kb9vqf: (workstation power envelope is much different than laptops)
12:32 imirkin_: kb9vqf: well, ben said he was able to clock into 0f on boot
12:32 imirkin_: just not after all the display stuff was going
12:33 kb9vqf: so while the card is still in VGA mode then?
12:33 imirkin_: yeah
12:40 karolherbst: maybe he got lucky
12:40 karolherbst: wait
12:40 karolherbst: ...
12:40 karolherbst: of course
12:41 karolherbst: imirkin_: any idea what refclk = fuc->mempll.refclk;might be in that situation?
12:41 imirkin_: err... huh?
12:41 karolherbst: maybe it was so low, that M=1 for ben at boot
12:41 imirkin_: no idea
12:41 karolherbst: imirkin_: https://github.com/karolherbst/nouveau/commit/2188c57c321f0dc73de1e7db323c70fc566b8efd#diff-c55b594c4bf4b9ffe42d3a48aca8f90aL973 this thingy
12:41 karolherbst: this is the critical part in my patch
12:41 imirkin_: he might also have had more customness going on when doing this
12:41 karolherbst: yeah
12:42 karolherbst: but usually the issue was that the pstates had a high refclock
12:42 kb9vqf: well, I'll test and report back
12:42 kb9vqf: kernel is compiling now
13:22 everym4n: what's the good practice to check monitor turned on or off? i found some tool 'ddccontrol' which gives info about monitor, only if monitor turned on, but seems it's complicated tool not for just monitor power check, maybe anyone know some nouevau user space tool
13:25 imirkin_: everym4n: unfortunately there's no particularly reliable way
13:25 imirkin_: to generically check that
13:48 everym4n: imirkin_: what's about unreliable ways except 'ddccontrol'?
13:48 imirkin_: everym4n: well, you could inspect the dpms state :)
13:49 imirkin_: i.e. the driver-side dpms state
13:50 imirkin_: everym4n: i.e. grep . /sys/class/drm/card*-*/dpms
14:20 everym4n: no luck, gives 'On' in both states, seems it depends on interface state not on monitor power state
14:20 imirkin_: like i said -- unreliable ;)
14:46 RSpliet: shakesoda: iirc you were the one with the GDDR3 GPU right?
14:47 shakesoda: RSpliet: yes
14:47 RSpliet: if so, would you mind trying to reclock with this kernel : https://github.com/RSpliet/kernel-nouveau-nv50-pm
14:47 RSpliet: I made a few changes related to memory voltage settings based on the findings from your card
14:48 RSpliet: and I'm keeping my fingers crossed that this will make things more stable ;-)
14:49 RSpliet: it's untested so far, I'll make sure to roll a kernel of my own too to see what I can verify :-)
14:50 RSpliet: erm... I'll do that tomorrow I mean, look at the time! :-D
15:13 imirkin_: skeggsb: any idea why memory doesn't reclock on my GK208? the relock "succeeds", but memory stays at 800mhz instead of going up to 2ghz. it's ddr3 vram.
15:14 karolherbst: imirkin_: gpu clock changes I assume?
15:14 imirkin_: karolherbst: core goes up, yea
15:14 imirkin_: karolherbst: but memory stays put
15:15 karolherbst: let me say it this way: nouveau won't reclock the gpu core if not the exact requested voltage is found. Maybe the same goes for memory
15:15 karolherbst: but it should print so on demsg :/
15:15 imirkin_: no error prints
15:15 imirkin_: everything's all nice and perfect
15:16 imirkin_: except speed doesn't really go up and i see this in pstate: http://hastebin.com/okeboqaqos.mel
15:16 karolherbst: imirkin_: nvkm_pstate_prog
15:16 karolherbst: you see the silent fail?
15:17 karolherbst: you could check what ret = pfb->ram->calc(pfb, khz); returns
15:17 imirkin_: cstate changes though
15:17 karolherbst: yeah
15:17 karolherbst: this is below
15:17 imirkin_: oh, if calc fails?
15:17 karolherbst: "return nvkm_cstate_prog(clk, pstate, 0);"
15:18 karolherbst: this is mem only part
15:18 imirkin_: iirc i looked at that path
15:18 karolherbst: mhh
15:18 karolherbst: ret = 0 ?
15:18 imirkin_: sec
15:18 imirkin_: no, i meant i read the code
15:18 RSpliet: imirkin_: have you verified whether GF100_ram_create() doesn't fail?
15:18 karolherbst: wait, I thought reclocking doesn't work on fermi? :D
15:19 imirkin_: RSpliet: pretty sure that'd lead to a ton of fail all over
15:19 karolherbst: or was it this just urban legend
15:19 imirkin_: RSpliet: the function is shared by fermi and kepler
15:19 karolherbst: I assume ret = pfb->ram->calc(pfb, khz); returns not 0
15:19 karolherbst: and mem clock fails just silently
15:20 RSpliet: imirkin_: it's also the first silent failure on gk104_ram_ctor
15:20 karolherbst: or ret = pfb->ram->prog(pfb); fails
15:20 karolherbst: who knows
15:20 imirkin_: well, looking at gk104_ram_calc
15:20 imirkin_: gk104_ram_calc_data yells if it fails
15:20 karolherbst: okay
15:20 imirkin_: i doubt ram_init fails
15:20 karolherbst: imirkin_: ohhh
15:20 karolherbst: fermi or kepler?
15:20 imirkin_: kepler.
15:20 imirkin_: GK208
15:21 karolherbst: okay
15:21 imirkin_: DDR3
15:21 karolherbst: mhh
15:21 imirkin_: so if either nvkm_sddr3_calc or gk104_ram_calc_sddr3 fail, then it's silent
15:21 karolherbst: gk104_clk_calc
15:21 imirkin_: unless they yell
15:22 imirkin_: nvkm_sddr3_calc only fails silently on old vbios
15:22 imirkin_: oh actually hm
15:22 imirkin_: also on unexpected timing params
15:22 imirkin_: that could be a thing
15:22 imirkin_: i should turn debug on
15:22 karolherbst: yeah
15:22 karolherbst: there are some areas with silent fails there
15:23 karolherbst: I should add my PWM voltage thingy ...
15:25 imirkin_: [785335.128972] nouveau D[ CLK][0000:01:00.0] setting performance state 1
15:25 imirkin_: [785335.129018] nouveau D[ PMU][0000:01:00.0] Exec took 1ns, PMU_IN 00000000
15:26 imirkin_: that's all i see
15:26 karolherbst: shall I use debug?
15:27 karolherbst: imirkin_: thats what I get : https://gist.github.com/karolherbst/153387b87fcd4896fb37
15:28 RSpliet: imirkin_: that would imply an empty script
15:30 imirkin_: RSpliet: well that corresponds nicely to nothing actually happening ;)
15:30 karolherbst: :D
15:31 RSpliet: imirkin_: yes, but I expected it to not try to execute when _calc fails
15:32 imirkin_: right, so calc succeeded
15:35 karolherbst: imirkin_: I guess something is mssing for you and the pmu does nothing at all :p
15:35 karolherbst: like voltage doesn't work for me too
15:36 imirkin_: RSpliet: http://hastebin.com/ijaziqaxet.css
15:36 imirkin_: should i be worried that it doesn't go up to 2GHz?
15:36 karolherbst: *2
15:37 karolherbst: imirkin_: my highet entry is Entry 3: 2201 MHz - 3500 MHz
15:37 karolherbst: nouveua still clocks even to 4500
15:37 karolherbst: software is messy with ddr ram
15:37 RSpliet: imirkin_: hmm, it's actually very likely that calc failed
15:37 karolherbst: sometimes it uses the doubled clock, sometimes it does not
15:38 RSpliet: as nvkm_memx_fini tells you the execution time even if the "exec" bool is false, what happens if you call gk104_ram_tidy
15:39 imirkin_: oh wait
15:39 imirkin_: i added some code locally
15:39 imirkin_: but i'm not runnign that module
15:39 imirkin_: nvkm_sddr3_calc actually has a bunch of silent outs
15:39 imirkin_: heh
15:40 karolherbst: told ya
15:40 RSpliet: imirkin_: which card is this? is the vbios in nvidia_vbios?
15:40 RSpliet: "gk208", never mind
15:41 karolherbst: silent fails are the best
15:41 imirkin_: [786258.531558] nouveau D[ PFB][0000:01:00.0][0x00000000] unexpected timing param: CL: 5, CWL: -22, WR: -22
15:41 imirkin_: [786258.531559] nouveau E[ PFB][0000:01:00.0] calc_xits: -22
15:41 imirkin_: there ya go
15:41 imirkin_: i think 22 = ENOSYS?
15:41 RSpliet: it's "not found in the lookup tables", for sure :-P
15:42 imirkin_: or EINVAL
15:42 imirkin_: yea
15:42 imirkin_: well phooey
15:42 RSpliet: it... is a little worrying that your timing mapping table doesn't go beyond 1200
15:42 imirkin_: what do i look at to find (a) the values that weren't found
15:43 imirkin_: and (b) what values to set them to
15:44 imirkin_: this is the timing table btw: http://hastebin.com/ajawisaxad.avrasm
15:45 imirkin_: i'm really weak on what maps to what...
15:45 karolherbst: RSpliet: it should be fine
15:45 karolherbst: don't forget multiply by 2
15:45 imirkin_: i.e. ram->next->bios.timing[1] -- what does that refer to in nvbios?
15:46 RSpliet: the second timing register
15:46 imirkin_: there are 12 entries
15:46 imirkin_: in the timing table
15:46 imirkin_: which entry is it?
15:46 RSpliet: yes, the timing mapping table tells you which one to pick
15:46 RSpliet: in this case "3"
15:46 RSpliet: you have a CWL of 10, which is not in the translation table
15:47 RSpliet: and a WR of 15, again not in the table... values not seen before :-)
15:47 RSpliet: it's probably best if you get a peek of the MR values from the blob (or it's trace) to find out what they should map to
15:47 imirkin_: cool, so... what values do i stick in there?
15:47 imirkin_: do i have one of those laying around?
15:48 RSpliet: don't know, nothing in the VBIOS repo
15:48 imirkin_: sadness. i don't.
15:48 imirkin_: nvidia clocks up by default right?
15:48 RSpliet: yep
15:49 karolherbst: imirkin_: give it a help with nvidia-settings ;)
15:49 RSpliet: doesn't have to be a full trace, just a peek would be sufficient
15:49 imirkin_:tries to remember how to use mmiotrace
15:49 karolherbst: but yes, it does
15:49 RSpliet: although trace could always come in handy :-)
15:51 imirkin_: ok, got the trace
15:51 imirkin_: what do i look for?
15:51 RSpliet: MR values
15:52 RSpliet: and timings, to verify the blob indeed picked timing set 3
15:52 imirkin_: 100220 right?
15:53 RSpliet: not on kepler
15:54 kb9vqf: karolherbst: your patch worked GREAT!
15:54 kb9vqf: cat /sys/class/drm/card0/device/pstate 07: core 324 MHz memory 648 MHz 0a: core 324-862 MHz memory 1620 MHz 0d: core 540-1215 MHz memory 6008 MHz 0f: core 540-1215 MHz memory 6008 MHz AC DC * AC: core 1215 MHz memory 5976 MHz
15:54 imirkin_: ok, stuck one in http://people.freedesktop.org/~imirkin/traces/gk208/
15:54 kb9vqf: switching on the fly is working perfectly
15:54 karolherbst: :)
15:54 karolherbst: nice
15:54 imirkin_: karolherbst: ship it!
15:54 karolherbst: :)
15:55 karolherbst: its still to messy though
15:55 kb9vqf: I'm going to stress test with a little Portal 2
15:55 karolherbst: ...
15:55 karolherbst: portal 2 ...
15:55 kb9vqf: "stress"
15:55 imirkin_: yes... test... that's the word :)
15:55 karolherbst: I stresstest with bioshock infitine
15:55 karolherbst: :D
15:55 imirkin_: want to make sure that no part of the game has issues
15:55 imirkin_: so have to be thorough :)
15:55 kb9vqf: heh
15:55 karolherbst: :D
15:56 karolherbst: I don't
15:56 kb9vqf: actually on the more serious side, is there a recommended stress test freely available?
15:56 karolherbst: kb9vqf: clock too low though
15:56 karolherbst: dmesg?
15:56 kb9vqf: what's wrong with the clock?
15:56 karolherbst: too low
15:56 karolherbst: 32MHz missing
15:57 karolherbst: :p
15:57 karolherbst: I guess the blob does the same internally maybe
15:57 karolherbst: but who knwos
15:57 karolherbst: *knows
15:57 kb9vqf: Portal 2 is silky smooth...very nice
15:57 kb9vqf: http://paste.ee/p/cefbB
15:57 kb9vqf: I switched the clock a couple times so that dmesg might be a bit confusin
15:57 kb9vqf: *confusing
15:57 karolherbst: yeah
15:58 karolherbst: please a clean output .D
15:58 karolherbst: :D
15:58 kb9vqf: heh, tried from 0x7 to 0xf with Portal 2 running and it went down this time
15:58 imirkin_: RSpliet: http://hastebin.com/raw/zaduviyeru
15:58 kb9vqf: so close, but still some tewaking needed somewhere in nouveau
15:58 karolherbst: yeah
15:58 kb9vqf: *tweaking
15:58 karolherbst: its not perfect yet
15:59 karolherbst: it also went down for me sometimes
15:59 karolherbst: but its a lot more stable with the patch
15:59 kb9vqf: still, much better
15:59 karolherbst: yeah
15:59 karolherbst: would like to see a clean output of dmesg though
15:59 kb9vqf: I'm rebooting now to clear the hung GPU
15:59 RSpliet: imirkin_: let's see what nonsense did I spew again? CWL of 10
16:00 imirkin_: RSpliet: oh, and also, later on i see tCL = 0xe | tCWL = 0xa
16:00 imirkin_: and tWTR = 0x8 | tWR = 0x1e
16:00 kb9vqf: karolherbst: so, you want to see once from 0x7 to 0xf?
16:00 imirkin_: RSpliet: grab the trace for full details :)
16:00 RSpliet: yeah, saw it
16:01 karolherbst: yeah
16:01 kb9vqf: booting back up now
16:01 RSpliet: imirkin_: that piece of trace is missing some important bits
16:01 karolherbst: will check it here too
16:01 RSpliet: could be an intermittant change to a different cstate
16:01 imirkin_: RSpliet: yeah
16:01 karolherbst: the blob algorithm is really bad anyway
16:02 imirkin_: RSpliet: this is all the mem_timings reads: http://hastebin.com/lovayimasi.coffee
16:02 RSpliet: looking for MR though
16:02 imirkin_: oh right. doh
16:02 imirkin_: knwo the reg name offhand?
16:02 kb9vqf: hmm, I've got dmesg spew from another issue. will need to clear that before I can get you the additional info
16:03 karolherbst: kb9vqf: your value is right by the way
16:03 karolherbst: 2968066 * 2 from the blob
16:03 RSpliet: 0x10f300 and - more importantly - 0x10f304 + 0x10f320 I think
16:03 imirkin_: ram->fuc.r_mr[0] = ramfuc_reg(0x10f300);
16:03 imirkin_: ram->fuc.r_mr[2] = ramfuc_reg(0x10f320);
16:04 imirkin_: there's no r_mr[1]
16:04 kb9vqf: karolherbst: here's something for you to consider
16:04 kb9vqf: 0x7 --> 0xf corrupts the display
16:04 RSpliet: ram->fuc.r_mr[1] = ramfuc_reg(0x10f304);
16:04 kb9vqf: 0x7 --> 0xa --> 0xd -->0xf works
16:04 imirkin_: RSpliet: where?
16:05 imirkin_: i don't see that...
16:05 RSpliet: oh hah, I added that myself in https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/8d1f3cc06790eece90bd7da3a88e6ce2a2f76dbe
16:05 karolherbst: kb9vqf: okay
16:05 karolherbst: kb9vqf: thats the issue skeggsb was talking about
16:05 RSpliet: sent the patch to the ml/skeggsb a few weeks ago
16:05 imirkin_: oh :)
16:06 karolherbst: there is still something missing for the transition for the display part
16:06 karolherbst: I can't do anything about that though, because my nvidia card doesn't have any port for a display
16:06 karolherbst: at least with my patch the clock signal is stabilized
16:07 karolherbst: so the memory clock doesn't get unstable
16:07 RSpliet: imirkin_: just to make sure, do you know the exact type of your RAM chips?
16:07 kb9vqf: karolherbst: stupid question: any chance the blob does that sequence internally, very fast?
16:07 karolherbst: don't know
16:07 imirkin_: RSpliet: no clue. DDR3.
16:07 RSpliet: as in, a serial number that could lead to a datasheet kind of typenumber
16:07 RSpliet: oh
16:08 karolherbst: but if you want look that that: 2968066
16:08 karolherbst: ...
16:08 karolherbst: https://gist.github.com/karolherbst/a5dd956189a533ff3e6d
16:08 karolherbst: blob PDAEMON script
16:08 imirkin_: i could pop the card out, but that'll have to wait quite a while
16:08 karolherbst: and nouveau PDAEMON script
16:08 karolherbst: the issue should be somehwere there
16:08 karolherbst: but then again
16:08 karolherbst: I have no clue and skeggsb may have a good idea what is wrong already
16:09 karolherbst: imirkin_: we got a trace now...
16:09 kb9vqf: karolherbst: ok, for now I'll just work around with that sequence. you still need the dmesg output for the step jump from 0x7 to -xf?
16:09 imirkin_: RSpliet: so... what do i want to add to the xlat tables to match nvidia?
16:10 RSpliet: imirkin_: yes, that's the bit that worries me :-P
16:10 karolherbst: kb9vqf: would be nice to have it
16:10 karolherbst: but
16:10 imirkin_: RSpliet: how so?
16:10 karolherbst: it can also be from 0a
16:10 karolherbst: doesn't matter
16:10 RSpliet: for wr it seems to set the value "3"
16:10 karolherbst: I just want to see how nouveau decides which clokc to use
16:10 mupuf: karolherbst: why do you want to increase the temperature?
16:10 karolherbst: imirkin_: by the way: with the path I am nearer to the requested clock than the blob already
16:10 mupuf: there is a tool to fake the temperature
16:11 karolherbst: mupuf: performance issue most likely
16:11 karolherbst: imagine this
16:11 karolherbst: blob: 81°C in unigine
16:11 karolherbst: nouveau only 73
16:11 karolherbst: with same clock, same volt
16:11 imirkin_: RSpliet: ok... and that's bad?
16:11 karolherbst: so I thought, maybe nouveau isn't putting enough pressure onto the card
16:11 mupuf: yes, and? We suck at fully using the hw
16:11 imirkin_: RSpliet: because it's no longer monotonic for my wr = 15?
16:11 karolherbst: okay
16:12 karolherbst: just thought maybe the gpu core hasn't enough to do
16:12 RSpliet: monotonic is not the worry
16:12 kb9vqf: karolherbst: all right, I'll get something to you in the next half hour if all goes well
16:13 RSpliet: but the table already maps a WR of 7 to 3
16:13 karolherbst: imirkin_: apitrace says 84121 calls, but apitrace dump and qapitrace only should some of them
16:13 karolherbst: like 20
16:13 karolherbst: glXQueryVersion is the last of them
16:13 imirkin_: RSpliet: perhaps 15 = 7?
16:13 imirkin_: i.e. one bit too many
16:14 RSpliet: possibly...
16:14 imirkin_: er wait, where is this 15 coming from?
16:14 RSpliet: your timing register
16:14 karolherbst: mupuf: also my patch kind of worked for kb9vqf
16:15 RSpliet: but values of 14 and 16 are valid
16:15 imirkin_: oh, coz it's shifted by 1
16:15 karolherbst: still changing pstate too much can cause issues
16:15 imirkin_: RSpliet: note that my trace switches between WR=7 and WR=15
16:15 imirkin_: so... did you look at the wrong script?
16:16 RSpliet: ah
16:16 RSpliet: probably
16:16 karolherbst: mupuf: would be still nice to also test it on more cards
16:16 mupuf: yes, gonna plug them now
16:17 imirkin_: RSpliet: yeah, i see it go to 7
16:18 imirkin_: which can make sense... both 14 and 15 = 7?
16:18 RSpliet: that can make sense yes
16:18 kb9vqf: karolherbst: before your patch anything above 0xa at any time caused an immediate hard lock
16:18 kb9vqf: with your patch I switched a bunch of times between adjacent power states
16:19 karolherbst: okay, nice
16:19 kb9vqf: the only time (thus far) I've had trouble is with big jumps
16:19 kb9vqf: (0x7 --> 0xf and the like)
16:19 kb9vqf: interestingly 0xf --> 0x7 worked the one time I tried it
16:19 karolherbst: could be because of the PLLs
16:19 kb9vqf: but each time the other way has hard locked or corrupted the screen (hard lock if 3D application running)
16:19 karolherbst: never thought about that yet
16:20 karolherbst: it could be that the memory clock drops too low
16:20 karolherbst: or too high for a brief moment
16:20 imirkin_: RSpliet: and 7 for CWL=10?
16:20 RSpliet: imirkin_: and you want to add a CWL mapping { 10 , 4 }
16:20 imirkin_: where'd you get 4 from?
16:20 karolherbst: I have to check which PLL gets set first
16:20 RSpliet: W 4 150.079530 5 0xfa10a1c4 0x10f320 0x0 0
16:20 RSpliet: W 4 150.079565 5 0xfa10a1c4 0x2000a0 0x0 0
16:21 imirkin_: er, did i say 7? i meant 5.
16:21 imirkin_: RSpliet: 000208: R[0x10f320] := 0x00200088
16:21 imirkin_: er
16:22 imirkin_: 000214: R[0x10f320] := 0x002000a8
16:22 karolherbst: mupuf: also the temp seonsor is nvd*+
16:22 imirkin_: RSpliet: where do you see the 0xa0 thing?
16:22 karolherbst: imirkin_: wanna verify for a short moment?
16:23 imirkin_: verify what?
16:23 karolherbst: ohh silly me
16:23 karolherbst: you are using a kepler
16:23 karolherbst: not fermi card
16:23 karolherbst: nvm then
16:23 RSpliet: imirkin_ what worries me more... is that the timing value does not appear in your VBIOS
16:23 karolherbst: RSpliet: its the same for me
16:24 RSpliet: or I'm looking at something quite different from what I expect to be looking at
16:24 RSpliet: oh *giggles*
16:24 RSpliet: I was looking at gk208.trace.xz
16:24 karolherbst: https://gist.github.com/karolherbst/5318acbba0927753d1e0 and I can clock to 6000 MHz if I want to
16:24 karolherbst: even 8500 worked with blob
16:24 imirkin_: [788872.724830] nouveau D[ PMU][0000:01:00.0] Exec took 143296ns, PMU_IN 07b1ec08
16:24 imirkin_: yay :)
16:24 karolherbst: :D
16:25 karolherbst: nice
16:25 imirkin_: AC: core 966 MHz memory 2002 MHz
16:25 imirkin_: now let's see if it's death
16:26 imirkin_: gah! it's no faster :(
16:26 RSpliet: it... what?
16:27 karolherbst: :/
16:27 karolherbst: imirkin_: do you have someting at 0x02044c ?
16:27 karolherbst: values around 70
16:27 imirkin_: 0x68
16:27 karolherbst: okay, nice
16:28 imirkin_: the card reports 40 degC
16:29 karolherbst: imirkin_: so changing pstate doesn't change performance
16:29 karolherbst: not even a bit?
16:29 imirkin_: no, it does
16:29 imirkin_: just not on that one trace
16:29 karolherbst: okay
16:29 imirkin_: glxspheres is constant at around 600mpixels/s
16:29 karolherbst: :)
16:29 karolherbst: increase pcie link
16:30 karolherbst: that pushes it most
16:30 karolherbst: glxpsheres doesn't care much about mem or core clock
16:30 imirkin_: while it's about 331 mpix/s
16:30 imirkin_: at 0f
16:30 imirkin_: yeah, i've already done that
16:30 kb9vqf: karolherbst: here you go, 0x7 to 0xf: http://paste.ee/p/4St7L
16:30 imirkin_: 8GT/s :)
16:30 karolherbst: okay
16:30 kb9vqf: it reliably corrupts when I do that
16:30 karolherbst: also
16:30 karolherbst: the value are pretty unstable
16:30 imirkin_: but it's an x8 card, and GK208 is pretty crap in general
16:30 karolherbst: try to restart glxspheres and you can get +30% perf
16:32 karolherbst: imirkin_: 600 mp/s isn't bad
16:32 karolherbst: I only got doubled values
16:32 imirkin_: RSpliet: thanks a lot for the help :)
16:33 karolherbst: I should add \n in the patch
16:33 karolherbst: ...
16:33 RSpliet: imirkin_: no problem
16:33 RSpliet: but... now that I take another closer look
16:33 karolherbst: imirkin_: I think glxsphere is cpu limited
16:33 RSpliet: would you mind testing https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/8d1f3cc06790eece90bd7da3a88e6ce2a2f76dbe for me please?
16:33 kb9vqf: karolherbst: it is very reliable when I use the 0x7 --> 0xa --> 0xd --> 0xf sequence
16:33 karolherbst: :D
16:33 kb9vqf: even with 3D running
16:33 karolherbst: nice
16:33 RSpliet: you seem to have one of the rare VBIOSes that wants to disable the DLL in low perf mode
16:34 kb9vqf: karolherbst: my stress test is the hyperspace rss-glx saver on all three screens -- it brings this card to its knees even with the blob on max settings
16:34 imirkin_: kb9vqf: we're supposed to do double-reclocks for some transitions
16:34 imirkin_: kb9vqf: perhaps we get it wrong on your card
16:34 karolherbst: yes
16:34 karolherbst: gddr5 is double reclock
16:34 karolherbst: above 2.4GHz
16:34 karolherbst: always
16:34 karolherbst: you have to set two PLLs
16:34 imirkin_: karolherbst: i meant 2-step
16:35 imirkin_: i.e. do one full reclock, and then another full reclock
16:35 kb9vqf: still, very nice. I think reclocking is just about functional on the GTX-670 now :-)
16:35 karolherbst: so both PLLs twice?
16:35 karolherbst: mhhh
16:35 karolherbst: okay
16:35 kb9vqf: karolherbst: do you need any more info?
16:36 karolherbst: no, don*t think so
16:36 karolherbst: we are better then the blob already
16:36 kb9vqf: how so?
16:36 karolherbst: we choose a closer clock
16:36 kb9vqf: ah, ok
16:36 karolherbst: blob cares less about choosing a good clock
16:36 karolherbst: so you get a bit higher clocks with nouveau
16:37 RSpliet: imirkin_: please let me know if you have time to test that patch I linked, otherwise I'm off to bed ;-)
16:38 imirkin_: RSpliet: oh, i ran on top of it
16:38 imirkin_: i haven't tested without it
16:38 RSpliet: so back and forth to lowest is stable too?
16:38 skeggsb: karolherbst: are you taking into account the fractional part of N?
16:38 skeggsb: (when looking at the binary driver values)
16:38 imirkin_: RSpliet: well... it's a secondary card, i'm not running displays on it
16:38 karolherbst: you mean the highest bits?
16:38 karolherbst: I saw them yes
16:38 imirkin_: RSpliet: but it wasn't particularly *unstable* :)
16:39 karolherbst: but choose to not care about them yet
16:39 imirkin_: let me try changing clocks while running glxspheres
16:39 RSpliet: imirkin_: on second thought, don't bother
16:39 skeggsb: well, you'll probably find that the binary driver is pretty spot on if you do :)
16:39 kb9vqf: karolherbst: cool. if you need any more tests I'll idle in this channel (in a bit anyway)
16:39 kb9vqf: thanks again!
16:39 imirkin_: RSpliet: yep, up and down works fine
16:39 karolherbst: skeggsb: does nouveau calculates clock right?
16:40 RSpliet: imirkin_: yeah, I was hoping it would drop below 162MHz
16:40 imirkin_: sorry can't help you with that
16:40 karolherbst: skeggsb: I got same PLL values for like two different clocks
16:40 karolherbst: in blob
16:40 imirkin_: 800mhz is as low as i go on ram ;)
16:40 RSpliet: imirkin_: yeah... I wonder why I observed that in your traces though
16:41 imirkin_: perhaps blob knows something we don't? :)
16:41 karolherbst: yeah, maybe
16:41 karolherbst: or maybe it doesn't care
16:41 karolherbst: it also didn't care about my 8500MHz mem clock...
16:42 karolherbst: skeggsb: thats the patch I wrote https://github.com/karolherbst/nouveau/commit/2188c57c321f0dc73de1e7db323c70fc566b8efd
16:42 karolherbst: and I think this is pretty close to what the blob does
16:43 karolherbst: maybe the blob only does a static tbale lookup
16:45 skeggsb: yeah i seen that, i'll try and take a proper look shortly
16:45 RSpliet: imirkin_: oh! it's not touching DLL, but RTT_NOM
16:45 karolherbst: P=2 is also a possibity, but I wanted to keep that patch tirival for now, so that it can be tested
16:45 imirkin_: RSpliet: told you the blob knew something we didn't. for example it knows how to count bits properly :p
16:46 karolherbst: :D
16:49 RSpliet: imirkin_: I bet it's derived from the up-until-now-unexisting ramcfg_11_02_20
16:50 RSpliet: hooray, more to play with when I find time
16:51 RSpliet: shakesoda: be sure to try out that kernel ;-) I'd be interested in hearing your results
17:01 karolherbst: mupuf: how is it going?
17:13 karolherbst: skeggsb: I guess you don't know much about DRI_PRIME stuff in general?
17:18 skeggsb: the specifics about the code, no. but there's not too much to know in general
17:18 karolherbst: mhh
17:18 skeggsb: i get the impression that sync stuff has mostly been abandoned in favour of explicit sync down the track...
17:19 karolherbst: I am asking because I have sometimes heavy synchronisation issues
17:19 karolherbst: also tearing
17:20 karolherbst: funny though: a game with heavy sync issues got my gpu to hang again
17:38 karolherbst: will be off now
17:40 imirkin_: skeggsb: btw, i still get 'nouveau E[ CLK][0000:01:00.0] failed to lower voltage: -22' when clocking down, but the updates seem to have taken effect
17:40 imirkin_: skeggsb: anything to worry about?
17:42 skeggsb: imirkin_: aside from it having failed, no, probably not
17:57 marcosps: Hi guys, someone here tried to run steam by using DRI_PRIME=1 for trying to use optimus?
17:57 imirkin_: yeah, works fine
17:58 marcosps: even when using DRI_PRIME and LD_LIBRARY_CONFIG, my System Info shows Mesa 10.6.3, and not Mesa 11
17:58 imirkin_: probably because it's a 32-bit game
17:58 imirkin_: and you pointed it at a 64-bit lib
17:58 marcosps: What sad ...
17:58 marcosps: imirkin_: I'm hitting crashes in Dead Island...
17:59 imirkin_: what sort of crashes?
17:59 marcosps: Even when trying with DRI_PRIME and a update mesa
17:59 marcosps: When the game tries to load the prolog, after chossing for my character, the game stops to load and fails...
17:59 imirkin_: please describe the failure :)
18:00 imirkin_: actually i'll bbiab. but i'll read scrollback.
18:00 marcosps: hehehe
18:00 marcosps: the log shows:
18:02 marcosps: imirkin_: https://paste.fedoraproject.org/256051/85972614/
18:02 marcosps: The log is much bigger, but I extract the final log. Do you the initial output from game?
18:12 marcosps: imirkin_: http://www.pastefile.com/km97za
18:12 marcosps: I zippped the log...
18:20 marcosps: imirkin_: If you need more tests, please let me know...
18:22 imirkin_: marcosps: and then it just exits?
18:22 marcosps: yes...
18:22 imirkin_: anythign in dmesg?
18:22 marcosps: after the game closes, so I close steam...
18:22 marcosps: Yes, it shows a segfaults in Dead Island...
18:23 marcosps: Also, I have some problems about ACPI in kernel side, maybe due to optimus: https://paste.fedoraproject.org/256053/14398610/
18:25 imirkin_: paste the segfault line?
18:25 imirkin_: oh, you already did
18:25 imirkin_: the acpi stuff is normal
18:25 imirkin_: well that's great... segfault somewhere in libc
18:26 marcosps: imirkin_: Sad... I bought this game some time ago waiting for mesa to be able to play it... I'm almost there :)
18:27 imirkin_: if you can get a backtrace in gdb that might be interesting
18:27 imirkin_: but it might also just be the game crashing due to something unexpected
18:27 imirkin_: i.e. in the game logic
18:28 marcosps: imirkin_: got it... but, this is strange, since a lot of people are running this game for so long time... and also, this is an old game...
18:28 marcosps: As I have my optimus thing, I always suspect something about it :)
18:31 tobijk_: marcosps: prime is working fine here for some time now, you got some reliable problems with it, or are you just suspicious? :D
18:32 imirkin_: actually iirc someone did file a bug about that game
18:32 imirkin_: https://bugs.freedesktop.org/show_bug.cgi?id=91480
18:35 marcosps: tobijk_: I'm having problems :) Also, steam System Info shows 10.6.3 even when LD_LIBRARY_PATH to my compiled mesa... imirkin_ said that this can be realted to 32bit lib, against my 64it mesa libs...
18:36 tobijk_: marcosps: cause you compiling 64bit mesa and steam uses 32bit mesa? :>
18:36 marcosps: imirkin_: nice! A proper bug to be fixed... how can I test this shader inside mesa?
18:36 marcosps: tobijk_: I think so...
18:37 tobijk_: marcosps: you may trace the game with intel (if it works there)
18:38 tobijk_: ...and then replay it with intel
18:38 tobijk_: *nouveau
18:38 marcosps: tobijk_: Both cases ends to a crash... =/
18:38 tobijk_: :/
18:38 marcosps: tobijk_: But I'll try to get the trace when using Intel and then compare...
18:38 imirkin_: marcosps: perhaps mention that in the bug? iirc it was only reported against radeon
18:40 marcosps: imirkin_: I'll comment the bug here.
18:41 marcosps: imirkin_: Do you think it's interesting to test the shader in my setup?
18:41 imirkin_: no
18:44 marcosps: imirkin_: I'll try to get the full trace here...
18:46 tobijk_: every time i rebase my little work i have to merge mass of stuff :/
18:58 marcosps: tobijk_, imirkin_: https://paste.fedoraproject.org/256058/98630731/
18:58 marcosps: Running gdb now with DRI_PRIME=1
18:59 marcosps: Also, I had to start steam first on a console, and then start Dead Island in another to test it..
19:00 tobijk_: i dont see mesa in there :O
19:00 imirkin_: marcosps: what CPU do you have?
19:01 imirkin_: can't be pre-sse2...
19:01 imirkin_: and you would have gotten a SIGILL anyways
19:02 marcosps: imirkin_: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz
19:02 tobijk_: new enough for everything :D
19:04 marcosps: tobijk_, imirkin_: =/
19:04 marcosps: The crah when loading the prologue...
19:04 marcosps: I'll comment the bug...
19:04 imirkin_: marcosps: you can try running it in valgrind to see if perhaps it's our bad
19:04 imirkin_: i.e. we overwrite something
19:04 imirkin_: but... yeah dunno
19:04 tobijk_: it looks like they already got one or several shaders and try to manipulate them somehow
19:04 imirkin_: most likely it's their bad
19:05 imirkin_: marcosps: one random idea... try running with LC_ALL=C
19:05 imirkin_: (i'm guessing you have some non-ascii locale set?)
19:06 tobijk_: mh or deadisland wants a super-special steamos/ubuntu libc
19:07 imirkin_: i guess ubuntu probably defaults to LC_ALL=en_US.utf8 -- probably worth testing that as well
19:07 imirkin_: the only reason i bring that up is that it's some random string function dying
19:08 imirkin_: in a function that's clearly doing some sort of string processing
19:08 marcosps: imirkin_: with LC_ALL=C, crashed again.. will try again with en_US...
19:08 imirkin_: it's a long-shot, just worth trying since it's easy
19:09 tobijk_: is that game working with any other opengl vendor? like say nvidia
19:10 imirkin_: probably
19:10 imirkin_: oh you mean on his specific system. question worth asking
19:11 marcosps: imirkin_: problem with en_US too...
19:11 imirkin_: k
19:11 tobijk_: i still suspect the damn steamos libs
19:12 marcosps: tobijk_, imirkin_: there is a quick way, and not painful, to test nvidia proprietary driver?
19:13 tobijk_: with an optimus notebook it always gave me trouble configuring it right...
19:14 marcosps: =/
19:15 tobijk_: but it is possible, just takes more time if you do it the first time
19:15 marcosps: tobijk_, imirkin_: maybe it's worth trying valgrind first?
19:16 imirkin_: oh, i can already imagine what's going to happen
19:16 imirkin_: valgrind will die :(
19:16 imirkin_: saying you're hitting some unknown instruction
19:16 imirkin_: ugh, i hate the universe.
19:17 marcosps: imirkin_: so, my problem is different from the bug you send?
19:17 imirkin_: no, it's just there's a good chance that valgrind will get you nowhere
19:19 marcosps: imirkin_: another problem, valgrind can't use memcheck for x86...
19:19 imirkin_: yeah, the valgrind guys have basically dumped x86_32
19:19 imirkin_: sadness.
19:19 marcosps: and sorrow...
19:20 marcosps: imirkin_, tobijk_: maybe the last test would be using the nvidia driver?
19:20 tobijk_: marcosps: that is one way
19:20 tobijk_: andother would be to use some random (other) distro and try to run the game
19:20 tobijk_: *with mesa
19:21 tobijk_: that may get you around the libc bug
19:21 marcosps: tobijk_: so... I have just fedora on this machine... do you suggst to instal a ubuntu and try it...? :)
19:22 tobijk_: maybe you can just use some live-distro and mount fs with steam on it and run it
19:23 tobijk_: what ever distro you prefer, should be as far away from fedora as possible
19:23 tobijk_: :D
19:23 marcosps:starts downloading ubuntu and starts to stop smiling...
19:23 tobijk_: please not that this is a wild guess
19:23 tobijk_: *note
19:24 marcosps: tobijk_: sure, but maybe this test can explain somethings...
19:24 tobijk_: if the game does not crash or crashes somewhere else we have a good chance for a fedora libc bug
19:25 marcosps: tobijk_: damn... ubuntu has 1.1G of size...
19:25 marcosps: tobijk_: so, we're going deeper and deeper ...
19:25 marcosps:wants to stop going deeper before hit the hell :P
19:26 tobijk_: you are just scratching the outer layer :P
19:26 imirkin_: still in limbo :)
19:27 marcosps: I still don't know why can I help this crazy things called graphic cards :)
19:27 marcosps:is thinking about install Windows 12 and get all the games the world can offer
19:28 tobijk_: windows cloud-os plus 12? :D like in 3 years
19:28 marcosps: :)
19:28 marcosps: tobijk_, imirkin_: I really don't play games... maybe once a week, but, I think this problem can help me to be more in touch with mesa code...
19:28 imirkin_: i play games like once a year :)
19:29 tobijk_: imirkin_: but you start one once a day? :D
19:29 imirkin_: tobijk_: if glretrace can be considered a game...
19:29 marcosps:is waiting for 24 minutes to get the download finished...
19:30 tobijk_: imirkin_: text adventure enhanced with some pictures :)
19:37 tobijk_: imirkin_: btw can you review / commit my for now no-op patch :)
19:37 tobijk_: it does get ignored at the ml as always and you are the closest *contact*, sorry :)
19:37 imirkin_: link
19:37 imirkin_: to patchwork
19:39 marcosps: imirkin_: also, woul you like to commit my patches too...?
19:39 tobijk_: it is not in there :O
19:39 tobijk_: wtf
19:39 marcosps: tobijk_: sorry...?
19:39 imirkin_: marcosps: yea... i'll get to it, don't worry :)
19:39 tobijk_: marcosps: i am ranting about the email system, sorry
19:40 imirkin_: tobijk_: i don't see any email from you since june
19:41 tobijk_: yeah my system is misconfigured, local sendmail :O
19:41 tobijk_: thats why it is ignored :D
19:41 marcosps: tobijk_: no problem :)
19:42 marcosps: imirkin_: ok so :) in the meantime, I'll verify the double immeadiates...
19:42 imirkin_: marcosps: cool
19:43 imirkin_: marcosps: i'll fix it up, but in the future please be careful about stuff like "ctx->implied_array_size = 32 ;"
19:43 imirkin_: note the space.
19:44 marcosps: imirkin_: oops... sorry... I was too anxious to send my patches to mesa that I forgot this detail...
19:45 imirkin_: marcosps: i'll also reword your commit logs... look at how it comes out afterwards
19:46 marcosps: imirkin_: ok, thanks a lot :)
19:48 marcosps: tobijk_: Do you have Dead Island too?
19:49 tobijk_: marcosps: nope
19:49 tobijk_: just problems with steam one in a while :D
19:49 marcosps: hehehe
19:50 marcosps: tobijk_: Also, AMD seems to be doing a very nice work no mesa lately... Maybe nvidia could take as an example and do the same :P
19:51 tobijk_: marcosps: if you get them to help more (yes they started to), just make em do that
19:52 tobijk_: imirkin_: patch is on the ml now, patchwork is slow
19:53 marcosps: tobijk_: hum... nice to know...
19:53 imirkin_: tobijk_: please regenerate with -M
19:53 imirkin_: tobijk_: also... this should be part of a series that adds cull distance
19:53 imirkin_: as-is it's a bit weird to check in
19:54 tobijk_: its just a split out as it stands for itself
20:10 imirkin_: marcosps: pushed
20:15 marcosps: imirkin_: Thanks a lot! I liked the way you rewrote my commit msg... thanks a lot :)
20:16 imirkin_: marcosps: your old one was more about something being printed in tgsi_dump, making it seem as if that was the bug
20:16 imirkin_: marcosps: whereas the printing was quite accurate based on what was being parsed in by the text parser
20:17 tobijk_: marcosps: he does that al lthe time, half my commit msgs are from him ;D (making them way more clear)
20:18 marcosps: tobijk_: hehe
20:19 marcosps: imirkin_, tobijk_: In my case, I just need more info about the problems I'm solving, and this knowledge will come after some commits :)
20:19 marcosps: imirkin_: But I promise to let things easier to you next time :)
20:19 imirkin_: no worries
20:20 marcosps: imirkin_: Downloaded Ubuntu here... I'll try to load it tomorrow to test with steam...
20:22 marcosps: imirkin_: do you have some shader with double immeadiates to test with...?
20:22 imirkin_: marcosps: not offhand, let me find one
20:24 tobijk_: going to bed, good night
20:27 imirkin_: gah, can't seem to find one. airlied do you remember of one?
20:28 marcosps:will stop to debug by just looking at code... will put prints to avoud overloaded/overwrited methods/functions...
20:29 imirkin_: marcosps: should be pretty easy to write one...
20:29 marcosps: imirkin_: I have absolutely now knowledge about shaders yet hehe
20:31 marcosps: *no knowledge
20:31 imirkin_: marcosps: http://hastebin.com/itexujedal.hs
20:31 imirkin_: you can run that through bin/shader_runner in piglit
20:32 imirkin_: actually that's not a very good constant... pick a constant that can be encoded in the top 20 bits of the 64-bit float
20:32 imirkin_: since that's all the bits you get
20:32 imirkin_: switch things up so that it's 1.0 or something
20:32 imirkin_: that should fit :)
20:33 marcosps: imirkin_: where I need to chnge...? :P
20:34 marcosps: imirkin_: Also, sorry if this is a newbie question, but, I saw that tgsi it's like a mesa intermediate shader language... so, this shader you sent to me is a shader that needs to be compiled to become a tgsi one...?
20:34 imirkin_: yeah, but that will happen as part of the normal process
20:35 imirkin_: TGSI is an assembly-like language used to communicate shaders across the gallium api
20:35 imirkin_: don't worry about that... that bit all works fine ;)
20:37 marcosps: imirkin_: ok :)
20:38 marcosps: imirkin_: I ran the shader in piglit... so it generated two tgsi shaders and a lot of assembly output :)
20:38 imirkin_: marcosps: you ran it with VN50_PROG_DEBUG=1 ?
20:39 marcosps: imirkin_: yes sir :)
20:39 marcosps: DRI_PRIME=1 and that LD_LIBRARY_PATH setup to point to my compiled mesa
20:40 marcosps: imirkin_: if you want, I can share the rsult with you by pastebin
20:40 marcosps: imirkin_: https://paste.fedoraproject.org/256085/69227143/
20:40 vducuy: Hi all, enabled nouveau in kernel 3.18 and i see this errror
20:40 vducuy: nouveau E[ DISPLAY][0000:01:00.0][0x00000000] 01:0130: func 08 lookup failed, -2
20:40 imirkin_: vducuy: nothing to worry about
20:41 vducuy: what does that error mean?
20:41 imirkin_: something in the vbios refers to a thing that doesn't exist
20:41 vducuy: ah. thanks imirkin_
20:51 marcosps: going to sleep, see ya!
21:33 imirkin_: oh nice. heaven works on my gk208 again. i think vblank_mode=0 "fixes" it
21:33 imirkin_: weird. wtvr.