01:01 orbea: is there any good reason to use the autogen.sh instead of autoreconf -fi or something?
01:01 karolherbst: orbea: look inside autogen.sh
01:02 orbea: qah, yea, so pretty much same diff
01:02 orbea: *ah
01:02 karolherbst: yeah
01:02 karolherbst: some projects require more complex things though
01:03 karolherbst: so usually projects include that so that it is easier to use
01:24 imirkin: Gnurou: welcome back - been away for a while?
01:24 Gnurou: imirkin: ah sorry I was on holidays for a couple of days last week, and log off IRC in that case
01:25 imirkin: nothing to be sorry about :)
01:26 imirkin: Gnurou: any chance you have a more complete list of https://github.com/envytools/envytools/blob/master/rnndb/g80_defs.xml#L276 you could share? (gk104+ image format enum)
01:28 Gnurou: imirkin: isn't it the one I contributed? If so I'd expect it to be fairly complete, what's missing?
01:28 imirkin: Gnurou: no, you contricted texture formats
01:28 imirkin: this is for image formats - totally different ;)
01:29 Gnurou: ah sorry
01:29 imirkin: these are format enums handed to sustp instructions
01:29 imirkin: (for images)
01:29 Gnurou:needs coffee
01:29 imirkin: on GK104+
01:30 imirkin: well, for someone not *intensely* in the know, a texture and an image might sound awfully similar
01:30 Gnurou: imirkin: can you open an issue on Github with the link, so I don't lose track of it?
01:30 imirkin: yep
01:30 imirkin: that's my best thing
01:30 airlied: imirkin: v3!
01:30 airlied: oops wrong chan
01:30 imirkin: airlied: should get v4 ready, anticipating another objection :)
01:30 Gnurou: Github issues eventually tend to follow up to completion... slowly, but they do :)
01:34 imirkin: Gnurou: ok, filed. (and i filed one earlier, too)
01:35 Gnurou: imirkin: excellent, thanks!
01:35 imirkin: as always, if anything's unclear, let me know, happy to explain in more detail what i mean
01:35 imirkin: i know it's easy to have terminology mismatches =/
02:06 Doctors: the difference between specifing the amount of jobs and not is like night and day. 10 jobs is waaayy faster than default
02:12 imirkin: Doctors: esp if you have multiple cores
02:12 imirkin: which most modern desktops do
02:13 Doctors: I just have two
02:13 Doctors: but setting the job count to 10 took like 1 min to compile
02:13 Doctors: whereas nothing took over 10min
02:15 imirkin: then you have more than 2 cores... this stuff ain't magic
02:16 airlied: you can get some minors bits from the fact you are doing i/o while compiling as well
02:16 airlied: but I don't think it would be 5x
02:16 imirkin: right :)
02:16 imirkin: i think the usual advice is to set it to cores + 1
02:16 airlied: yup sounds right
02:16 imirkin: to account for the fact that i/o isn't infinitely fast
02:17 imirkin: i just set it to the # of hyperthreads
02:17 imirkin: coz i'm lazy and don't want to think about it
02:17 airlied: make should be smarter
02:18 imirkin: yeah, make -j should auto-detect number of cores instead of fork-bombing
02:18 imirkin: o well
02:38 Doctors: imirkin; Works great, though its quite slower than than 11.2.2
02:39 imirkin: Doctors: hmmm... what is?
02:39 imirkin: Doctors: how did you build it?
02:39 Doctors: make -j10 install
02:39 imirkin: i meant the configure line
02:40 imirkin: (you can run 'head config.log' in case you forgot)
02:40 Doctors: ./configure --prefix=/home/user/install
02:40 imirkin: that's it?
02:40 Doctors: yeah
02:40 imirkin: that seems ... unlikely
02:40 imirkin: or rather
02:40 imirkin: you're probably running on top of llvmpipe
02:40 imirkin: which is why it appears so slow
02:41 imirkin: by default nouveau doesn't get built, i think
02:41 Gnurou: RSpliet: tried your kernel-nouveau-nv50-pm branch on my gk106 btw, could still get ctx switch errors :(
02:41 Gnurou: RSpliet got two different kinds of errors actually:
02:41 Gnurou: see http://pastebin.com/UkzpK2PZ and http://pastebin.com/G1K3KGJS
02:41 imirkin: Doctors: you probably want to at least add --with-gallium-drivers=nouveau,swrast
02:42 Doctors: imirkin; So could I get it not to run ontop of llvmpipe? (also I half noticed that earlier when I frist started it up)
02:42 imirkin: Doctors: this is what i have, in addition to the prefix: --with-gallium-drivers=nouveau,swrast --with-dri-drivers=nouveau,i965 --enable-texture-float --enable-gles2 --enable-gallium-llvm --enable-gbm --with-egl-platforms=x11,drm
02:42 Doctors:nods
02:42 imirkin: although you could easily just do --with-dri-drivers=''
02:42 imirkin: since you neither need i965 nor the nouveau_vieux driver
02:43 Doctors:nods
02:43 imirkin: Doctors: make sure you do "make clean" first too, otherwise some of those settings might not "take"
02:44 Doctors:nods a second time
02:45 imirkin: Gnurou: what did you run to get the invalid opcodes? :(
02:46 Gnurou: imirkin: start X with plasmashell, then run 4 glmark2
02:46 imirkin: you don't ask much, do you
02:46 Gnurou: imirkin: one of the two errors usually happen within seconds unless I am using NVIDIA's firmware
02:46 imirkin: hmmm ok
02:46 imirkin: so then it's a ctxsw fail, not nouveau generating bad shaders
02:46 Gnurou: I suspect so
02:47 Gnurou: let me try some more with NVIDIA's firmware to see if I can get the invalid opcode error
02:47 Doctors: imirkin; Jobs aren't based on number of cores/threads. Its how many proccess you want open per make install.
02:48 imirkin: Doctors: but your desire for processes is highly connected to how many CPUs you have to service those processes :)
02:51 imirkin: Gnurou: fwiw i've seen the PUSH_TOO_MUCH_DATA thing too, when trying to run F1 2015 :)
02:52 Gnurou: imirkin: on which chip?
02:53 imirkin: Gnurou: GK208
02:53 imirkin: the NV106 variety rather than the NV108 variety
02:53 Doctors:shrugs
02:53 Doctors: anyhow rebuilding now
02:53 imirkin: Gnurou: i go for the high-end stuff ;)
02:54 Gnurou: imirkin: hehe
02:54 imirkin: Gnurou: pcie x8, ddr3 vram
02:54 gnurou: something wrong with the kepler fw then?
02:55 gnurou: running my 4 glmark's with NV fw, very stable so far
02:55 imirkin: well, people have been reporting issues on GK106's since the dawn of time
02:55 gnurou: right
02:55 imirkin: clearly there's something nvidia knows that skeggsb_ doesn't
02:55 imirkin: perhaps, even multiple things
02:55 gnurou: at least for Maxwell 2 and on this issue cannot happen, since you don't have the option to run non-signed FW if you want to do interesting things :/
02:56 imirkin: yes... thank goodness for that
02:56 gnurou:tries to look at the bright side of things
02:56 imirkin: of course you can't do interesting things anyways since you won't release that fw...
02:57 gnurou: there are still improvements to be done on that front indeed /o\
03:01 imirkin: yes ... on so many fronts
03:01 imirkin: it's all front, no back
03:34 Doctors: imirkin; Works great! Thanks for fixing it, can
04:36 mupuf: hakzsam, imirkin, karol: I got a trace of shadow of mordor showing real issues
04:36 mupuf: the trace is taken on the titan
04:36 imirkin: mupuf: i'm not surprised
04:36 mupuf: I had to set an environment variable to get the rendering fixed on nvidia (https://devtalk.nvidia.com/default/topic/926220/linux/364-12-shadow-of-mordor-regression-perhaps-tessellation-related-/)
04:37 mupuf: i965 shows the same behaviour as nvidia
04:37 mupuf: I am uploading the trace as we speak, 8.1 GB
04:37 mupuf: need a trace for the witcher 2? It was really funny with nouveau on the lowest setting
04:37 mupuf: there is also talos principles that had issues
04:38 imirkin: well, allegedly it's a bug in the game
04:38 imirkin: the fact that talos has issues is well known
04:38 imirkin: amusingly it works fine on nv50
04:39 imirkin: they have a demo that also shows issue
04:40 imirkin: iirc most of them come down to a single setting in their graphics menu
04:40 imirkin: (if only i could remember which one... something to do with dynamic lighting?)
04:40 mupuf: hehe
04:46 mupuf: imirkin: what is nouveau's take on application bugs?
04:47 imirkin: they suck :)
04:47 mupuf: I guess: Low priority bugs?
04:47 imirkin: not sure what you're asking
04:47 mupuf: well, "workarounds" that could land in drirc
04:47 imirkin: ah. well, among other things, there's no easy way to plumb drirc settings into gallium backends
04:48 imirkin: so if it's a frontend workaround - fine, but for backend, it'll be more work
04:48 imirkin: i'm not opposed in principle, but i have enough headaches that i don't need to go looking for more :)
04:48 mupuf: not cool, especially since there is support for specifying for which driver we want to read the settings
04:49 mupuf: yeah, my guess was right then, low priority
04:49 mupuf:is not asking anything
04:49 mupuf: I am merely doing what hakzsam asked me to do, test shadow of mordor
04:49 mupuf: and I had other games installed
04:49 imirkin: i'm not very good at tracking down why rendering is broken, be it due to driver or application issues - there's a class of bugs i can figure out with ease, but anything falling out of that, i'm totally lost
04:50 mupuf: apitrace may help, but one needs a visual debugger
04:50 imirkin: basically if my bag of tricks "solves" it, great. otherwise i'm stuck.
04:50 imirkin: and it's a lot more fun to work on features
04:50 mupuf: hehe, right
04:50 imirkin: so that's what i do.
04:51 imirkin: who ported shadow of mordor? was it feral? if so, they might be willing to hand out keys
04:51 mupuf: yeah, it is feral
04:57 mupuf: the witcher 2 trace failed
04:58 mupuf: as in, it creates ~45 windows, but all of them are black
04:58 mupuf: well, seems like the only trace I will upload is shadow of mordor
04:58 imirkin: probably uses buffer storage
04:59 mupuf: luckily, it is problematic for intel too and it is shaders refusing to compile
04:59 mupuf: so... that should be clear-enough to troubleshoot
05:00 imirkin: will you be troubleshooting?
05:00 imirkin: or are you just trouble-teeing?
05:00 imirkin: or trouble-making :)
05:02 mupuf: well, like you, low priority. I am just dumping the information I have for posterity :D
05:02 mupuf: and I am off to work now
05:47 gnurou: RSpliet: imirkin: so can definitely confirm that the kernel-nouveau-nv50-pm repo with the NV firmware runs fine on GK106, but doesn't with the Nouveau firmware
05:47 imirkin: gnurou: btw, i assume you weren't testing his master branch?
05:48 imirkin: gnurou: i think that the thing to test was the ctxswitch_litmus branch
05:48 gnurou: imirkin: that's the one with the latest commits, so I assumed this was the one to test ... ?
05:49 imirkin: i could be mistaken
05:49 imirkin: it's not my tree
05:49 gnurou: ah dammit, I got fooled by the date of the top commit
05:49 imirkin: but i think that the master branch has stuff re fermi reclocking
05:50 gnurou: imirkin: so yeah, you may be right here... ah well I can check this branch as well
05:51 gnurou: imirkin: you're *very* likely to be right since I cannot see anything regarding fuc in his master branch...
05:59 gnurou: RSpliet: imirkin: no luck with ctxswitch_litmus either: http://pastebin.com/dNyDMcbK
05:59 imirkin: :)
05:59 imirkin: doh
06:00 imirkin: no stack =/
06:00 imirkin: but at least it prints the pc
06:00 imirkin: which RSpliet will hopefully know what to do with
06:07 imirkin: RSpliet: 0xb4c and 0xb52 (in your branch)
06:18 imirkin: hrmph
06:18 imirkin: 00000b48: f1 97 00 00 B mov $r9 0x0
06:18 imirkin: 00000b4c: f0 93 03 sethi $r9 0x30000
06:18 imirkin: 00000b4f: cf 99 00 iord $r9 I[$r9]
06:18 imirkin: 00000b52: f1 94 00 20 and $r9 0x2000
06:18 imirkin: 00000b56: f4 1b f2 bra ne 0xb48
06:19 imirkin: which is the gpcs_idle_wait_loop if comments are to be believed
08:33 RSpliet: gnurou:sorry, yes that ctxswitch_litmus tree was the branch. I refrain from updating it for reasons of reproducability
08:34 RSpliet: I should really fix that stack printing method
08:35 RSpliet: but... the pc is interesting. would the gpc *actually* not idle for...reasons?
09:01 gnurou: skeggsb_: re: FD bug 94990, I will send you the patch that makes Nouveau more tolerant to secure boot errors tomorrow... wondering why this even happens though :(
09:11 hakzsam: mupuf, where are the traces? what's the issue with shadow of mordor?
09:14 mupuf: hakzsam: issues: https://devtalk.nvidia.com/default/topic/926220/linux/364-12-shadow-of-mordor-regression-perhaps-tessellation-related-/
09:14 mupuf: no worries about it, it is being handled actually, there is a bug on IRC
09:14 hakzsam: yep, I know this bug already
09:15 mupuf: I sent an email to Feral to ask when they will deploy the new version
09:15 mupuf: and, at the same time, asked for a key for our account
09:15 hakzsam: nice
09:15 mupuf: as for the trace, you'll have to force exposing 4.4, otherwise, it will fail
09:16 hakzsam: okay
09:16 hakzsam: thanks
09:19 karolherbst: mupuf: awesome :)
09:20 karolherbst: gnurou: welcome back
09:22 karolherbst: mupuf: two things: 1. we might be able to upload an PMU image on gm20x without access to special regs for like stuff like "fan control" 2. on pascal the voltage is set most likely on the pmu :p
09:23 mupuf: karolherbst: what makes you think so for 1)?
09:23 mupuf: I would love for it to be true!
09:23 karolherbst: mupuf: because ben said this
09:23 karolherbst: :D
09:23 mupuf: oh oh oh
09:24 mupuf: well, I agree for the fan
09:24 karolherbst: yeah
09:24 mupuf: but, what are we going to do to keep the GPU cold?
09:24 karolherbst: well
09:24 karolherbst: the host can still do this I think?
09:24 mupuf: nope!
09:24 karolherbst: or not?
09:24 karolherbst: ohhh
09:24 karolherbst: ohhhhhhh
09:24 karolherbst: :O
09:24 karolherbst: mhhh
09:24 karolherbst: well
09:24 karolherbst: we have the fsrm....
09:25 mupuf: :D
09:25 mupuf: maybe we can be crazy and use another PWM controler though
09:25 karolherbst: yeah
09:25 karolherbst: maybe
09:25 karolherbst: I am sure we can figure this out
09:25 mupuf: but I never got how the heck we were supposed to change the routing of GPIOs' special functions
09:26 karolherbst: anyway the gp104 trace looks a bit scary
09:26 karolherbst: PFB moved
09:27 karolherbst: and reclocking looks oddish enough
09:27 mupuf: if we manage to use SOR's PWM for the GPIO, we are good
09:28 mupuf: if not, we may try to resurect the TOGGLE mode
09:28 mupuf: which uses the host to do PWM at 10 Hz
09:28 karolherbst: well
09:28 karolherbst: I think users would be thankfull if they could reclock their gm20x gpus with nouveau _at_all_
09:28 mupuf: but, I seriously doubt we can do this, otherwise, what was the point?
09:29 mupuf: But you never know, we may get away with this for 2 families
09:29 karolherbst: yeah
09:29 karolherbst: anyway I really don't like how it is looking now
09:30 mupuf: I got the key from Feral and instructions on how to access their beta build apparently
09:30 karolherbst: ahh
09:30 karolherbst: mhh
09:30 karolherbst: I have no clue if the beta access is saved on the account though
09:34 mupuf: hakzsam: here you go, shadow of mordor, with beta access :p
09:35 hakzsam: cool, but I just need a trace :)
09:35 hakzsam: and that game requires 50G of free space...
09:35 hakzsam: so, I can't just download it :D
09:37 mupuf: 1TB drives for ~50e on rdc
09:37 hakzsam: yep, I know
09:38 mupuf: just saying :p
09:38 hakzsam: I will need to buy one in the next weeks, but I have enough work for now :)
09:38 karolherbst: well I download it
09:38 karolherbst: I can give you a trace in like... 4 hours? :D
09:38 karolherbst: ohh 2 and a half now
09:39 mupuf: karolherbst: steam made me break my speed record :D
09:39 mupuf: 39.2 MB/s
09:39 karolherbst: :O
09:39 karolherbst: well
09:39 karolherbst: they have fast servers for sure
09:39 karolherbst: but usually you have to be higher ranked to get those speeds
09:39 mupuf: they do :D
09:40 mupuf: just click on the game and pretend you want to play ASAP
09:40 karolherbst: well for that I would need to have fast internet
09:40 karolherbst: ...
09:40 karolherbst: you know germany sucks with internet big times
09:40 mupuf: mwk: can we change the special function of GPIOs?
09:41 karolherbst: 100Mbit is considered _fast_ here
09:41 karolherbst: :p
09:41 mupuf: mwk: like, changing which PWM controller we want to use
09:41 librin: karolherbst, I read Your comment on Payday2
09:41 karolherbst: and it doesn't help that I am here on wifi and through a wall where nearly nothing comes through
09:41 mupuf: I wonder if that will allow us to get around the silly restriction on the PWM register
09:41 karolherbst: but I guess 7MB/s is fast enough for now
09:41 librin: it's odd, as I've been able to "restore" the low perf just fine, and did it twice to make sure
09:42 karolherbst: librin: odd
09:42 karolherbst: librin: well I also noticed increased perf, but mhhh
09:42 karolherbst: librin: couldn't revert to the old thing
09:42 karolherbst: maybe I did something wrong
09:42 mupuf: karolherbst: I managed to get the display controler fucked up after running metro 2033
09:42 mupuf: it entirely failed to run
09:43 karolherbst: librin: but my CPU is usually fast enough to keep up though
09:43 karolherbst: mupuf: oom
09:43 mupuf: karolherbst: possible
09:43 karolherbst: I am sure
09:43 karolherbst: I have a trace for that
09:43 karolherbst: it grabs like 16GB of virtual memory
09:43 karolherbst: and quits
09:43 karolherbst: no idea where the actual game stops
09:44 mupuf: AHAHA
09:44 karolherbst: well
09:44 karolherbst: it is inside the kernel somewhere
09:44 librin: karolherbst, I assume You did try turning every graphics setting to "low" / equivalent of "low"
09:44 karolherbst: librin: huh
09:44 librin: they added quite some more choices for that lately
09:44 karolherbst: librin: hell now, because then I am pcie bottlenecked
09:44 karolherbst: *no
09:45 librin: what GPU are we talking about here?
09:45 karolherbst: 770m
09:45 librin: *scratches head*
09:45 karolherbst: I ran like 40 fps with everything maxed out on nouveau :p
09:47 karolherbst: librin: I guess you set everything to low to see the perf difference?
09:47 karolherbst: librin: I guess that might make sense in that case then
09:49 librin: karolherbst, in my case, making it GPU bound takes a fair bit of effort. Performance hogs like AA and ambient occlusion don't cut it :V
09:49 karolherbst: meh, shadow of mordor can't be family shared... now I have to stay on this account
09:49 Calinou: DRM, DRM :)
09:49 karolherbst: librin: I see... well SMAA and SSBO high are helping
09:49 karolherbst: at least I can run payday 2 on the nouveau account :D
09:50 Calinou: http://xpfree.org/epsilon
09:50 Calinou: test this
09:50 Calinou: btw this has graphical artifacts even on nvidia driver, at Ultra settings
09:50 Calinou: might be a DarkPlaces bug though
09:50 Calinou: this is demanding enough to put a GTX 980M on its knees I believe, at 1920x1080
09:51 Calinou: use r_glsl_offsetmapping_reliefmapping 1; r_shadow_bouncegrid 1
09:51 Calinou: along with the standard Ultra settings, for absolute maximum graphics :P
09:55 karolherbst: librin: but you are right, it is really cpu bound
09:58 mwk: mupuf: yes on GF119 and up, no otherwise
09:58 mupuf: mwk: very very nice
09:58 mupuf: they may have locked it up though
09:58 mupuf: I will check tonight
09:58 mwk: on Maxwell, you mean?
09:58 mwk: possible
09:58 mupuf: yes
09:59 mupuf: we can use SOR[1], that would work
09:59 mupuf: or the older PWM regs in PNVIO may still work too
10:00 karolherbst: imirkin: with your locking code I got a deadlock after disabling vsync
10:00 karolherbst: I think
10:06 karolherbst: librin: yep 55->90fps
10:07 librin: karolherbst, mhm
10:08 karolherbst: well
10:08 karolherbst: but that doesn't matter when you really turn on every setting to max
10:09 librin: karolherbst, what really sux is the lack of benchmarking mode on PD2. Sure there are some levels with large enough *static* places where the scene can be mostly reproduced, but it takes way too much effort...
10:10 karolherbst: yeah
10:10 karolherbst: maybe we should ask the devs
10:11 karolherbst: librin: well I test in the safe house anyway
10:11 librin: karolherbst, 99% of people who actually want to play an first-person-shooter and play it well are ready to sacrifice any amount of eye-candy to get a good and stable framerate
10:11 karolherbst: mhh I am not one fo them :p
10:11 librin: so, for "real world scenario", having all at max is very unrealistic
10:12 karolherbst: huh
10:12 librin: not a hardcore gamer, I'd take it? ;]
10:13 karolherbst: well as long as I am above 30 fps I am usually happy :p
10:13 karolherbst: but usually I enjoy non fps games more
10:14 karolherbst: I am more the puzzle game type. Games like la-mulana are the best.
10:14 librin: yeah, for non-fps, err, non-shooters low framerate has a lot less impact
10:14 karolherbst: well
10:14 karolherbst: right
10:14 librin: a turn based strategy game can run at 10fps for all I care, just give me the eye-candy x]
10:14 karolherbst: though there are some action rpgs where this is quite important too
10:16 librin: varies quite a bit between FPS games. PD2 is perfectly fine at ~30 fps, as one can afford to take that sweet time aiming. In games like CSGO, 30 fps is considered unplayable and for a good reason.
10:18 karolherbst: *stupid reasons :p
10:19 karolherbst: I don't like csgo for the internal mechanics
10:20 karolherbst: and because usually you get away with software assisted mouse clicking scripts
10:26 librin: karolherbst, You mean, triggerbots? ;]
10:26 karolherbst: no, I mean like mouse scripts
10:27 karolherbst: librin: you are aware that the bullets hit in static patterns?
10:27 librin: yes
10:27 librin: of course
10:27 karolherbst: librin: and those mouse scripts move the mouse according to that and shoot automatically
10:27 librin: ah, recoil-remover
10:27 karolherbst: right
10:29 karolherbst: I really don't like that there is a static pattern to this, because then you can use "cheats" like this which can't be detected and it end ups being a game about how skilled you are with moving the mouse in a special pattern
10:29 librin: although, anyone worth their salt can spot those easily and distinguish it from learned recoil compensation
10:30 karolherbst: well, games without luck aren't games :p
10:30 karolherbst: (I know that's no true, but still)
10:30 librin: it has a fair bit of luck in it, though. As there's still bullet spread
10:30 librin: x]
10:30 karolherbst: :D
10:32 librin: and it's very much a team game. In my experience, between a disorganized bunch that can shoot well and a very well organized bunch having good strategy that can't shoot as well
10:32 librin: the latter wins most of the time
10:33 karolherbst: yeah, but it has a bigger "sport" aspect than a "game" one
10:33 librin: it's a competitive team sport... game.
10:33 librin: ;]
10:33 librin: can't deny that
10:34 librin: karolherbst, what CPU do You run, again?
10:34 karolherbst: i7-4700MQ
10:42 Tom^: karolherbst: cs:go changed the patterns from older counter strike and added a bit of randomisation.
10:42 Tom^: 1.6 you could entirerly rely on mouse scripts like you say. nowadays not so much
10:43 librin: now, "spinbots" are all the rage \_(:_/
10:49 mupuf: can anyone tell me a bit more about this special pattern you are talking about?
10:50 Tom^: mupuf: http://trs80-csgo.weebly.com/uploads/9/7/4/3/9743606/597937052.gif
10:50 mupuf: Tom^: AHAHAHAH
10:51 karolherbst: Tom^: yeah, thy have that splitted thing: static patterns + random accuracy penalties through movements or stuff like that
10:51 Tom^: indeed
11:13 karolherbst: mupuf: anyway, did you found some time to look over my iccsense patches? the min/max volt thing for hwmon got merged (which also means one patch of the reclocking stuff is merged too hehe)
11:15 mupuf: OMG, this DFS PLL is insane :o
11:16 karolherbst: pascal?
11:16 karolherbst: or maxwell?
11:16 mupuf: maxwell
11:16 mupuf: https://github.com/skeggsb/nouveau/commit/4330f7ec2fc6fc1fb9854c8b4db6fa08f20122d4
11:16 karolherbst: yeah it is :D
11:16 karolherbst: I really hoped we could move that into common code
11:17 karolherbst: anyway, parts of that might be needed for gk110+
11:18 karolherbst: and I am sure we have that speedo_id too somewhere
11:19 Rush__: just wondering, Is there any hope for reclocking for Quadro NVS 4200M?
11:19 karolherbst: well somebody is working on that
11:19 karolherbst: well fermi that is
11:20 karolherbst: best thing you can do is to wait or to use nvidia
11:20 RSpliet: Rush__: it's something I'm looking into in my spare time, but it's rather limited at the moment
11:20 Rush__: you mean nvidia adding stuff to nouveau? aren't they focused on Tegra only?
11:20 RSpliet: (my spare time that is)
11:20 karolherbst: RSpliet: no, I meant the nvidia driver
11:21 karolherbst: RSpliet: I guess it is your only gpu?
11:21 RSpliet: I have access to two, both GDDR5
11:21 Rush__: RSpliet: sounds good, I look forward to testing it then
11:21 RSpliet: Rush__: yeah, it might take a long while though
11:21 RSpliet: I have practically no time until the end of this month
11:22 karolherbst: mupuf: well at least I think ben will enable maxwell reclocking soon
11:22 Rush__: no worries, I think I won't be getting a new laptop any time soon. Basically all new thinkpads are crap so I'm stuck with this T420
11:22 karolherbst: mupuf: there are missing bits, but we also miss them for kepler, so there is really no reason to hold maxwell back
11:23 Rush__: new laptops have no redundant storage, here I have two SSDs on RAID-1 and a third one for Windows
11:23 Tom^: Rush__: +1 on that, which is why i refused a laptop payed from my job and bought myself a t60p secondhand instead.
11:23 Tom^: Rush__: xD
11:23 RSpliet: and after that... well, I'm close to bringing that Fermi to it's mid perflvl (incl memory), nouveau does nearly the same thing as nvidia, but I suspect NVIDIA is hiding something very important in their firmware that I still need to RE :-P
11:23 RSpliet: anyway, spare time I have today is spent putting out smaller fires
11:26 karolherbst: does anybody know if we reclock the engines correctly on maxwell? skeggsb_ said we might mess up the mapping from the vbios to the clock domains
11:26 karolherbst: but I thought they changed it in maxwell2 and not before?
11:27 RSpliet: karolherbst: never looked at that
11:28 karolherbst: mupuf: would it be possible to add your maxwell1 to reator?
11:29 mupuf: karolherbst: it would be possible, but you need to ask hakzsam
11:29 karolherbst: I see
11:29 karolherbst: mhh
11:30 karolherbst: and I might also want to look into the gk110 again... but maybe Tom^ could do that, because it shouldn't be that hard :p
11:30 karolherbst: well I am sure gnurous code tells us enough already
11:31 Tom^: last week of july i begin my 4 week vacation.
11:31 karolherbst: perfect then
11:31 Tom^: so if you need stuff done by then im free :p
11:34 karolherbst: ahh perfect
11:34 hakzsam: mupuf, karolherbst I'm running some piglits today on kepler to make sure we didn't introduce any regressions but you can plug the maxwell later today if you want
11:34 karolherbst: gnurou: thanks a lot :p
11:34 karolherbst: mupuf: so most likely we won't need the gk110 for now, the sensor stuff is pretty much done and the clock thing we can just take from the tegra code
11:35 mupuf: karolherbst: of course, I will have a look at your patches
11:35 karolherbst: Tom^: might trying something out running nvidia?
11:36 karolherbst: Tom^: *wanna
11:36 karolherbst: mupuf: thanks
11:36 Tom^: karolherbst: perhaps
11:36 karolherbst: Tom^: just run my nv_cmp_volt tool with a little patch applied
11:45 karolherbst: huh
11:46 karolherbst: Tom^: seems like it isn't there in the tegra code
11:46 karolherbst: odd
11:46 Tom^: ok
11:47 karolherbst: I am sure it would have been gk20a_pllg_calc_rate
11:47 karolherbst: but somehow...
11:49 karolherbst: mupuf: this part worries me: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/clk/gk20a.c#L31-L34
11:50 karolherbst: I am quite sure our code is correct, but we don't do this
12:01 Tom^: hm im all out of sata ports
12:02 Tom^: i wonder how slow it would be running a test install ontop of a usbstick
12:03 karolherbst: :O
12:03 karolherbst: I thought most boards have like at least 6 ports
12:03 Tom^: indeed
12:03 Tom^: and having 3 1tbs in raid0 and 2 60gb ssds, and now this 250gb samsung ssd.
12:03 Tom^: im all out :(
12:03 karolherbst: :D
12:04 karolherbst: those space problems
12:04 karolherbst: Tom^: is it hw raid0?
12:04 Tom^: nope
12:04 karolherbst: meh
12:04 Tom^: i dont dare doing such things, because motherboards breaks.
12:05 Tom^: and i rather see my data go bye bye only when the disk dies. :P
12:09 Tom^: yea il figure something out later, now food. and some game of thrones. karolherbst just pm or highlight me here with what you need tested and il see if i work something together later today
12:11 RSpliet: karolherbst: you can test that with nvatiming if you feel like it, but do we generate diviers as high as that?
12:11 RSpliet: *diviers
12:11 RSpliet: ... >_<
12:11 RSpliet: *dividers
12:13 karolherbst: RSpliet: well that's not _the_ issue
12:14 karolherbst: more like that every value means something else already
12:15 karolherbst: but maybe it is indeed a bit different for us...
12:16 RSpliet: idk, I get the feeling it's the same for small values for us
12:17 karolherbst: well there is this +1 offset
12:17 karolherbst: if 2 is in the reg, it means 3
12:18 karolherbst: or the other way around?
12:18 karolherbst: anyway, the clocks in nvatiming on my gpu are the same on nouveau and nvidia
12:19 karolherbst: but maybe that has changed with gk110+
12:19 karolherbst: let me check
12:23 karolherbst: huh
12:23 karolherbst: it would be interessting if I would see p being not 1
12:23 karolherbst: ...
12:25 karolherbst: Tom^: okay, here is what I need:
12:26 karolherbst: Tom^: nvapeek 137000 0x20 for different temperatures + the clock displayed in nvidia-settings
12:26 karolherbst: wait, maybe we can automate things
12:29 karolherbst: ahh nice
12:38 karolherbst: Tom^: for i in {104..0}; do echo "at $i °C"; nvaforcetemp $i; vblank_mode=0 __GL_SYNC_TO_VBLANK=0 timeout 1s glxgears > /dev/null; sleep 1; nvapeek 137000 0x20 ; nvidia-settings -c :8 --query GPUCurrentClockFreqs; done
12:38 karolherbst: ... maybe lower max temp
12:38 karolherbst: Tom^: for i in {95..0}; do echo "at $i °C"; nvaforcetemp $i; vblank_mode=0 __GL_SYNC_TO_VBLANK=0 timeout 1s glxgears > /dev/null; sleep 1; nvapeek 137000 0x20 ; nvidia-settings -c :8 --query GPUCurrentClockFreqs; done
13:14 Doctors: imirkin; after further testing I'm starting to notice this happen after a few minutes on certain applications. http://paste.ee/p/L1OGS#ZNFxGX6uNLsAwyT5ZLNCXOh4TGyvxTTy Sometimes this will cause a freeup on the application, other times it starts freezing my entire computer. This is non-exsistent outside of the patched version
13:14 zeq: Hi again. I've recently been gifted a GTX 8800, not exactly a new card, but it was very high end gaming card at the time of release, and given NV50 (G80) is fully supported vs my attempts to get things going with NV35 I'm pretty confident that it can be put to some use with Nouveau.
13:14 zeq: So I've got it up and running with a new Gentoo/KF5 build, only, of course there's no reclocking enabled for Tesla cards pre-G94! So I toggled the reclocking bool on nv50_clk_new_()...
13:14 zeq: The pstate contains just "20" [this has the standard high clocks as listed by nvidia] and "AC" entries, there doesn't seem to be an entry for actual boot clocks. However writing 20 to pstate it seems to reclock sucessfully. I've no idea if all the clocks get set correctly, but performance is multiple times faster. No way to down clock again though...
13:18 zeq: I do get this in my log after reclocking:
13:18 zeq: nouveau 0000:05:00.0: fb: invalid/missing rammap entry
13:32 karolherbst: only one GB left..
13:38 karolherbst: hakzsam: okay, so you wanted a trace of the game?
13:39 hakzsam: if you see rendering issues, yes
13:39 karolherbst: okay
13:39 karolherbst: so I just check the beta branch and if everything is fine we just wait until it gets deployed for everbody else
13:41 karolherbst: stupid intros, can't skip em
13:44 karolherbst: uhh it crashed
13:44 karolherbst: ahh
13:44 karolherbst: nice
13:46 karolherbst: RSpliet: I guess we can't have this: 31: mad u32 $r4 $r2 0x0019660d $r4 (8)
13:47 karolherbst: ohh compute shader
13:47 RSpliet: karolherbst: what arch are you talking about?
13:47 karolherbst: RSpliet: setImmediate fails
13:48 RSpliet: zeq: I don't think NVIDIA ever downclocks that card after setting those speeds
13:48 karolherbst: Assertion `(u32 & 0xfff00000) == 0 || (u32 & 0xfff00000) == 0xfff00000' failed.
13:48 hakzsam: karolherbst, make a trace :)
13:48 karolherbst: hakzsam: nah, it is my mistake
13:48 RSpliet: but a missing rammap entry probably implies everything scales apart from DRAM
13:48 hakzsam: karolherbst, you didn't try with master?
13:49 karolherbst: hakzsam: nope
13:49 zeq: RSpliet: so it's very close to working then?
13:49 RSpliet: zeq: so close yet so far :-P
13:49 RSpliet: I don't have time to look into clock changing at the moment
13:49 RSpliet: sorry
13:50 RSpliet: but there are known problems
13:50 zeq: RSpliet: okay, let me know if there's anything I can do to help.
13:50 karolherbst: okay, yep, the emitter is anyoed by mad u32 $r4 $r2 0x0019660d $r4
13:50 RSpliet: zeq: your VBIOS and a trace of the official driver is a good start. I don't own a working 8800 myself
13:51 RSpliet: there's wiki pages to help you obtain those, send them to mmio.dumps@... (should be on the wiki as well)
13:51 zeq: RSpliet: My Fermi is in a similar state with no memory reclocking
13:51 RSpliet: zeq: I know, and I have equally no time to sort that out. Fermi reclocking is a WIP and I believe I have 75% of it now
13:51 zeq: RSpliet: I'll see what I can do.
13:52 RSpliet: unfortunately, clock changing is very much a hit or miss, it either works or it doesn't, it doesn't like work 75% or something :-P
13:52 zeq: RSpliet: may still be worth white-listing where it works?
13:52 karolherbst: hakzsam: I need to test my passes and see where stuff crashes, when I am sure nothing breaks I can start trying to get those merged :p
13:53 RSpliet: zeq: no that's not going to win you a lot on Fermi
13:53 RSpliet: most workloads are memory-bound, and that bit doesn't work at the moment
13:53 RSpliet: (and no, it also doesn't work with my WIP)
13:53 hakzsam: karolherbst, sure, but it still crashes :p
13:53 karolherbst: yeah, but it was my fault :p
13:54 karolherbst: okay
13:54 karolherbst: that's now not my fault
13:54 karolherbst: ShadowOfMordor: ../../../src/mesa/main/teximage.c:822: init_teximage_fields_ms: Assertion `img->_BaseFormat != -1' failed.
13:54 zeq: RSpliet: is it a lack of information about what the registers mean, or sequencing... or???
13:54 karolherbst: hakzsam: I guess you want a trace from that?
13:54 hakzsam: karolherbst, yep
13:54 RSpliet: zeq: that certainly doesn't help, but it's also very much a matter of time
13:54 karolherbst: hakzsam: I am using highest settings though, so it might be a bit slow to replay
13:55 karolherbst: mhh
13:55 karolherbst: I could see if it also happens on lower settings...
13:55 RSpliet: I'm a PhD student doing mostly non-nouveau related stuff, not a full time employed nouveau-codemonkey
13:55 RSpliet: free time does not appear in the vocabulary of a PhD student ;-)
13:55 hakzsam: karolherbst, and please use a low resolution :)
13:55 zeq: RSpliet: I really don't understand why NVIDIA doesn't make the reclocking information available, especially for legacy hardware where nouveau is really the only option.
13:56 mupuf: RSpliet: not in the mind of phd supervisors :D
13:56 mupuf: zeq: because who wants to write accurate documentation for older platforms?
13:56 karolherbst: hakzsam: actually 2.8 GB isn't that bad :D
13:56 mupuf: what money would they get out of it
13:56 karolherbst: we
13:56 karolherbst: ll I will lower the res
13:56 RSpliet: zeq: and in part because they might use 3rd party PHYs and PLLs and such, for which they do not have the right to publish documentation
13:57 karolherbst: zeq: IP :p
13:57 zeq: Yeah, would be good PR though.
13:57 karolherbst: and useless
13:58 karolherbst: it would most likely not cover the increased costs
13:59 karolherbst: and to be honest in a few years nobody will bother that much anyway. kepler cards will be cheap by then (especially after pascal is common use) and on kepler we are pretty far already
13:59 zeq: I would never consider buying a new NVIDIA card due to the lack of nouveau support from them.
13:59 iterati: karolherbst: hi. For 6.1 kernel & gtx650 the preferred driver is https://github.com/karolherbst/nouveau/tree/stable_reclocking_kepler_v5 ?
13:59 karolherbst: well and the future doesn't look that bright
13:59 zeq: I'm sure I'm not the only one.
13:59 karolherbst: iterati: 6.1 kernel?
14:00 iterati: 4.6.1 I mean
14:00 karolherbst: ahh
14:00 karolherbst: as long as it is a kepler and you have instabilities with stock nouveau, yes
14:01 iterati: yeah, I can't reclock it with the upstream one. I use 4.6 with the above now and reclocking works
14:02 zeq: karolherbst: it's not really about the money to me. I build systems from old hardware where it's still useful. I also buy new hardware, but I only buy what is well supported by FOSS.
14:02 karolherbst: ahh right
14:02 karolherbst: iterati: voltage error I think?
14:03 karolherbst: zeq: yeah I understand, but usually if you want performance you also want newer gpus. usually
14:03 iterati: karolherbst: yeahs, something like failed to adjust voltage, error -22
14:04 karolherbst: zeq: it is no reason to not fix the issue, I am just saying that not that many actually care about such issues and that it may be a long process to figuring all out while the report rate decreases
14:04 zeq: karolherbst: I totally get the limited time/resources, I know you all do an incredible job.
14:04 karolherbst: zeq: and with "nobody" I meant the users. Obviously we care a lot about all issues :p
14:05 zeq: IMHO, nouveau is most useful where the hardware at least runs at full speed though! ;-)
14:05 karolherbst: totally
14:06 karolherbst: ask Tom^ :p
14:06 Tom^: my philosophy is to buy enough new hw to compensate for the slower opensource drivers.
14:06 karolherbst: hakzsam: I deleted the game binary by mistake and have to validate those files now, could take a while
14:06 Tom^: =D
14:06 karolherbst: :D
14:06 karolherbst: Tom^: try that wth 980 Tis
14:06 zeq: Tom^: I really couldn't justify that approach! :-)
14:08 zeq: To the degree that I have a Matrox Mystique 220 in the server here sitting next to me! Useful. :-) (Would be even more useful if the BIOS would let the system boot without an VGA, but I digress...)
14:09 iterati: why not implement the voltage raise fix upstream ? I'ts not stable or accurate yet ?
14:10 karolherbst: iterati: well
14:10 karolherbst: iterati: if you look at the branch you see a lot of patches
14:10 karolherbst: hard to seperate things because they have to be applied all at once basically
14:10 karolherbst: otherwise users end up running into undervolting issues
14:10 karolherbst: or something else
14:11 hakzsam: karolherbst, :/
14:11 iterati: also I get have this issue when using vdpau with mpv: https://github.com/mpv-player/mpv/issues/2798
14:12 iterati: someone claims that "FYI the messages mean that nouveau is (mistakenly) allocating a 0-sized buffer."
14:12 karolherbst: iterati: imirkin somehwat worked on that I think
14:13 imirkin: karolherbst: did you get a backtrace of the deadlocked threads?
14:13 karolherbst: imirkin: well, the issue was that my build was also corrupted, will check it if this also occurs after a clean biuld
14:14 karolherbst: imirkin: and as I thought it works now
14:15 karolherbst: that build system... :p
14:15 imirkin: karolherbst: well ... deadlocks aren't 100% reproducibel usually
14:15 karolherbst: well
14:15 karolherbst: it happens like 4 times in a row
14:15 imirkin: "it" = "no deadlock"?
14:15 karolherbst: nope the deadlock
14:16 imirkin: can i get a backtrace? :)
14:16 karolherbst: no, I meant it happend that often with the corrupted build
14:16 imirkin: oh
14:16 karolherbst: when I rebase too far away and headers are changing, not everything required gets rebuilt
14:16 imirkin: well the locking strategies are a bit inter-related
14:16 karolherbst: and your locking code is my top commit
14:16 karolherbst: right
14:17 imirkin: so if you have some but not all of it, that won't be great
14:17 karolherbst: exactly
14:17 karolherbst: that was my thought too
14:17 karolherbst: anyway, if that continue to annoys me that much, I will end up fixing that build system at one point :D
14:20 Doctors: imirkin; Did you see what I said earlier?
14:21 imirkin: Doctors: yes
14:21 imirkin: Doctors: were there more lines? but either way, stuff like that can happen... and unfortunately we don't handle that super-well
14:21 imirkin: Doctors: you should see something in dmesg too
14:22 Doctors: imirkin; There was more lines, but it seemed like a lot of spam, I can post them if you need them.
14:22 Doctors: I'll dmesg then when it happens and get you what it says
14:24 imirkin: Doctors: the lines that came after were the commands being sent that ended up getting discarded
14:24 Doctors: ahh
14:24 Doctors: I just ignored them because it was spamming me, will send them once I trigger it then.
14:26 imirkin: Doctors: well, it's unlikely i'll be able to do anything to fix it
14:26 imirkin: Doctors: are you getting that now with my locking patch in applications that used to work fine?
14:31 karolherbst: hakzsam: ... now it doesn't crash anymore
14:31 Doctors: imirkin; It works fine for the first few minutes for after a certain point ethier that starts happening or my system hard freezes
14:33 imirkin: Doctors: and it didn't happen before? or the application died much sooner?
14:33 hakzsam: karolherbst, what did you change?
14:33 karolherbst: no idea
14:33 Doctors: imirkin; It didn't happen before.
14:33 karolherbst: ah
14:33 karolherbst: now I got something funny
14:34 karolherbst: hakzsam: https://gist.github.com/karolherbst/3a2f9f4ca283e2db59dbde65b6bee9e0
14:35 hakzsam: OOR_ADDR --> this is new
14:35 hakzsam: imirkin, ^
14:35 karolherbst: yay
14:35 karolherbst: reproducible!
14:35 imirkin: hakzsam: no, that's just ben's new name
14:35 imirkin: hakzsam: for out-of-range address or soemthing? double-check his renaming commit
14:35 hakzsam: imirkin, yeah, I know, this is from the gk20a headers
14:36 imirkin: i think it's MEM_OUT_OF_BOUNDS
14:36 hakzsam: GPR_OUT_OF_BOUNDS
14:36 hakzsam: err
14:36 hakzsam: MEM_OUT_OF_BOUNDS ;)
14:36 karolherbst: hakzsam: mhh it might be related to the resolution...
14:38 hakzsam: huh, why?
14:38 karolherbst: because on lower resolutions I don't get the crash
14:38 karolherbst: or it might be something else
14:39 Doctors: imirkin; dmesg tail https://paste.ee/p/fq134#mWfbxQMAXWw1laBl1bTmbUc2pHaVEuTx
14:40 karolherbst: hakzsam: yep, happens at 1920x1080 but not at something really low
14:40 hakzsam: what about the mesa error you got?
14:41 karolherbst: "kernel rejected pushbuf: Device or resource busy"
14:41 karolherbst: and the one error I track has something todo with the texture settings
14:45 Doctors: imirkin; everything I see in console until I kill it. https://paste.ee/p/TIdy8
14:47 karolherbst: hakzsam: stupid... it doesn't show on retrace...
14:50 karolherbst: hakzsam: well yeah, no idea, seems like you need to download the game because the trace won't show it
14:50 karolherbst: ...
14:51 hakzsam: you can reproduce the issue with the trace?
14:51 hakzsam: weird
14:51 hakzsam: *coun't
14:51 hakzsam: *can't
14:52 karolherbst: yep
14:55 Doctors: imirkin; After some testing I can get it to work correctly by disabling all shaders.
15:50 karolherbst: hakzsam: uhh, the settings I use they say I need like 6GB of vram...
15:50 hakzsam: awesome :)
15:51 karolherbst: I guess this could be a simple oom situation
15:56 karolherbst: I think we need to start to provide games with information about used vram :/
15:57 karolherbst: hakzsam: "multiple instances of buffer 7 on validation list"
15:58 karolherbst: and in mesa "Wait on fence 245542 (ack = 245530, next = 245542) timed out !"
15:59 hakzsam: anything in dmesg?
16:00 Tom^: karolherbst: gallium hud and see if you do run out of vram
16:01 imirkin: Doctors: what was the error in dmesg?
16:04 karolherbst: hakzsam: https://gist.github.com/karolherbst/e71a39f4bda4fd6f01dfdbeea59a24aa
16:04 hakzsam: I have never seen that
16:06 karolherbst: hakzsam: you now that you get like multiple windows in glretrace?
16:07 hakzsam: yep
16:07 karolherbst: I have 180 now
16:07 karolherbst: quite the fun
16:07 karolherbst: maybe the issue triggers on GPUs with less vram within the trace
16:07 karolherbst: hakzsam: you have like 1GB, right?
16:08 hakzsam: 1 or 2GB, I don't remember to be honest
16:08 karolherbst: well best I show you the issue
16:09 karolherbst: it's a bit odd
16:09 karolherbst: because the screen gets corrupted, but normalizes later
16:09 Doctors: imirkin; https://paste.ee/p/fq134#mWfbxQMAXWw1laBl1bTmbUc2pHaVEuTx
16:09 karolherbst: maybe something odd to texture loading or something silly
16:09 hakzsam: karolherbst, I definitely can't test that game at home, but I could try this week at work
16:09 karolherbst: due to space?
16:09 hakzsam: and due to my poor GF119 :)
16:09 karolherbst: :D
16:09 karolherbst: well
16:09 karolherbst: I could give you the trace
16:10 hakzsam: that might help yeah
16:10 karolherbst: it's 3.6GB big, but nothing I can do about that. The issue hit like multiple times though so maybe it will work out
16:10 orbea: lol @ paste.ee javascript based encrypted pastes...what exactly si the point?
16:10 karolherbst: orbea: none
16:11 karolherbst: orbea: shitty devs can't deal with encoding :p
16:11 orbea: heh
16:22 RSpliet: (had anyone already dropped https://images.nvidia.com/content/pdf/tesla/whitepaper/pascal-architecture-whitepaper.pdf ?)
16:23 karolherbst: doubt it
16:24 karolherbst: or maybe
16:24 karolherbst: sounds familiar
16:24 RSpliet: wouldn't be surprised, could contain some relevant little details
16:26 zeq: RSpliet, karolherbst: So what do I have to do with my GTK 8800 to get the needed memory reclocking info? Install nvidia proprietary driver, envytools? And then..?
16:27 RSpliet: get an MMIOTrace of X.org starting
16:37 zeq: RSpliet: okay, rebuilding the kernel with mmiotrace enabled...
16:39 karolherbst: hakzsam: I think the game just does heavy threading and this causes multiple issues within mesa :/
16:39 karolherbst: https://gist.github.com/karolherbst/b1218fbeca6ffee80f3f3a0328cc12c1
16:40 karolherbst: they have sevel "OpenGL Dispatch" threads
16:40 karolherbst: and Thread ids above 300
16:56 gregory38: karolherbst: hello
16:57 gregory38: For perf you need -fno-omit-frame-pointer otherwise stack/symbol are useless
16:57 gregory38: And I have a question for you on the fan configuration
16:58 gregory38: What is implemented currently half-speed in low reclocking level and full-speed in faster mode ?
16:59 gregory38: basically I'm around 800 currently. But if reclock the GPU, it doesn't get back and instead remains to 1400-1500
16:59 mupuf: karolherbst/imirkin/hakzsam: got a new trace with the fixes from feral
17:00 mupuf: oh, it is also much smaller
17:00 mupuf: and the game is now 64 bits
17:01 hakzsam: karolherbst, I was thinking about a concurrency issue too
17:01 hakzsam: mupuf, nice
17:02 mupuf: uploading
17:03 karolherbst: mhhh
17:03 karolherbst: mupuf: did you try to replay?
17:03 mupuf: karolherbst: yes
17:03 mupuf: the first trace failed
17:03 mupuf: the second worked
17:03 mupuf: replay at 65 fps :D
17:03 karolherbst: I se
17:03 karolherbst: :D
17:04 mupuf: let's see how it works without it
17:04 karolherbst: where is the trace?
17:04 mupuf: karolherbst: I am pushing it to my server
17:04 karolherbst: I see
17:04 karolherbst: the ftp stuff?
17:05 mupuf: we have an ftp for traces? If so, I will move it there
17:05 karolherbst: mhh no idea
17:05 karolherbst: I thought we did
17:05 karolherbst: either way I wouldn't know how to connect
17:06 mupuf: hehe
17:06 mupuf: I will give you the link
17:06 mupuf: but ... you need to wait, it is 3.5 GB
17:07 mupuf: (as opposed to 8.1 GB for just the first first few frames)
17:07 karolherbst: :O
17:07 mupuf: I guess capturing errors on all calls is taking a lot of space
17:07 karolherbst: what did you do to trigger the issues?
17:11 karolherbst: what is wrong with my gpu today....
17:13 mupuf: karolherbst: you do not need to do anything
17:13 mupuf: just have an up to date driver
17:13 karolherbst: mhh odd
17:13 mupuf: you do not have this bug?
17:13 mupuf: what version do you have?
17:13 karolherbst: well I have weird bugs
17:13 karolherbst: but nothing I can reproduce
17:14 karolherbst: like after I set everything to ultra and played with the texture quality settings, things got messed up for a while
17:14 karolherbst: but now when I try that, the game just crashes
17:14 karolherbst: ...
17:14 karolherbst: it crashes quite often actually
17:16 karolherbst: okay something in recent master broke something
17:16 karolherbst: I get like traps now instantly
17:24 karolherbst: gregory38: regaring fan: we don'T really do the same thing nvidia does
17:29 mupuf: mwk: should I change anything else but the SPECIAL_IDX in PGPIO to change where the GPIO is connected to?
17:35 karolherbst: mupuf: trying to control the gm20x fan through magic now?
17:35 mupuf: karolherbst: quick check, yes
17:36 gregory38: karolherbst: ok, wjo is responsible to manage it ? The kernel ?
17:36 karolherbst: yeah
17:38 gregory38: ok Thanks
17:39 karolherbst: we know about the issue though
17:39 karolherbst: I am pretty sure we know where to look for it, but that require some time and nvidia being nice enough reporting the fan speed...
17:40 gregory38: I understand, it is the same they don't opensource the power-management stuff. It isn't like it could be useful to any of their competitors
17:41 karolherbst: mupuf: but I really don't want to play the game of finding hacks going around that secure stuff... just so that we can keep working ...
17:43 karolherbst: friggin shit...
17:43 karolherbst: Shadow of Mordor 3840 x 2160 - Ultra Quality: GeForce GTX 1080: 21.02 / 51.06 / 72.61
17:44 karolherbst: and the benchmark run at like 8 fps for me
17:44 karolherbst: on fullhd
17:44 mupuf: karolherbst: ahah
17:44 mupuf: on the blob, right?
17:44 karolherbst: nouveau
17:46 karolherbst: well the benchmark run once... otherwise I got locks or crashes or other stupid things
17:48 mupuf: karolherbst: on your machine, but what about the GTX 1080
17:48 karolherbst: ahh
17:48 karolherbst: nvidia
17:48 karolherbst: of course :p
17:49 mupuf: yeah
17:49 mupuf: but I was wondering where you got this, and now I see the phoronuix article
17:49 karolherbst: yeah
18:00 mupuf: ah, everything is much clearer after dinner
18:00 mupuf: ok, read a bit more, and there is a commit reg
18:02 karolherbst: ;D
18:13 karolherbst: imirkin: crap... my liveOnlyTex pass Traps the gpu...
18:26 mupuf: karolherbst: does not seem to work very well on the GPIO for the fan
18:26 mupuf: I mean, I can write values but I do not see the GPIO changing
18:26 dcomp: lastlog 840m
18:26 mupuf: maybe I need to change the ownership of the GPIO
18:27 mupuf: and this ... is part of pdaemon
18:27 mupuf: and is likely a registered reg
18:27 mupuf: the ownership was already there for i2c, so they may have extended it
18:30 mupuf: mwk, karolherbst: it does not look good for the fan :s
18:37 karolherbst: meh
18:37 karolherbst: mupuf: I guess even on high temp nothing happens?
18:38 mupuf: I can try
18:38 mupuf: karolherbst: nothing changes
18:40 karolherbst: sad
18:42 karolherbst: so we really need those pmu firmware files :/
18:51 karolherbst: mhh I also got "[MULTIPLE_WARP_ERRORS] warp 20014 [DIVERGENT]" toda
18:51 karolherbst: y
18:58 karolherbst: this entire thing smells like threading issues
18:59 karolherbst: game -> SDL2 -> MakeContextCurrent ->
18:59 karolherbst: and then it messes up destroying the context
19:00 Yoshimo: pmu firmware, mhmm when did they publish maxwell firmware part 1?
19:08 imirkin_: karolherbst: did you get that error with my patch in place?
19:09 karolherbst: not quite sore, but I think so
19:09 karolherbst: just noticed it much later
19:09 karolherbst: ahh the mordor crash
19:09 karolherbst: yes
19:09 karolherbst: for sure yes
19:09 imirkin_: hrmph ok
19:10 imirkin_: i guess i missed a spot
19:10 imirkin_: i knew that fence work stuff could cause problems =/
19:10 karolherbst: imirkin_: https://gist.github.com/karolherbst/8cee41315389dc8d7ddbd2180005065b
19:10 imirkin_: i might need to think a little harder
19:11 imirkin_: karolherbst: please try to look at other threads
19:11 imirkin_: and see if they're in nouveau or not
19:13 karolherbst: imirkin_: that's from another crash though: https://gist.github.com/karolherbst/ba37ef749b7fb9014488bf2bb9924866
19:14 imirkin_: GAH
19:14 imirkin_: ok, i messed up
19:14 imirkin_: i think.
19:14 imirkin_: well, i definitely messed up.
19:14 imirkin_: the question is how. need to think.
19:14 imirkin_: thanks for that
19:17 Doctors: imirkin; Did you get the dmesg?
19:17 imirkin_: Doctors: if it's in the scrollback, i'll see it
19:18 Doctors: imirkin; It's the last msg I sent you, the paste.ee
19:18 imirkin_: ok. i'll look at it tonight or ... when i get to it
19:18 imirkin_: it's unlikely that my locking patch makes that sort of thing worse
19:22 karolherbst: imirkin_: do you have an updated commit already about the one locking issue we found yesterday (or even before?)
19:23 karolherbst: ahh
19:23 karolherbst: you've updated that
19:23 imirkin_: karolherbst: yeah, so i drop locks in nouveau_fence_wait()
19:23 imirkin_: but i suspect that i have to acquire something in nouveau_fence_update()
19:23 imirkin_: and i don't? i forget
19:23 imirkin_: can't really look now
19:25 karolherbst: imirkin_: should I test ontop of your entire nv30 branch or is the one commit enough?
19:25 imirkin_: karolherbst: the one commit is enough
19:25 karolherbst: that warsow patch though
19:25 karolherbst: :D
19:25 imirkin_: you like that? :)
19:26 karolherbst: awesome work
19:26 imirkin_: they just do a strcmp
19:26 imirkin_: or strstr, i forget
19:31 karolherbst: imirkin_: just for reasons of "cleanless": https://gist.github.com/karolherbst/bf2a4f4437df40c114fa134773325136
19:31 karolherbst: newest version of your patch
19:31 karolherbst: clean build
19:31 karolherbst: I could have messed up earlier
19:32 karolherbst: but I like it how they all look differently
19:32 imirkin_: karolherbst: that's a different issue
19:32 karolherbst: well
19:32 karolherbst: I can't choose what happens
19:32 karolherbst: I always do the same in the game
19:32 imirkin_: :)
19:32 karolherbst: to be safe just think about the last one and we will see where this will get us
19:33 karolherbst: as I can't guarantee I didn't messed up before
19:33 imirkin_: well, that one is a result of some past failure
19:33 imirkin_: so unfortunately that backtrace provides no real information
19:33 karolherbst: I can create more if you want
19:33 imirkin_: besides "ha ha, you messed up earlier"
19:33 karolherbst: uhh right
19:33 karolherbst: nouveau messed up
19:33 imirkin_: right
19:34 karolherbst: HCE_ILLEGAL_MTHD
19:34 karolherbst: whatever that is
19:34 imirkin_: but that backtrace doesn't indicate the screwup
19:34 karolherbst: okay
19:34 imirkin_: just the fact that a screwup existed at some earlier point
19:34 karolherbst: then I create new ones
19:43 karolherbst: currently in gdb with this: https://gist.github.com/karolherbst/ced1b826fa3dc1343be0d0eff8bc069a
19:44 hakzsam: imirkin, what's that p[] addr space in GS?
19:46 karolherbst: hakzsam: https://drive.google.com/open?id=0B78S7GSrzebIdXF4U1FTZENmUUU
19:48 karolherbst: I really can't capture that in a trace
19:48 karolherbst: it is most likely also due to a multithreading issue
19:48 karolherbst: at least that would explain that
19:48 hakzsam: can't download right now
19:48 hakzsam: google is processing the video
19:48 karolherbst: ahh still...
19:48 karolherbst: now it works
19:49 hakzsam: yep
19:49 hakzsam: watching :)
19:49 hakzsam: outch...
19:49 karolherbst: yeah
19:50 hakzsam: I won't have a look today because I'm fixing some new piglit tests which fail :)
19:50 karolherbst: I like it how the state is repaired after resizing the window though
19:50 hakzsam: tomorrow, maybe
19:50 hakzsam: yeah, weird
19:54 imirkin_: hakzsam: you mean like on nv50?
19:55 hakzsam: I don't know about nv50, I'm looking at nvc0
19:55 hakzsam: I have one geom shader which uses p[]
19:55 imirkin_: right
19:55 imirkin_: so that gets you the lane for the vertex
19:56 imirkin_: and then you feed it to a load instruction so that it knows where to fetch from
19:56 hakzsam: imirkin_, okay, and what's the input argument of p[]?
19:56 karolherbst: imirkin_: is the new trace usefull?
19:56 imirkin_: this makes a bit more sense when you look at the nvdisasm output
19:57 imirkin_: karolherbst: grrrr. yes.
19:57 hakzsam: imirkin_, /*0000*/ VILD R5, v[0x1]; /* 0x0000000007f15c06 *
19:57 karolherbst: k
19:57 imirkin_: that STINKS
19:57 hakzsam: vertex input load I would say :)
19:57 imirkin_: hakzsam: right
19:57 karolherbst: I can do plenty more if you like that :p
19:57 imirkin_: hakzsam: it's basically the vertex base pointer
19:57 imirkin_: karolherbst: no, i hate things that stink
19:57 imirkin_: including, but not limited to, this one
19:58 hakzsam: imirkin_, okay
19:58 imirkin_: hakzsam: then if you look, it'll probably do ALD rx, a[0xabc], R5
19:58 imirkin_: which will load vertex attribute 0xabc from the 2nd vertex input to the GS
19:59 hakzsam: makes sense
19:59 imirkin_: similar deal for tess, of course
19:59 hakzsam: I have never looked at tess, but I will need to (for maxwell) :)
19:59 imirkin_: there's an additional complication if you want to do like ALD rx, a[R0+0x80]
20:00 imirkin_: which on fermi works just like that
20:00 hakzsam: but right now, I'm looking at the arb_gpu_shader_fp64 fails
20:00 imirkin_: but on kepler, you need to do
20:00 imirkin_: AL2P rx, a[R0+0x80]
20:00 imirkin_: ALD.PHYS ry, a[rx]
20:00 hakzsam: oh okay
20:00 imirkin_: so i introduced an "AFETCH" instruction in nv50 ir
20:01 imirkin_: which corresponds to the AL2P thing
20:01 hakzsam: okay, I see
20:02 imirkin_: but just like PFETCH fetches the vertex base address in the primitive
20:02 imirkin_: AFETCH fetches the "physical" shader input address
20:02 hakzsam: so, AFETCH is for kepler+ only?
20:04 hakzsam: imirkin_, and I guess, "out emit" is used to return values from a geom shader?
20:04 imirkin_: hakzsam: yes, AFETCH is for kepler only. for maxwell, chances are something else may be necessary, not sure. i haven't super-tested
20:05 imirkin_: hakzsam: out emit = take the previously stored value for all the vertex attributes, and write them out to the specified vertex stream
20:05 imirkin_: out cut = "send a primitive cut operation to the specified vertex stream"
20:06 hakzsam: okay, thanks
20:06 imirkin_: [and you may want to glance at how geometry shaders operate for a clearer understanding of wtf i'm talking about]
20:10 hakzsam: sure :)
20:10 hakzsam: this will be required for fixing those arb_gpu_shader_fp64 fails
20:10 imirkin_: errr
20:10 imirkin_: really?
20:11 hakzsam: well, I guess and learning is good
21:26 hakzsam: airlied, any ideas why this test fails http://hastebin.com/xemuhuhocu.avrasm because it used to work. Something is probably not totally correct in st_glsl_to_tgsi
21:27 imirkin_: wait, that *used* to work? are you sure? i think it's a new test...
21:27 imirkin_: airlied: for some reason it picks IMM[1] for the 3rd compare instead of staying with IMM[0]
21:27 hakzsam: the test is new, but you said that conversion from doubles to booleans used to work :)
21:28 imirkin_: oh, sure, in general - and it still does. this is just something weird going on.
21:33 airlied: uggh, no idea why, but yes something in st_Glsl_to_Tgsi
21:41 karolherbst: hehe, compiling mesa with scan-build :D
21:42 karolherbst: maybe we could teach static analyzers about code that has to be locked and they may tell us where we have to, allthough I really doubt they are _that_ smart already
21:56 karolherbst: huh
21:59 imirkin_: there's no way that any static analyzer would like my locking logic.
21:59 karolherbst: well
21:59 imirkin_: i don't think they like it when functions unlock and then lock, rather than vice-versa :)
21:59 karolherbst: it is smart about dead assignements though
22:00 hakzsam: you might want to try helgrind
22:00 hakzsam: it's a pretty good tool for that
22:00 karolherbst: this looks pretty dead to me: https://github.com/karolherbst/mesa/blob/master/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp#L444-L445
22:00 karolherbst: hakzsam: well at least scan-build is _really_ easy to use,
22:01 hakzsam: helgrind is too, once you understand the output :)
22:01 Rush__: clang has pretty good tools to debug threads, locking etc. it automatically inserts instrumentation code to the binary itself
22:01 karolherbst: but I think typeOfSize is so cheap, this call won'T matter
22:01 karolherbst: and compiler will optimize it away I guess
22:01 karolherbst: maybe not
22:02 Rush__: http://clang.llvm.org/docs/ThreadSanitizer.html
22:03 karolherbst: Rush__: ahh so you build with clang and run your binariy
22:03 imirkin_: karolherbst: who knows. it's not hurting anyone.
22:03 karolherbst: imirkin_: yeah, I know
22:03 karolherbst: I will keep digging until I find something serious
22:04 Rush__: karolherbst: yep. It's much more practical than valgrind/helgrind as 10x performance penalty is quite managable.
22:04 karolherbst: well
22:04 karolherbst: for games it sucks
22:04 Rush__: valgrind is 100x and helgrind probably 1000x penalty :D
22:04 Rush__: it's 100% emulated CPU
22:05 karolherbst: "Branch condition evaluates to a garbage value"
22:05 karolherbst: that sounds serious
22:05 karolherbst: any known issues with TGSI_OPCODE_RESQ?
22:08 karolherbst: I get that message herE: https://github.com/karolherbst/mesa/blob/master/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp#L3519
22:09 imirkin_: karolherbst: hmmmmm
22:09 imirkin_: that's unexpected
22:10 karolherbst: if line 2900 is false
22:10 airlied: imirkin_, hakzsam : d2b needs some special casing
22:10 karolherbst: it might happen
22:10 airlied: will look later
22:10 imirkin_: karolherbst: oh hm. i think i see what's going on
22:10 karolherbst: yeah
22:10 karolherbst: dstCount is 0
22:11 karolherbst: no clue if that could happen though
22:11 hakzsam: airlied, mmh
22:13 karolherbst: same thing here: https://github.com/karolherbst/mesa/blob/master/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp#L2692
22:17 hakzsam: imirkin_, airlied except this conversion from doubles to ints, all arb_gpu_shader_fp64 are now fixed
22:19 karolherbst: mhh while(in) delete in; I mean, well
22:20 imirkin_: right, those are copied
22:21 karolherbst: memory leak, now the usefull stuff
22:21 imirkin_: that should be FOR_EACH_DST_THING
22:21 imirkin_: FOR_EACH_DST_ENABLED_CHANNEL() instead of that for loop
22:23 karolherbst: so
22:23 karolherbst: FOR_EACH_DST_ENABLED_CHANNEL(dst0) dst0[?] = dst; ?
22:23 imirkin_: yes
22:23 karolherbst: ahh three arguments
22:23 imirkin_: :)
22:23 karolherbst: start, name, array?
22:24 imirkin_: i dunno, read the macro, it's like one line
22:25 karolherbst: two lines actually :p
22:26 imirkin_: two lines is like one line :p
22:26 karolherbst: and three lines are like two lines :p
22:27 karolherbst: uhh third parameter is inst
22:27 karolherbst: tgsi in that case I assume
22:27 imirkin_: see how it's used elsewhere
22:27 imirkin_: do the same thing.
22:29 inglor: Do we report issues with power management in NVE0 here?
22:31 imirkin_: we do.
22:31 inglor: (yay)
22:31 imirkin_: get in line :p
22:32 inglor: I've got 2x GTX 690 cards and my fan is spinning like crazy when idling.. Fan control is set to AUTO on all of them and I've set the power pstate to lowest with no luck.
22:32 karolherbst: kernel version?
22:32 inglor: With prop blob it's almost silent.
22:33 imirkin_: inglor: pastebin 'sensors' output too
22:33 inglor: kernel 4.5.6-1-ck
22:34 inglor: sensors output: http://pastebin.com/PNKezGr6
22:35 karolherbst: ohh
22:35 karolherbst: two fans on each card
22:35 imirkin_: two cards on each card
22:35 inglor: no two cards on each card it's 690
22:35 inglor: ;)
22:35 karolherbst: :D
22:35 karolherbst: I see
22:36 karolherbst: so 4 cards in total
22:36 inglor: (plus they are setup as SLI but I think this is completly ignored)
22:36 inglor: yes
22:36 imirkin_: i wonder where those names are coming from - NVIDIA GTX 690 A-1?
22:36 karolherbst: inglor: not that I want to convince you, but wanna become a nouveau dev and impement sli stuff? :p
22:36 imirkin_: yeah, we don't do anything with SLI right now
22:36 inglor: hehe sensors.d/*.conf
22:37 imirkin_: ah ok
22:37 inglor: Sure! I'm a dev anyway (java though)
22:37 karolherbst: now I am curious how we read the power consumption on those :O
22:37 imirkin_: do those RPM's reflect reality?
22:37 inglor: hmm so the fan is auto calculated from the poower consumption
22:37 inglor: interesting
22:37 karolherbst: no
22:37 karolherbst: I am just curious
22:38 inglor: oh :|
22:38 karolherbst: they are calculated depending on the temperature
22:38 inglor: imirkin_: I don't know - not sure
22:38 imirkin_: is 1600RPM high? i think it is...
22:38 inglor: temp is about ~10C more than prop blob
22:38 inglor: I can hear it :D
22:38 inglor: with the other drivers I barely can
22:39 imirkin_: anyways... the temps are low(ish), which means that nouveau shouldn't be going apeshit over temps
22:39 imirkin_: check what the pwm settings say in hwmon sysfs?
22:39 karolherbst: on kepler we are always higher than nvidia currently
22:39 inglor: karolherbst: yay!
22:39 inglor: higher is better right? :D
22:39 karolherbst: well
22:39 imirkin_: what we lack in fps, we more than make up for in temperature and fan speed
22:39 karolherbst: it is safer
22:39 inglor: imirkin_: how?
22:39 karolherbst: :D
22:40 imirkin_: grep . /sys/class/drm/card*/device/hwmon/hwmon*/pwm*
22:40 imirkin_: or something.
22:40 karolherbst: inglor: could you dump the files from /sys/kernel/debug/dri/0-3/vbios.rom =
22:41 inglor: karolherbst: yes if you give me instruction I can
22:41 inglor: ;)
22:41 karolherbst: inglor: cat those files
22:41 karolherbst: and upload them
22:41 karolherbst: and if you got time you could also mmiotrace them, but most likely the vbios will tell us already
22:42 inglor: imirkin_: wait I have many directories under /sys/class/drm/card*
22:42 karolherbst: inglor: execute the command as is
22:42 imirkin_: inglor: hence the *
22:42 imirkin_: inglor: the grep . takes care of it - clever little hack
22:42 imirkin_: pastebin the results
22:43 inglor: imirkin_: cool easy: https://ptpb.pw/8rcm
22:44 inglor: karolherbst: do you need all 4 bios?
22:44 karolherbst: yeah
22:44 imirkin_: ok, well, we think we set the fans low
22:44 imirkin_: but i guess we're wrong :)
22:44 karolherbst: inglor: this is the interessting part
22:44 karolherbst: inglor: because usually, nobody is that insane to run nouveau on those 690 gpus :p
22:44 inglor: oh got it
22:44 inglor: hahahhaha
22:44 inglor: I don't like nvidia
22:45 karolherbst: also mmiotrace is _important_ from your card
22:45 inglor: and I don't use any of the HW capabilities
22:45 karolherbst: because we most likely will never have the chance to get one
22:45 imirkin_: that's why you bought 2 of their most-expensive-at-the-time gpu's?
22:45 karolherbst: :p
22:45 karolherbst: again
22:45 karolherbst: :D
22:45 inglor: karolherbst: happy to give more with mmiotrace if I get instructions
22:45 inglor: imirkin_: I inherited them ;)
22:45 karolherbst: inglor: https://wiki.ubuntu.com/X/MMIOTracing
22:45 karolherbst: lucky bastard
22:45 imirkin_: inglor: rich uncle? :)
22:45 inglor: decommitioned server
22:45 inglor: ;)
22:46 karolherbst: ...
22:46 karolherbst: some people and their luck
22:46 imirkin_: karolherbst: i don't think they'd fit into your laptop anyways
22:46 karolherbst: you whould be surprised
22:46 inglor: I did wrote some CUDA code on in back 1-2 years ago..
22:46 karolherbst: you didn't saw my laptop yet
22:46 imirkin_: and the server's probably a bit unwieldy to lug around with you
22:46 inglor: I was mostly interested on the CPU tbh not the GPUs..
22:47 inglor: but heh what the hell I'll take them
22:47 karolherbst: currently I have 3 hdds in my laptop :p
22:47 imirkin_: inglor: or so you thought until you heard the jet engine sounds
22:47 karolherbst: inglor: well
22:47 karolherbst: inglor: you can always donate one to us
22:47 inglor: the 6core i7 would have been better ;)
22:47 karolherbst: inglor: we have a remote server where nouveau devs have access to
22:47 karolherbst: inglor: and we can code on different gpus over ssh
22:48 airlied: hakzsam: http://paste.fedoraproject.org/375569/52532561 fixes it here
22:48 airlied: but would need to do a full piglit
22:48 inglor: interestin..
22:48 karolherbst: a 690 would be perfect for us (and not so perfect for the electirc bill hehe
22:48 inglor: karolherbst: haha
22:48 inglor: planning to mine some bitcoins? :D
22:48 karolherbst: well if you don't need both 690 we will gladly take one
22:48 karolherbst: nope
22:48 karolherbst: dev
22:48 karolherbst: and reeing
22:48 imirkin_: airlied: dunno if that's right - what would happen if you were doing dvec4 == dvec4immediate
22:49 karolherbst: inglor: we usually have a bunch of slow cards without nothing special on it
22:49 inglor: no kepler arch?
22:49 karolherbst: inglor: what we really need are high end gpus, where nvidia-smi works for example
22:49 karolherbst: or where the driver enables special features you don'T get on cheap cards
22:49 karolherbst: like nvidia-smi only reports the power consumption on gpus like 1080... titans...
22:50 karolherbst: not even a 780 ti is enough
22:50 inglor: yeah not gettng those yet..
22:50 karolherbst: well anyway
22:50 inglor: I got the roms
22:50 karolherbst: that 690 would be interessting to RE SLI on those gpus
22:50 inglor: you need two of those
22:50 karolherbst: nope
22:50 inglor: and they are special since
22:50 karolherbst: one
22:50 karolherbst: because the 690 is SLI
22:50 imirkin_: karolherbst: afaik mwk RE'd the SLI bits
22:51 karolherbst: ahh, but we can't test it, right?
22:51 inglor: they are the only gtx which are 2 gpus in one.
22:51 karolherbst: right
22:51 imirkin_: karolherbst: also making use of SLI isn't exactly a solved problem
22:51 karolherbst: and are like SLI cards afaik
22:51 imirkin_: like ... let's say you could do all the SLI you wanted - how would you use it?
22:51 inglor: where do you want the ROMs?
22:51 karolherbst: inglor: doesn't matter just upload them packed as a tar.xz somewhere
22:51 imirkin_: this isn't voodoo2, where alternating scanlines was a good idea
22:52 karolherbst: :D
22:52 karolherbst: right
22:52 karolherbst: imirkin_: but we would need something SLI able to work on it anyway, or what's your point exactly?
22:52 imirkin_: my point is - i haven't the faintest idea how i'd use SLI even if all the bits to actually operate it were piped through
22:53 karolherbst: ahh you mean like in userspace
22:53 imirkin_: yeah
22:53 karolherbst: or how nouveau would synchronize the work and stuff like that
22:53 karolherbst: mhhh
22:53 imirkin_: forget synchronize
22:53 imirkin_: how do you take a work item and split it up
22:53 karolherbst: mhhh
22:53 karolherbst: right
22:54 imirkin_: it's not such an easy task
22:54 karolherbst: it's also like super low priority for us...
22:54 imirkin_: it's infinitely low priority, and it's infinitely difficult
22:54 imirkin_: which is a bad combination
22:54 inglor: Are they similar to CUDA programming?
22:54 karolherbst: opencl would be the easiest thing
22:54 karolherbst: but we talk about opengl here
22:55 karolherbst: opencl is built in a way, that you can split up work on multiple devices
22:55 karolherbst: opengl... not so much
22:55 inglor: what about vulkan? :D
22:55 imirkin_: we're talking about taking a workload designed for a single GPU and programmatically splitting it up among multiple GPU's - that's what "SLI" is.
22:55 imirkin_: with vulkan, it's the application's problem
22:55 imirkin_: so it's easy
22:55 imirkin_: no SLI necessary
22:55 karolherbst: same thing with opencl as it seems then
22:55 inglor: well it's not just that
22:55 imirkin_: SLI is a mechanism to allow multiple GPUs to process a single command stream
22:55 inglor: since the GPUs communicate with each other when nessesary in SLI
22:56 karolherbst: yeah well
22:56 karolherbst: that's not out biggest problem
22:56 imirkin_: yeah, i guess there's that piece too - although i'm not 100% sure how useful that is.
22:56 inglor: so it doesn't go through the PCI-E bus
22:56 inglor: anyway I'm ignoring the SLI complitely
22:56 skeggsb_: imirkin_: i can plumb those bits through if you like ;)
22:56 karolherbst: inglor: anyway, if you don't know what to do with those cards of yours ;)
22:56 imirkin_: skeggsb_: for SLI?
22:56 skeggsb_: yeah
22:57 inglor: karolherbst: I'll contact you :D
22:57 imirkin_: skeggsb_: how about you shoot me now instead and put me out of my misery
22:57 skeggsb_: hehe
22:57 karolherbst: inglor: well one 690 would be enough, because one of those _is_ SLI enabled
22:57 imirkin_: skeggsb_: i still owe a libXvMCnv1x.so ...
22:57 karolherbst: inglor: that's why you get two devices in nouveau for each
22:58 skeggsb_: imirkin_: good point
22:58 hakzsam: airlied, thanks for the fix, I can launch a full piglit tomorrow to make sure it doesn't introduce any regressions
22:58 karolherbst: skeggsb_: mupuf failed to control the fan on his gm20x even with cheating... any ideas?
22:59 inglor: karolherbst: https://dl.dropboxusercontent.com/u/7969252/gpu-690-vbios.roms.tar.gz
22:59 imirkin_: iirc fan control is locked away, no?
22:59 karolherbst: inglor: but I am sure you get more money from them if you sell those, but then you are most likely in a rather odd position tax wise
22:59 karolherbst: imirkin_: right
22:59 skeggsb_: imirkin_: the pwm regs are, yeah, they were trying to switch it to an alternate pwm
22:59 karolherbst: imirkin_: but mupuf tried to rerout the GPIOs
22:59 imirkin_: oh
22:59 imirkin_: heh
22:59 karolherbst: inglor: thanks
22:59 imirkin_: sneaky
22:59 inglor: karolherbst: haha they are around 170-200£ in ebay
23:00 karolherbst: inglor: :D
23:00 skeggsb_: karolherbst: but no, nothing else comes to mind, though i might take a poke myself this week
23:00 inglor: and considering they are 2 years old none will buy them
23:00 inglor: now that 1080 and 1070 are out
23:00 karolherbst: skeggsb_: well without fan control, reclocking is.. useless
23:00 karolherbst: skeggsb_: even more, mupuf said most likely the fsrm isn't in place too
23:00 inglor: everyone is trying to get rid of "old" cards
23:00 imirkin_: inglor: some people stay a few gens behind
23:00 imirkin_: inglor: someone was just in here asking about a GTX 8800 (G80)
23:00 karolherbst: inglor: well the best you can use with nouveau is kepler anway
23:00 inglor: come on!
23:00 skeggsb_: karolherbst: thank nvidia for such great decision making ;)
23:01 inglor: G80?
23:01 karolherbst: skeggsb_: please :D guess to whom I pray to before I go to bed every night
23:01 inglor: my "old" card was gtx 670 :D
23:01 imirkin_: inglor: the first GPU that supported compute, released in 2006 if i'm not mistaken
23:01 inglor: I had it!
23:01 skeggsb_: "here, you can overclock+volt the gpu and burn it to a cinder, but upping the fan speed is WAY too dangerous"
23:01 inglor: it was great
23:01 imirkin_: G80 is the chip codename
23:01 karolherbst: skeggsb_: it's so sad really...
23:01 imirkin_: just like your GTX 690 is most likely a GK106
23:02 inglor: let me read about MMIOTracing
23:02 karolherbst: imirkin_: gk104 actually
23:02 imirkin_: er yeah
23:02 imirkin_: i guess that makes sense
23:02 karolherbst: imirkin_: like two 680
23:02 karolherbst: just a bit underclocked
23:02 skeggsb_: karolherbst: keep harassing poor gnurou about ls pmu ucode ;)
23:02 karolherbst: inglor: anyway
23:02 karolherbst: inglor: I have some patches to fix a lot of kepler reclocking issues
23:03 inglor: karolherbst: yay!
23:03 karolherbst: inglor: so you might get decent perf out of one core of the 690
23:03 karolherbst: inglor: uhhh
23:03 karolherbst: inglor: you know what? maybe you could use DRI_PRIME to offload workloads :O
23:03 karolherbst: and run like 4 times the same game!
23:03 inglor: haha
23:03 karolherbst: each instance on a different core
23:03 karolherbst: plug in 4 monitores
23:03 karolherbst: and you have your super advanced split screen thing!
23:04 inglor: I don't play games at arch. I just reboot@windows and use the Quad-SLI :P
23:04 inglor: (show off)
23:04 karolherbst: inglor: (insider tip: somebody here worked on controling those fancy LEDs on those cards, for extra performance!)
23:04 inglor: I wanted to turn them off
23:04 karolherbst: what :O
23:05 inglor: to save some power as my PSU is struggling!
23:05 karolherbst: you are not worthy to hold thy 690s!
23:05 karolherbst: :D
23:05 karolherbst: yeah
23:05 karolherbst: because turning of LEDs is the thing to do then
23:05 inglor: of course! :P
23:05 RSpliet: every little helps
23:05 karolherbst: please
23:05 inglor: they have TPD 300W... :(((
23:06 inglor: My bill is going to go up
23:06 karolherbst: RSpliet: imirikin questionied my laptop saying a 690 won't fit... how could he :D
23:06 inglor: then I'#ll probably donate them
23:06 inglor: :P
23:07 karolherbst: inglor: we would be very thankful
23:07 inglor: so for mmiotrace I need nvidia drivers..
23:07 karolherbst: exactly
23:07 karolherbst: well otherwise we don't know what nvidia would do :p
23:07 karolherbst: which is the point of mmiotraces
23:07 inglor: here we go again - remove nouveau install nvidia for 3rd time in 2 days :D
23:07 inglor: at least the fans will slow down
23:08 karolherbst: inglor: at least both cards have the same vbios
23:08 karolherbst: inglor: but the both extracted once from one card differ
23:08 inglor: oh yeah
23:08 karolherbst: *one
23:08 inglor: in windows they are identified as Card-A-1
23:08 inglor: Card-A-2
23:08 inglor: etc..
23:09 karolherbst: uhhh
23:09 karolherbst: segfault
23:10 karolherbst: how nice
23:11 inglor: brb rebooting
23:11 karolherbst: bios->conn.entries is NULL
23:13 inglor: ok back with nvidia drivers now..
23:14 inglor: nvidia-smi report: https://ptpb.pw/Foco
23:15 karolherbst: how usefull
23:15 karolherbst: ...
23:15 inglor: :P
23:16 imirkin_: only 2G of vram on each one? i have that much on my GK208
23:16 inglor: told you 2 yrs ago models
23:16 inglor: there was no 4K screen then :P
23:16 karolherbst: nope those 690 just sucked so hard
23:16 imirkin_: and going by model numbers, GK208 = 2 * GK104, right? :)
23:16 karolherbst: some GT 640 have 4GB
23:17 inglor: hey! :/
23:17 karolherbst: serioulsy
23:17 karolherbst: those 690 weren't worth the money
23:17 karolherbst: two 680 cost the same and gave you more perf
23:17 karolherbst: (most likely)
23:17 imirkin_: karolherbst: actually when GTX 680's came out, 2G was pretty much the high end of vram
23:18 inglor: well the alternative was tesla but it was too expensive for a pet project..
23:19 karolherbst: skeggsb_: does that makes sense? DCB entries but no CONN entries?
23:19 skeggsb_: where?
23:19 imirkin_: on the 690 - i'm not too surprised
23:20 karolherbst: inglors second part of the 690
23:20 karolherbst: CONN table version 0.0
23:21 skeggsb_: what's the dcb table have?
23:22 karolherbst: 0x51af: 40 1b 10 08 4a 52 cb bd dc 4e 97 52 8b 52 d4 53
23:22 karolherbst: 0x51bf: e0 53 ed 53 1e 54 c1 00 00 63 54
23:22 karolherbst: but nvbios crashes
23:22 karolherbst: so yeah
23:22 skeggsb_: more wondering what entries were present
23:22 karolherbst: yeah
23:22 karolherbst: I have to fix that crash first
23:23 karolherbst: https://gist.github.com/karolherbst/a49a86f2e8beb605d753e8e5e3050551
23:24 karolherbst: it crashes at this thing: fprintf(out, " CONN %d [0x%02x]", entry->conn, bios->conn.entries[entry->conn].type);
23:24 karolherbst: entry->conn is 0
23:24 skeggsb_: *shrug* odd they defined an output path, but not its connector entry
23:24 karolherbst: well
23:24 karolherbst: nouveau doesn't crash at least
23:25 karolherbst: inglor: mmiotracing is fun, isn't it? :p
23:25 karolherbst: inglor: make sure to put also some workload on it
23:25 karolherbst: inglor: just so that it uses SLI for sure
23:25 karolherbst: skeggsb_: I guess I just add a stupid pointer check and be done with it
23:26 RSpliet: skeggsb_: well, if NVIDIA provides the DCB table, the OEM provides the connectors...
23:26 skeggsb_: RSpliet: the OEM defines both, they have to match each other
23:26 skeggsb_: that'd be my assumption, anyway
23:27 RSpliet: either way, it's not as if we never encountered BS in a VBIOS before :-P
23:27 karolherbst: :D
23:27 karolherbst: I guess I make our code more safe and just check for the pointer
23:27 karolherbst: and print and error?
23:27 skeggsb_: i wouldn't bother printing an error, it might be a valid thing to do for all we know
23:28 karolherbst: k
23:28 skeggsb_: nouveau should be fine, it checks the dcb connector index < connector table entries
23:29 airlied: imirkin_: immediates operate a bit different since we consolidate them
23:29 skeggsb_: and will attempt to make up something sane for connector type based on the output paths present
23:29 karolherbst: mhh
23:30 karolherbst: otherwise the vbios are mostly the same though
23:30 karolherbst: the first one has more DCB entries though
23:30 airlied: imirkin_: AFR is pretty much all the SLI is good for nowadays
23:30 imirkin_: airlied: AFR?
23:30 karolherbst: Alternate frame rendering
23:30 imirkin_: ah
23:30 karolherbst: I guess?
23:31 airlied: too much post processing for anything else
23:31 imirkin_: airlied: right... splitting up a load seems complicated that way
23:31 skeggsb_: SFR isn't used anymore? that seems simplest
23:31 karolherbst: skeggsb_: and slow
23:31 karolherbst: bottom half might have all the fun where top half is boring as hell :p
23:32 skeggsb_: yes, true
23:32 karolherbst: I think AFR is pretty much simple enough to get decent perf
23:32 karolherbst: and somehow deals with the unbalanced workload issues pretty trivially
23:33 karolherbst: maybe something chess board kind of thing might also make sense
23:33 inglor: karolherbst: I can't make it run in single user.. sometimes I hate systemd..
23:33 karolherbst: inglor: isn't required anyway
23:33 airlied: karolherbst: the problem is where you have main rendering and then a post processing effect that mightneed all the frame contents
23:34 karolherbst: inglor: just make sure X won't start and nvidia isn't loaded automatically
23:34 karolherbst: airlied: uhh, right
23:34 airlied: so really AFR is all anyone should care about up front if they ever care about SLI
23:34 karolherbst: airlied: but I am pretty sure nvidia has a solution for that
23:34 airlied:had wanted to do crossfire for years as well
23:34 airlied: karolherbst: app profiles :)
23:34 karolherbst: right
23:36 karolherbst: inglor: yeah I think with 4.7 you will be able to control the fancy LEDs of yours
23:36 karolherbst: skeggsb_: or wasn't it merged yet? :P
23:36 karolherbst: :O
23:37 karolherbst: ohh it really wasn't
23:38 karolherbst: inglor: to bad then, seems like you can't go playing in the first league anymore without fancy LED controls
23:39 karolherbst: UNK3C table differs between both gpus
23:39 karolherbst: ...
23:39 RSpliet: have we got the first conspiracist complaining that the NSA could use this LED to bridge the air-gap and hack machines that are not connected to the internet?
23:39 karolherbst: *vbios
23:40 karolherbst: RSpliet: morse code communication?
23:40 karolherbst: allthough that might be too ovious
23:40 karolherbst: allthough maybe they hide the com inside those fancy ricer patterns :O
23:53 karolherbst: imirkin_: something like that? https://github.com/karolherbst/mesa/commit/df2482016f7492022ca7d37e3f6a577c31fc168b
23:54 imirkin_: karolherbst: yeah, except you have a { missing
23:54 karolherbst: uhh where?
23:54 imirkin_: er, nm
23:54 karolherbst: yeah, I had the issue, because I removed the } first
23:54 imirkin_: :)
23:54 imirkin_: yeah that looks like it could be right
23:55 karolherbst: wondering if we ever hit those cases
23:55 karolherbst: would be good candidates for random corrupted memory
23:55 karolherbst: or just stuff going wrong
23:56 karolherbst: mhh let's check some games with issues! :D