00:11RSpliet: excellent, thanks
00:48pmoreau: Thanks for working on it! ;)
00:49pmoreau: Actually,I might end up testing it sooner as I have my laptop with me: I could launch the building while waiting for ideas to come.
01:37pmoreau: RSpliet: Grrr... You forced updated... And now I can't simply pull from your branch! :p
01:37RSpliet: yes, I upgraded to kernel 4.1rc3
01:39pmoreau: I'll delete the branch and reclone it, it will be easier
02:06pmoreau: RSpliet: Screen still dies when I go to level 0e.
02:12pmoreau: It could well be that my laptop is in a weird state to begin with: remember I still do need to PCI-reset the card before loading Nouveau to be able to use it.
02:15pmoreau: Oh, and I managed to generate some PFIFO/PGRAPH errors. :)
02:19pmoreau: RSpliet: http://pastebin.com/X2tFHjLX
08:43yann-kaelig: I compile a kernel 4.0.3 with nouveau driver and something going wrong : http://upload.devosi.org/f.php?h=3MSsl_2s
08:43yann-kaelig: I make a kernel 3.18.x-rt with nouveau driver and I have no problems
08:43RSpliet: yann-kaelig: the application that crashes is called "nvidia-smi"
08:44RSpliet: and the module linked in is called "nvidia"
08:45RSpliet: that's unlikely to be a nouveau bug
08:45yann-kaelig: Ho! That strange. WTH nvidia is doing on my kernel 4.0.3. I have a kernel 4.0.4 with nvidia but that not disturbing the kernel 3.18.x-rt with nouveau
08:47yann-kaelig: I thing there is no probleme to mix two different kernel with two differnet graphical drivers ?
08:47RSpliet: well, it often leads to hell on the userspace side because NVIDIA has a different OpenGL library as the open source drivers (mesa)
08:48RSpliet: kernel-side they just shouldn't be loaded at the same time (which they are... but nouveau might be effectively disabled by kernel params or the like)
10:03imirkin_: skeggsb: uhm... how does the ddx even work on kepler? all the sched codes are missing! is sched optional on kepler?
10:11hakzsam: imirkin_, hi, if you have some time today, could you please push this branch http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nouveau_add_query_header ? :-)
10:12yusukesuzuki: hi, does anyone know about trap handlers in nvc0? /cc imirkin, mwk
10:13imirkin_: hakzsam: can you explain why the former so_target_save location was wrong?
10:13yusukesuzuki: i crafted the handler with bpt pause and rtt, but it causes page fault errors.
10:13imirkin_: hakzsam: there isn't a single other cmdbuf emit in nv50/nvc0_state.c
10:13imirkin_: yusukesuzuki: provide as much info as you can... links to code, etc. might be best in a mailing list email
10:14yusukesuzuki: imirkin_: ah, ok...
10:15hakzsam: imirkin_, that function was located to the nv50_query.c file because the nv50_query struct was local to that file. Now, that struct is exposed and we can easily move the so_target func to the correct file
10:15yusukesuzuki: imirkin_: the code is here, and I'll show the points related to handlers. https://github.com/shinpei0208/gdev/compare/master...Constellation:handler
10:15imirkin_: hakzsam: that's one viewpoint. another viewpoint is that nv50_query.c is the correct file. why is your viewpoint "correct"?
10:16yusukesuzuki: imirkin_: at first, i set up the handler with bpt pause & rtt, but it causes page faults. https://github.com/shinpei0208/gdev/compare/master...Constellation:handler#diff-e7300ac7a12e81c6ce8e7d3b4f99d590R95
10:16yusukesuzuki: but, by using just rtt, it seems that the execution is paused. https://github.com/shinpei0208/gdev/compare/master...Constellation:handler#diff-e7300ac7a12e81c6ce8e7d3b4f99d590R95
10:17imirkin_: yusukesuzuki: are you trying this with nouveau or blob?
10:17yusukesuzuki: imirkin_: i'm trying it with nouveau in 4.0.0 kernel
10:18imirkin_: yusukesuzuki: and you modified the kernel right?
10:18imirkin_: if not, re-read that doc
10:18imirkin_: you need host-side support too
10:19yusukesuzuki: imirkin_: no. at this time, i just injected handler through envytools (libnva).
10:19hakzsam: imirkin_, because the name of that function is not something like nv50_query_do_stuff() ?
10:19imirkin_: hakzsam: but it basically is... it's running a query
10:20imirkin_: hakzsam: certainly nothing to do with the things generally done in nv50_state either
10:20hakzsam: but it's just calling end_query()
10:20imirkin_: anyways... i assume you're creating a nv50_query.h for a reason, not just for the sheer joy of it, so you should package it with other commits that help with that
10:20imirkin_: with other commits that use that
10:20imirkin_: moving this one function doesn't seem like the right thing... imo it belongs in nv50_query.c in the first place
10:21imirkin_: or i dunno
10:21imirkin_: i'd have to think about it
10:21imirkin_: either way, not reason enough for the refactor. i'm sure you have later patches that _are_ reason enough.
10:22hakzsam: okay, I understand what you mean, you're right
10:23hakzsam: it's not the main reason, and you already know this reason :)
10:25yusukesuzuki: imirkin_: oh, is it not enough to access the BAR0 through libpciaccess (in root)?
10:26imirkin_: yusukesuzuki: oh, it could be... maybe.
10:26imirkin_: yusukesuzuki: oh, but no. it's context-switched
10:26imirkin_: so you have to make sure it's done when the right context is loaded
10:27yusukesuzuki: imirkin_: so, i should do it in falcon's firmware code just after loading graph context, correct?
10:27imirkin_: yusukesuzuki: no
10:27imirkin_: in the intr handler
10:28imirkin_: when you get a trap intr
10:31yusukesuzuki: imirkin_: ah, ok. I misunderstood. i confused shader trap and host's trap. to handle shader trap correctly, we also need to handle it in host's interrupt handler (maybe, mc's handler)
10:32imirkin_: yusukesuzuki: i believe so. in that doc, read the "host-side point of view" section
10:33imirkin_: yusukesuzuki: http://people.freedesktop.org/~imirkin/mwk-singlestep-nvc0.txt -- "Handling trap interrupts - host PoV"
10:34imirkin_: as well as the "use case" descriptions at the bottom
10:34yusukesuzuki: imirkin_: thanks! i misunderstood this part.
10:35imirkin_: "The trap handler's start PC ... parts of the per-channel context, care must be taken to set it while the proper channel is loaded"
10:36imirkin_: apparently the fuc includes a way to write random mp registers? i wasn't aware of that.
10:36imirkin_: perhaps the blob one does but nouveau doesn't? not sure.
10:37yusukesuzuki: imirkin_: i think it means accessing BAR0 through falcon. i seems that falcon can access to BAR0 window from microcontroller side.
10:39imirkin_: i'd avoid thinking of things in terms of "BAR0 window"
10:39imirkin_: as that is precisely that -- a window
10:40imirkin_: there's a temporal component as well, accessing the right thing at the right time
10:42imirkin_: yusukesuzuki: also remember that the trap handler pc is relative to the code address
10:44yusukesuzuki: imirkin_: yeah. and in my experience, the offset need to be positive... (but maybe, it's incomplete experience. I'll investigate more)
10:44imirkin_: hehe, i don't really see the use-case for negative
10:45imirkin_: the code_address points to the code page
10:46yann-kaelig: well, thx to funtoo OS I can swith between nouveau and nividia.
10:47yann-kaelig: All working very well, and nouveau driver don't freeze my OS now when starting a video with mpv player
10:50yusukesuzuki: imirkin_: oh, i see. if i'd like to allocate the handler separated from the kernel code, it requires a little bit hack (mapping handler virt addr within code_address + 32bit range)
10:51imirkin_: yusukesuzuki: yeah, don't do that ;)
10:51imirkin_: just stick them into the same codepage and move on with life
10:51imirkin_: when everything else works, you can try to get clever
10:52yusukesuzuki: imirkin_: sounds very reasonable :D
10:53yann-kaelig: well, I talk too quickly, Something wrong with the nouveau driver and the kernel with FullRT patch
10:54yann-kaelig: That freeze my screen, but the file continue to be read
10:54imirkin_: yann-kaelig: fullrt converts spinlocks into preemptible entities
10:54imirkin_: yann-kaelig: it's unlikely that nouveau will be very happy with that
10:55imirkin_: yann-kaelig: i suspect you have to just s/spin_lock/raw_spin_lock/ the whole thing
10:55imirkin_: but i guess i duno
10:57yann-kaelig: imirkin_: ok, that really something I don't know about, spin_lock/raw_spin_lock. I will try to find some answer about and try to do something. I really need the nouveau for fullRT because nvidia can't be installed with fullRT
11:00yann-kaelig: ther is steel some screen deformation with kernel 4.0.4 and nouveau, http://upload.devosi.org/f.php?h=08gAqSgh
11:00yann-kaelig: look the litlel black cube at tome
11:00imirkin_: which GPU?
11:01imirkin_: looks like a compression fail
11:01imirkin_: but that was fixed quite a while back
11:28yann-kaelig: well, freeze again with the kernel 4.0.4
11:28yann-kaelig: no way nouveau has lot of problems with my conf
13:10RSpliet: pmoreau: too bad... it's odd though, I thought I had most details worked out
13:10RSpliet: meh, these kind of things are difficult to do with remote cards
13:30pmoreau: RSpliet: When I get some time ---at least mid-June--- I could give you access to it if you want.
13:32RSpliet: heh, I've got a pretty tight schedule the coming weeks, not sure if that'd help
13:32pmoreau: Isn't mid-June far enough? :D
13:34pmoreau: It's probably better if we fix the G96 first to get it properly working without PCI-resetting it, and then retest reclocking.
13:34pmoreau: That way, you have at least half a year before having to give it another try! ;)
14:00yann-kaelig: rostedt: the symptomes are: Sometimes I have this strange things in my screen http://upload.devosi.org/f.php?h=2NfDkMsS, and that mean that my screen is going to freeze , or if I try to start a video playback, after some second my screen freeze but not the sound
14:01yann-kaelig: sry wrong channel
14:09librin: good evening
14:10librin: I've got this game that keeps on having odd [red] flickering on my GK104 on Nouveau
14:11librin: if I record an apitrace and replay in on proprietary drivers, it replays "correctly" – no flicker / looks fine
14:11imirkin_: what if you replay on nouveau?
14:11librin: same as "live"
14:11imirkin_: great. let's try some shotgun-debugging. do you have a mesa tree checked out?
14:12librin: I am always running the latest mesa – am kinda autistic about it :V
14:12imirkin_: oh blast. i don't have the patches here. sec.
14:13imirkin_: librin: in nv50_ir_lowering_nvc0.cpp NVC0LegalizePostRA::findFirstUses
14:13imirkin_: usei->op == OP_MOV && usei->getDef(0)->equals(usei->getSrc(0))
14:13imirkin_: change that to
14:14imirkin_: 0 && usei->op == OP_MOV
14:14imirkin_: [basically i want it to never hit that case]
14:14librin: wouldn't it be simpler to #ifdef 0 it? ;]
14:14librin: and okay, gonna test
14:15imirkin_: however you want to remove it is fine with me
14:15imirkin_: is the game 'terasology' by any chance?
14:15librin: it's not the game "teresology"
14:15librin: It's the Talos Principle
14:15librin: whoop whoop
14:15imirkin_: ah ok
14:16imirkin_: did that help?
14:21librin: dunno, rebuilding
14:21librin: it's a bit slow to do the manual parts while I am also eating
14:21librin: (FWIW, didn't expect anyone to respond so quick)
14:21imirkin_: i'll try to be slower next time
14:22librin: please don't – it's normally awesome when people do respond fast
14:33buhman: it seems imirkin_ has figured out the secret sauce for 'awesome when he responds late'
14:36librin: imirkin_, it didn't help at all
14:36imirkin_: librin: ok, seems reasonable ;)
14:36imirkin_: librin: please open a bug on bugs.freedesktop.org, include a link to the apitrace and a description of the badness
14:37librin: is a short video recording of the said badness a good "description"?
14:37imirkin_: i'd prefer textual, but video recording is probably ok too
14:38imirkin_: basically when i see the trace
14:38imirkin_: and can't repro the issue
14:38imirkin_: i want to know what issue i'm not repro'ing ;)
14:38librin: roger that, b0ss
14:40librin: imirkin_, I suppose I should compress the apitrace? (To not waste *Your* bandwidth.)
14:40tobijk: librin: please do so :)
14:40imirkin_: or yours. yeah, xz -9 preferred
14:41tobijk: and provide a complete dmesg
14:41imirkin_: fwiw i have a short trace of the talos principle (recorded on radeonsi) and no issues
14:42tobijk: about which card we are talking here about?
14:42imirkin_: on my GK208
14:42tobijk: oh i meant librins card :D
14:43librin: err, 2xGK104
14:59librin: P.S. it has no problems under Intel
14:59imirkin_: i'm sure it's some sort of compiler issue
15:00imirkin_: but there's just this one and one other i'm actively aware of
15:00imirkin_: the other is a spill failure on 3-component items
15:00imirkin_: but you should have gotten an assert fail for that one
15:04librin: I don't believe I did
15:04imirkin_: i guess you only get asserts in debug builds...
15:05imirkin_: oh right yeah, the GK208 has a ton more registers
15:05imirkin_: which might be why i don't see any fail
15:05imirkin_: can you rebuild with --enable-debug?
15:06imirkin_: [note you don't want that for you "real" build... just for debugging... it enables a lot of slow checks]
15:07librin: lemme see
15:16librin: imirkin_ okay, I am rebuilding into a debug build
15:32tobijk: librin: if you can provide an apitrace i'll go look at it with my GK107
15:32librin: filesize: 361.9 MiB
15:32librin: it's gonna be in the bug report, too
15:33tobijk: ok :)
15:33librin: just wanna test with a debug build first before I finalize the report
15:33imirkin_: i might be maxing your 100mbit line :)
15:34imirkin_: 10.1 MB/s average. not bad :)
15:34librin: don't worry – 2x100 mbit connection
15:35librin: my primary is p much idle
15:35skeggsb: imirkin_: *apparently* the hw manages fine without them on kepler, my guess is it stalls for the maximum number of clocks or something
15:35skeggsb: i don't believe that's the case on maxwell though, weird stuff happened without them
15:35imirkin_: skeggsb: how does it know whether they're there or not?
15:36skeggsb: iiuc some of the bits are set a certain way for the sched ops that aren't the same as for normal opcodes
15:36skeggsb: i didn't actually look myself, just believed what someone (calim?) mentioned
15:37imirkin_: ah yeah, probably
15:37skeggsb: btw, your comment about float number in the mail to nvidia
15:37skeggsb: that's a channel address, not a float
15:38imirkin_: ah, is that what shows up in the TRAP?
15:38librin: imirkin_, I don't appear to be having any failed assertions regardless o___O
15:38imirkin_: librin: yeah, i see the redness too
15:38imirkin_: librin: on my GK208 which has a ton more registers
15:38skeggsb:is still not sure there's any point mailing that address
15:39imirkin_: librin: but it's very rare, right?
15:39skeggsb: i tried for something simple recently
15:39imirkin_: skeggsb: cc nouveau ;)
15:39skeggsb: imirkin_: it was just a "can i use the pciid list from your driver's readme"
15:40librin: imirkin_, what is rare?
15:40imirkin_: librin: the red blotches
15:40imirkin_: librin: like once every 10s or so
15:42imirkin_: librin: this will require some careful investigation. looks like it's not anything simple :(
15:42imirkin_: please do file that bugreport
15:43imirkin_: i'm double-checking now that it's not some new issue i recently introduced...
15:43imirkin_: nope. happened on 10.3.x as well
15:44librin: also please watch the vid – the "gray" flickers are much more obvious in the video than the in the trace
15:45imirkin_: i'll check whether i can also repro on my GF108
15:45imirkin_: hopefully i can, that'd eliminate a source of potential idiocy
15:46librin: >potential idiocy
15:47imirkin_: kepler introduces explicit scheduling, texbar's, and a couple other annoyances
15:48imirkin_: if i can repro on fermi, i'm able to rule a lot of things out
15:49librin: oh, I believe it was a big "thing" they boasted about, saying how they could trim down a lot of logic from 'dem GPUs by assessing and doing it all on the compile stage
15:49imirkin_: uh huh
15:49imirkin_: well, when you don't have docs, it can be a bit painful to work all that out :)
15:50librin: I figured that much
15:51tobijk: i do only see some red blinking once in a while on my nve7
15:52librin: I should probably record a better trace hmmm
15:52librin: where it'd be more obvious
15:52imirkin_: no, it was plenty obvious
15:52imirkin_: just not super-common
15:52imirkin_: you made it sound like it was happening every few frames
15:53tobijk: so if thats really the problem, i can repro as wel ;-)
15:54tobijk: lets see what it looks like in your clip
15:54librin: FWIW, on "normal gameplay" it happens close to that. Much more so with the "gray" flicking (that's best seen in the video), which does happen on every other frame in most scenes
15:55imirkin_: wow, that video goes a lot faster than it replays on my gpu :)
15:55imirkin_: oh, probably coz it's fixed at 30fps, but you actually get fewer fps when playing it.
15:57librin: When not recording, with the same graphics quality settings I have some 25-30 FPS on this scene :V
15:58librin: slight reclocking FTW
15:58imirkin_: also GK104 tends to be pretty powerful
15:58tobijk: mh that plays way slower for me as well
15:58imirkin_: GK208 is the runt of the series
15:59imirkin_: (esp compared to its GK110 brother)
15:59tobijk: + i dont see the black flickering with apitrace
15:59librin: that reclocking still does help, A LOT
15:59tobijk: when you reclock it starts flickering black?
16:00librin: tobijk, it does happen a few times on the trace. Keyword: a few times
16:00tobijk: did not notice it in the trace, but noticed it in the video
16:00librin: tobijk, the only time I DON'T have my GPU clocks up is when booting
16:01librin: tobijk, well "a few times" implies "blink and You'll miss it"
16:06tobijk: meh where did my pstate bootloader setting go :/
16:06librin: I do it by hand :V
16:06imirkin_: nouveau.config=NvClkMode=0a or whatever
16:06librin: I put it under 0a
16:06imirkin_: er wait
16:06imirkin_: the stupid thing is decimal
16:06librin: anything higher than that and it falls flat on its face
16:06imirkin_: if you set it right on boot you might get lucky
16:06librin: figuratively speaking
16:06tobijk: nah i prefer it on demand :D
16:06imirkin_: something like nouveau.config=NvClkMode=15,NvForcePost=1
16:06librin: BTW I've got another bug. But I am not sure if it's REALLY a nouveau bug
16:06imirkin_: skeggsb: do you remember what you used?
16:08librin: >running steam *gradually* makes other opengl programs stutter. Leaving steam running for some 8 hours not only makes games hardly playable but even makes video players that use OpenGL for output, like mpv to have stuttering output.
16:08librin: restarting steam "resets" the stutter
16:08tobijk: lets blame steam
16:08librin: I don't see it on intel under Mesa
16:08tobijk: btw, stil lno stuttering with faster replay ;-)
16:09tobijk: *black stuttering
16:09librin: and don't see it on proprietary drivers (Nvidia AND AMD)
16:09librin: which kinda points towards Nouveau
16:09imirkin_: clearly a nouveau issue wrt resource management somehow
16:09librin: oh and CS:GO does the same
16:10librin: (if I run it outside steam)
16:10imirkin_: which the same?
16:10librin: but if it runs normally - with steam it goes stutter^2
16:11imirkin_: one problem at a time :op
16:11librin: imirkin_, CS:GO produces the aforementioned stutter over time, exponentian stutter with steam running at the same time
16:11imirkin_: running it now without optimizations
16:11imirkin_: if we're lucky, it's an opt that goes wrong
16:12librin: Without optimizations? :O
16:12imirkin_: compiler optimizations
16:12librin: inb4 the framerate is into fractional digitz
16:12imirkin_: nooope, that ain't it
16:13imirkin_: btw, do you happen to know if this works ok with any other gallium driver?
16:14imirkin_: i'm gonna run it with llvmpipe, but at 1920x1200, it might not take kindle to that sort of thing
16:14librin: I might be able to try on radeonsi tomorrow
16:14librin: keyword: might
16:14imirkin_: trying it with radeonsi right now, we'll see how far i get
16:14imirkin_: still on title screen :)
16:15tobijk: NV50_PROG_OPTIMIZE=0 does not change anything :/
16:15imirkin_: yeah i know
16:15imirkin_: oooh! just got to the menu
16:15librin: what card?
16:15imirkin_: core i7-4790
16:16librin: You said You're trying radeonsi B|
16:16imirkin_: i lied. i meant llvmpipe.
16:16imirkin_: common typo
16:17tobijk: yeah these words are quite similar ;-)
16:17imirkin_: ooh, it got to the game!
16:17imirkin_: yeah, the keys are all like right next to each other
16:17librin: I suppose that implies radeonsi is a pile of doo-doo ¬___¬
16:17tobijk: you got a pretty monster machine there btw :P
16:18librin: tobijk, are You referring to that Haswell chip?
16:19librin: I hate Intel :|
16:19imirkin_: that monster chip *just* finished the bit where it goes from white to the scene
16:19tobijk: imirkin_: *smile*
16:21skeggsb: imirkin_: *why* did you remind me about bash.org
16:21skeggsb:tries really hard to not look at it
16:21imirkin_: it's not like the top 100 have changed in the past 10 years
16:21librin: is llvmpipe multithreaded?
16:22imirkin_: sucking down 6-8 cores right now
16:22librin: how do I run it? :D
16:22skeggsb: it's far more entertaining to read than fb
16:22imirkin_: it's going a lot faster now though... a ton of shader compilation i guess
16:22librin: wanna try seeing how well it goes on my octacore :3
16:24imirkin_: hrmph, llvmpipe seems to be happy
16:24imirkin_: hard to pay attention though with it moving so slowly
16:24librin: bleh, it only uses up some 2-4 cores :C
16:25imirkin_: librin: just wait 'til it gets going
16:25imirkin_: give it a few minutes
16:25imirkin_: diff scenes get a diff amount of parallelism
16:25tobijk: yeah i add another pair of eyes, give me some years...
16:26librin: it goes fairly fast
16:26librin: I'm out of the menu already :3
16:26imirkin_: i have llvm 3.5
16:27tobijk: 95% cpu time, bleh
16:27librin: >OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits)
16:28imirkin_: LLVM 3.5, 256 bits =]
16:28imirkin_: i have twice as many bits as you, apparently
16:28librin: I get ~1 fps in the "main dish"
16:28tobijk: OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits)
16:29librin: I suppose my 128bits is due to -mprefer-avx128
16:29imirkin_: but what i lack in llvm version, i more than make up for in corse
16:29tobijk: oh i#m in the game *yay*
16:30imirkin_: anyways, llvmpipe looks ok, so it's not a conversion or gallium-level issue
16:30librin: yeah, looks fine here
16:30librin: on llvmpipe, that is
16:30librin: and imirkin_, I've got double the cores :P
16:31imirkin_: wow, the haswell is *really* snappy
16:32librin: I'm gonna have to look that up in a dictionary :C
16:32tobijk: intel is working fine as well?
16:33librin: ah, I see. snappy == fast
16:33librin: The fact that English is not my native language bites me sometimes :/
16:34tobijk: when translating and retranslating i come to swift somehow :D
16:35librin: whatever that means B|
16:35tobijk: english is not my native tounge either
16:35imirkin_: it isn't for most people
16:36imirkin_: Ben might be the only native english speaker here
16:36imirkin_: (if you can even call australian 'english' :p )
16:37tobijk: trip on toes much? ;-)
16:37skeggsb: more english than american :P
16:37librin: >Rendered 2311 frames in 740.868 secs, average of 3.11932 fps
16:37librin: oh snap whole 3 eff-pee-ess
16:37librin: gotta love llvmpipe
16:38tobijk: wow why is intel _that_ faster on that trace
16:38imirkin_: on the haswell: Rendered 2311 frames in 83.4594 secs, average of 27.6901 fps
16:38imirkin_: [using the gpu, of course]
16:38tobijk: Rendered 2311 frames in 84.5357 secs, average of 27.3376 fps - ivy bridge
16:39tobijk: we are clearly doing something wrong ;-)
16:43librin: > Rendered 2311 frames in 80.6779 secs, average of 28.6448 fps
16:43librin: GK104 @ 405 MHz
16:43tobijk: you should be _way_ faster
16:46librin: that's what it should give me on full clocks here, assuming it scales linearly
16:47tobijk: Rendered 2311 frames in 95.9976 secs, average of 24.0735 fps @ 708 Mhz
16:47tobijk: on my machine
16:47librin: >(02:44:46) librin.so.1: > Rendered 2311 frames in 80.6779 secs, average of 28.6448 fps
16:47librin: >(02:44:59) librin.so.1: GK104 @ 405 MHz
16:48librin: >full clock would be 1032MHz
16:49tobijk: yeah but it does not scale linear :>
16:49librin: although, err, it should got up to 1215 MHz
16:50librin: at least that's what it reaches under 'dem non-free drivers
16:53librin: imirkin_, anything else I could help with?
16:54imirkin_: librin: you could find the issue and send a patch to fix it
16:54imirkin_: sadly that's a non-incremental task
16:54tobijk: and fix reclocking on the way ;-)
16:57librin: writing a patch once the problem is known? Most likely I could do that. Figuring out the problem? If I could do it myself, I would not bother anyone here and would just do it, even if it takes me a really long while...
17:00imirkin_: usually it involves lots of staring at things
17:02librin: $5 for a tap with a hammer, $95 for knowing where to tap ;]
17:03imirkin_: it was $49995 when i heard it.
17:03librin: it has many variations
17:03imirkin_: or more like: "chalk mark: $1. knowing where to put it: $49999"
17:04librin: the point is still the same
17:04librin: thus, speaking of which, if You have any suggestions on what to stare at and if it might lead to helping, do let me know
17:05imirkin_: well, my plan of action was to load it up in qapitrace
17:05imirkin_: find the offending draw
17:05imirkin_: and look to see what about it looked "funny"
17:13librin: tried that. qapitrace kept crashing B|
18:01imirkin: librin: hmmmm... that's a bad sign
18:01imirkin: hopefully i don't get the same thing
18:03librin: well, it works now
18:03librin: I am trying to identify an offending call ATM
18:04librin: imirkin, so far so slow
18:40librin: imirkin_, in the trace, frame 1950, the ground gets painted red on call #2160519
18:40librin: hope that's useful
18:41imirkin: very! can you add that to the bug report?
18:46librin: and done