01:36 BoRiS: Hi guys
01:40 BoRiS: Hi Imirkin! I've done some more testing about why my NVA8 chipset for nouveau with vdpau freezes when trying to play a video using vdpau.
01:42 BoRiS: I tried older kernels, older versions of Mesa and it didn't make a difference.
01:42 imirkin: so ... what changed
01:42 imirkin: did it never work?
01:42 BoRiS: I did before but I tracked it down to Xorg
01:43 imirkin: huh
01:43 imirkin: that's surprising.
01:43 BoRiS: I compile Xorg from git.If I use the latest kernel + Mesa but Xorg compiled 20160824, It freezes
01:43 BoRiS: But If I use Xorg compiled from 20160508, it works flawlessly
01:44 imirkin: huh. i blame ... not me!
01:44 imirkin: ajax or airlied: any ideas --^
01:44 imirkin: BoRiS: can you bisect X?
01:45 BoRiS: I have another Xorg from 20160521, Im just testing that xorg version right now
01:45 imirkin: you should grab git and do a literal "git bisect"
01:45 imirkin: rather than trying to do it by date
01:46 BoRiS: k, what should I be looking for?
01:46 imirkin: the commit that breaks it ;)
01:47 airlied: dri2 or 3 changes maybe?
01:47 imirkin: airlied: he gets a few frames in, and then it hangs
01:47 imirkin: i think it might be some swap interval thing? dunno.
01:48 airlied: yeah sounds like present bug or something like that
01:48 airlied: if the whole system doesn't hang
01:48 airlied: try with -modesetting as well for effect maybe
01:50 BoRiS: ok... Traced it abit closer. Works on my Xorg version from 20160708 but fails on 20160824
01:51 BoRiS: let me try to git bisect it
01:52 Sophira: So I did discover an issue with Xorg 1.18, but I'm too tired to debug it right now so I've temporarily gone back to 1.17. The issue is that for some reason my Qt programs glitch don't update properly, which is especially noticeable when using menus. Oddly, it's just Qt and not anything else; GTK apps work fine.
02:00 imirkin: probably because QT apps use opengl to render, while gtk ones do not
02:02 BoRiS: imirkin: Still trying to bisect but I found some newer versions that I compiled so I narrowed it down abit more. X11-20160706 works perfectly playing the video using vdpau perfectly where as X11-20160722 it freezes so its something between those dates
02:10 Sophira: imirkin_: Ah, okay.
03:11 kloofy: http://developer.download.nvidia.com/assets/cuda/files/reduction.pdf i must really look why the loop unrolling is an optimization still though
03:32 BoRiS: imirkin: Ok, Ive narrowed it down the issue between 5 git commits
04:09 BoRiS: imirkin/airlied: I found the commit in xserver that breaks nouveau vdpau playback [looks frozen]
04:10 BoRiS: commit f993091e7db81b0420e23c485378cba112278839 <----------- Frozen!!!!
04:10 BoRiS: Author: Keith Packard <keithp@keithp.com>
04:10 BoRiS: Date: Thu May 26 10:40:44 2016 -0700
04:10 BoRiS: os: Switch server to poll(2) [v3]
04:16 BoRiS: https://cgit.freedesktop.org/xorg/xserver/commit/?id=f993091e7db81b0420e23c485378cba112278839
07:32 karolherbst_work: Sophira: there is a -platform switch for qt5 applications where you could use a xlib based one (I think it was xlib, could be something else) and see if the issues disappear and then set the QT_PLATFORM env variable globally or so, details could be wrong
07:33 karolherbst_work: but sadly every web search engine is really bad now, so I can't find the right thing...
07:38 kloofy: karolherbst_work: i may sound stupid now, there is a method, but let's just say the code branches from different pc's to the same branch let's say the branch is uniform even, can two warps separate warps take that same branch in parallel?
08:13 kloofy: http://cs.nyu.edu/courses/spring12/CSCI-GA.3033-012/lecture5.pdf well i'll try to answer it my own, it's said that maximum that one SM can handle is 512pixels/threads
08:13 kloofy: *single SM
08:14 kloofy: i think on kepler that is bit higher around 2000
08:18 kloofy: maybe that was over estimated still, maybe it remains the same even
08:26 kloofy: Maximum number of resident warps per multiprocessor , it says 64 i.e 64*32=2048 but can they execute a single branch/instruction in lockstel
08:26 kloofy: cause the sm is prolly divided into SIMD units yet, more reading needed
08:28 kloofy: no, not on nvidia, so 2048 it seems to be
08:44 kloofy: In GCN, each CU includes 4 separate SIMD units for vector processing. Each of these SIMD units simultaneously executes a single operation across 16 work items, but each can be working on a separate wavefront. This places emphasis on finding many wavefronts to be processed in parallel, rather than relying on the compiler to find independent operations within a single wavefront.
08:47 kloofy: https://www.amd.com/Documents/GCN_Architecture_whitepaper.pdf so karolherbst i answered this question too, it ought to work, i then assemble together a minor pseudo how to do this stuff
08:57 pmoreau: Wow, Andy is doing three talks in a row on the Wednesday.
08:58 karolherbst: :O
08:59 karolherbst: well
08:59 karolherbst: he has a break
08:59 karolherbst: and it is only 30 min talks
08:59 pmoreau: True
08:59 pmoreau: but still :-)
08:59 karolherbst: well, it is easier that way
08:59 karolherbst: no need to setup the stuff 3 times :D
09:01 pmoreau: ;-)
09:02 karolherbst: RSpliet: so I will work on the pmu stuff this weekend, if you have anything done on nvagetpmu in the meantime it would be nice to push the changes somewhere
09:02 pmoreau: What’s the plan for XDC btw? Has an "arrival time" been decided yet?
09:02 karolherbst: nope
09:02 karolherbst: we come as we please
09:02 karolherbst: afaik
09:03 karolherbst: I will be there around 4pm on tuesday
09:03 pmoreau: Ok
09:03 pmoreau: I still need to book the flight…
09:03 karolherbst: well, I will land 4pm, no idea how much time I would need to get into the "city" or to mupuf
09:04 karolherbst: pmoreau: well, while I was booking, the cheaper flights had only one free seat ;)
09:04 pmoreau: :-/
09:04 karolherbst: but that was from hamburg, which is more expensive anyway...
09:04 karolherbst: 250€ in total, which is still nice, but from berling I would have gotten something for 100€
09:04 karolherbst: ....
09:05 karolherbst: *berlin
09:07 kloofy: the most important stuff is since accessing the program counter tag to overwrite the immediate, it's laggy to start with probably, but the coherency of the cache is minor trouble
09:08 pmoreau: I can find some flights around 900kr, that’s good.
09:11 kloofy: yeah it seems to work with syncthreads and masks still, so no worries
09:17 karolherbst: pmoreau: unfair
09:17 karolherbst: :D
09:18 pmoreau: It’s good to live close to Copenhagen Airport ;-)
09:19 kloofy: where is the xdc held this time?
09:19 pmoreau: Helsinki
09:19 pmoreau: https://www.x.org/wiki/Events/XDC2016/
09:19 karolherbst: pmoreau: ……..
09:20 karolherbst: just because I don't live in the hipster city berlin, I have to pay double for my flights, so unfair .D
09:20 karolherbst: :D
09:20 pmoreau: Yeah… that’s unfortunate
09:20 karolherbst: although a train to berlin is like 20€
09:21 pmoreau: :-D
09:21 karolherbst: 2 hours
09:21 kloofy: i could make it there with 15dollars approximately with a ship
09:21 kloofy: if my uncle or friend were to organize me cheap tickets
09:22 kloofy: uncle lives near helsinki himself too
09:23 Calinou: there should be a Wayland Conference
09:23 Calinou: = WC
09:23 Calinou:runs
09:23 Calinou: there's already the Way Cooler WM ;)
09:24 rmrfchik: well, computer freezes when transparency is enabled in kde.
09:24 rmrfchik: I can deal with it, I hope other will fine
09:27 kloofy: well now finally minor headwrapping around the issue that one said, sched opcodes are needed for atomics to work
09:41 kloofy: so atomic is an operation where each thread of a warp is serialized for things like memory operations, god sakes i do not understand why it's even needed , depends on the code where some memory consitency is needed
09:57 kloofy: with masks+branches or predication at least on cuda there is a way with tid and gid identifiers, i at all do not like this
10:06 kloofy: but restricting to a single SIMD lane on radeon calculation seems to be 2560/4 worth of threads, with a mask 1 that means 10 threads ever executing the instuction
10:07 kloofy: which is 640/64=10
10:14 kloofy: but for loop would do it as well
10:15 kloofy: in radeon terms for loop+cbranch for both scalar and vector or vskip in case of vector instructions only
10:20 kloofy: it would not make the handler hugely bigger , but something says that i would not like that solution either
10:20 Tom^: karolherbst: are you gonna make some presentation at the xdc?
10:21 blacklotus89: what does it mean when I get "disp: chid 1 mthd 0080 data 00000000 00005080 0000000d" at boot time?
10:21 RSpliet: karolherbst: I think I got a flight to Stockholm and back from Helsinki for like €95... with free Wifi on board!
10:22 Tom^: oh cool so it seems "1000 Samuel Pitoiset, Karol Herbst, Pierre Moreau, Martin Peres - Status update of Nouveau (45 minutes)"
10:22 Tom^: will it be live streamed?
10:24 kloofy: cause i vaguely remember that webgl for instance had an iteration count for for loop as const, but need to recheck
10:25 karolherbst: Tom^: sure
10:25 Tom^: cool
10:26 karolherbst: Tom^: I also have my own talk :p
10:26 Tom^: D:
10:26 Tom^: indeed on friday !
10:32 karolherbst: blacklotus89: something nouveau didn't expected
10:32 kloofy: however perhaps the hw can still handle this stuff for webgl too though
10:33 blacklotus89: karolherbst: a friend of mine has this problem when he boots his PC up - would it help to tell him to remove the xf86 nouveau driver so that modesetting is used or will the problem probably still exist afterwards?
10:33 karolherbst: nouveau is a kernel driver mainly
10:33 Tom^: modesetting is just for X
10:35 blacklotus89: yeah I know, but I don't know what the problem is triggered through if the problem only exists when starting X it could help to switch to vesa or modesetting couldn't it? (or should I just tell him to install the blob)
10:36 Tom^: which gpu and which kernel?
10:36 blacklotus89: I asked him he didn't answer yet
10:36 Tom^: dial him and tell him its an emergency, you need to know now
10:37 karolherbst: blacklotus89: if the message doesn't cause any issues, simply ignore it
10:37 blacklotus89: karolherbst: the pc hangs at boot
10:37 karolherbst: this may have other reasons
10:37 karolherbst: and before we can debug this, we need the _full_ dmesg
10:38 kloofy: so another monologue held, eating some food soon here, i'd stick with the for loop, if mupuf really was correct that atomic operations really need sched opcodes
10:38 blacklotus89: btw what is the status of qr codes for error showing in the linux kernel? I know it was discussed a few years back, but I didn't hear anything about it since
10:39 blacklotus89: karolherbst: yeah I know :/ thx anyway I will try to get as much information out of him as I can
10:39 karolherbst: full dmesg pls :p
10:40 RSpliet: blacklotus89: make sure your friend is using an up-to-date kernel
10:46 RSpliet: also, if things work and it's just an informative message, wouldn't worry about it too much
10:47 RSpliet: looks like a problem in nv50_display_flip_next
10:52 kloofy: i think modesetting can have working opengl too, or maybe i can't even remember
10:53 kloofy:does not know the current state, but anyways did someone get a real clue about my references too, what the point was?
10:54 kloofy: i'm again little bit busy, if still noone gets, maybe next weekend the rough pseudo arrives, so you'd understand if you did not get enlightened by the patents and those references
10:58 kloofy: RSpliet: should know how branching works, i read his thesis, and he had correct theory behind it and right formulation, saying as if they worked serialized, but actually they don't
11:01 kloofy: which means with correct masks+branching deeply pipelined instructions work faster, but those instructions that can take on the whole number of threads, the divergence would kill the perf for those
11:01 kloofy: hence such instructions are not supposed to have masks
11:04 kloofy: RSpliet: and btw, i also think that in parallel universe there is another kloofy who btw, continuosuly applaudes for my monolgues:D
11:08 kloofy: they were even teleporting atoms a theory branched from alberts himself, something like there is always always a same forse across the distance for every atom or something also for every human
11:09 kloofy: i actually don't take it very seriously though, it's quite scify, if i remember correctly than this was kinda subtheory or proof for the contraversial einsteins time relativeness stuff, but ...not that sure, can rewatch the tv series from internet once i have time
11:10 kloofy: when i was in new zealand then in switzerland there was a lab, where they searched how to travel in time, seeking for some holes in the outer space
11:15 kloofy: by the way albert learned his ways by working at the patent ratification institute, today also reading the patents educates the vastest
11:19 kloofy: in estonia one of the most famous scientists, well among the scientists the the most famous so to speak was a baltic german biologist called Karl Ernst von Baer
11:19 kloofy: he said the same things what i have faced in life, that estonian is very stupid and extremealy cruel against his own nationed people
11:21 kloofy: i bet when he did some acheivements he faced a lot of shit from those idiotic citizens like i have, so let's not forget that most estonians terrorise me daily basis
11:30 kloofy: schemes how they kill their own envied people is very retarded and how they annoy people their jelous about, i for instance have had 4surgeries i was bullied and injured in 3.5half of those extensively, and i may be forced to take another one, and they probably kill me
11:30 kloofy: i have very controlled people whom i deal with today and most of them are sportsmen, i can't tolerate estonian retards at all
11:34 Sophira: karolherbst: I believe the env variable you want is QT_QPA_PLATFORM?
11:34 karolherbst: most likely, yes
11:34 Sophira: las platf
11:34 Sophira: Oops.
11:34 Sophira: (that was meant to have a / on the front, for my IRC client :D)
11:40 kloofy: so in theory the pseudo code could be done today too, or tomorrow would you allow me to live quietly from there on, in thoery it can be implemented to the stack too , and very quickly as this method is thin and wise
11:43 kloofy: in contrast to the llvm one which introduces some ideas , it's like vulkan to get people thinking it serves as such, but it does not handle the stuff well, i was enighthened by vulkan too, but i get my education from verilog world overall
11:44 kloofy: and llvm sched and vulkan their only purpose is to get people thinking , ideas are ok, but overall they do not serve as implementations that are usable imo
11:45 kloofy: they just get poeple to think, which is the only good thing they have, but it's enough of the goods actually
11:46 kloofy: so if i had to pick if they were existing or not, i'd say it's better to have them as reference, but it's also better that they were not used now and later even
11:51 kloofy: so in sm3 spec 24 branches are possible to have, it's problematic a bit, i only need 4or so of them in the handler
11:51 kloofy: but if the code uses 24 of them it's not going to work out
11:52 kloofy: but in sm4 and up they have unlimited i.e dynamic branches
11:54 kloofy: as we talked replacing 4branches with interrupts would not make sense, but again, doing the predication would lift the instruction count and cache usage
11:59 kloofy: though i am quite sure that to hit the limit the branches would have to be nested
13:45 rmrfchik: errr, got kernel panic (blinking Scroll lock, caps lock)
13:45 rmrfchik: seems like nouveau is broken for me :(
13:46 rmrfchik: very sad, because with proprietary drivers cairo works very slow (SLOOOOW scrolling in libreoffice and such)
13:48 karolherbst: rmrfchik: is it possible for you to get a full dmesg?
13:48 rmrfchik: dunno, rebooting
13:49 rmrfchik: yep, smth interesting in messages. give me sec
13:52 rmrfchik: http://pastebin.com/ygyGtqA2
13:53 rmrfchik: karolherbst: see pastebing
13:53 rmrfchik: pastebin*
13:54 karolherbst: rmrfchik: could you paste a bit more? best would be the entire kernel output of that one boot
13:57 rmrfchik: karolherbst: http://pastebin.com/yGs8LfZV
14:06 karolherbst: rmrfchik: did you try any reclocking things? like setting pstate on boot or something like that?
14:07 karolherbst: uhhh
14:07 karolherbst: rmrfchik: did you try to watch or movie?
14:08 karolherbst: or some other video files?
14:08 karolherbst: I see the video accell firmware was loaded
14:08 karolherbst: imirkin_: any ideas here?
14:09 kloofy: http://dpaste.com/2D8QYF5 that is the radeon way, ouh i got so tired , don't laugh the idea is the important one
14:10 kloofy: but fermi and kepler has even a better way, while nv50 is sort of similar
14:12 rmrfchik: karolherbst: no reclocking
14:12 RSpliet: rmrfchik: that should work actually... although GDDR3 is the least of the tested DRAM types
14:12 rmrfchik: karolherbst: no movies, youtube was at background for about a hour, but was paused at crash time
14:14 rmrfchik: karolherbst: i can remove firmware files, i do not watch movies at all and firefox won't offload H264 anyway
14:14 rmrfchik: so, i think vdpau firmware is useless for me
14:15 rmrfchik: RSpliet: why should i reclock? i do not need opengl here, it's dev/office box
14:15 RSpliet: rmrfchik: in that case there might be some potential power saving
14:15 kloofy: karolherbst: said i don't owe you anything more, so you can go ahead and optimize the stuff, i've been quite sick myself, and still need to do some other stuff too
14:15 RSpliet: but no, there's no need
14:16 rmrfchik: i can downclock if it bring some stability ;)
14:16 RSpliet: probably doesn't make a difference
14:16 RSpliet: do you always get the same backtrace?
14:17 rmrfchik: well, there were 2 lockups when transparency was enabled in kde and there were no stacktrace in logs
14:17 rmrfchik: I switched off transparency and it worked fine for a few hours until last kernel panic
14:17 rmrfchik: so, this is firtst backtrace I get
14:18 RSpliet: so what I'd do is retry with a 4.7 kernel, and just file a bug for this if it doesn't solve any issues. Which is likely given the NV50 code isn't touched a lot currently
14:18 RSpliet: but you never know
14:19 RSpliet: sorry, it's a bit of a stock answer
14:19 rmrfchik: there is not 4.7 in debian, I'm not ready to build myself as back in 2000
14:20 rmrfchik: so, i hope may be karolherbst and imirkin_ will say something
14:20 RSpliet: but I currently don't have a lot of time to see what fifo interrupt 04200000 could imply - the timeout messages indicate the card shits itself anywhere
14:20 rmrfchik: sure
14:20 RSpliet: there must be some third-party repositories with 4.7 kernels for Debian...
14:21 RSpliet: (but then, I don't know Debian so well myself)
14:21 kloofy: RSpliet: testing for ignorance, so what do you use as a distro then:)?
14:22 rmrfchik: may you guys know how to fix slow cairo in debian? all I found is discussion in 2012 how cairo is buggy and there is patch for it
14:23 kloofy: rmrfchik: no idea, but can't see a reason why that should be slow, however where is the cairo used , i.e where you really actually need it?
14:24 rmrfchik: i suppose this is why libreoffice/firefox slow scrolling
14:25 RSpliet: rmrfchik: also note that you have both nouveau *and* the official driver installed - or at least traces of it
14:25 karolherbst: rmrfchik: try an updated cairo?
14:25 rmrfchik: like this https://devtalk.nvidia.com/default/topic/523281/linux/cairo-performance-regression-/
14:25 kloofy: hmm, so firefox and libreoffise are using cairo...ok did not know that but...it's enough of me i think here, can someone like pq or RSpliet confirm that they get my point
14:25 rmrfchik: karolherbst: latest in debian
14:25 karolherbst: rmrfchik: what is the output of glxinfo?
14:26 karolherbst: rmrfchik: which I assume is still old ;)
14:26 RSpliet: the official drivers libGL is incompatible with nouveau (and vice-versa). You might want to double-check you're using all components of a single-driver and your computer isn't trying to mix-and-match
14:26 kloofy: and it would be the time for me to leave, it's a silly code, i am quite sick of thinking about this, but it's very easy to be done
14:26 rmrfchik: http://pastebin.com/Jg6Ljafa
14:26 rmrfchik: I switched glx to mesa/nouvea
14:26 karolherbst: rmrfchik: that's all?
14:26 rmrfchik: nooop
14:26 kloofy: but i again lack hw for time being, i gave my kepler away, and nv50 lappy is being fixed
14:27 rmrfchik: a lot of more, you need all
14:27 karolherbst: yes
14:27 rmrfchik: http://pastebin.com/XEkaxbJZ
14:27 karolherbst: looks good
14:29 rmrfchik: cairo 1.14.6 is latest and it is in debian
14:29 kloofy: i would not encourage to pay attention for those bugs, this minor pseudo i did with 30minutes here, only the basic formation of the idea is important there
14:29 rmrfchik: may be problem is not in cairo, but choppy scrolling with 100% CPU in Xorg bring me to knees
14:30 RSpliet: rmrfchik: Firefox statically links its own fork of cairo I think
14:30 rmrfchik: the main problem is in libreoffice
14:31 rmrfchik: and it works like a charm with nouveau, i was very happy with it
14:31 rmrfchik: until kernel panic :(
14:32 kloofy: dor it to reliably work on radeon minor more work is needed, and and in real ISA, i.e the implementation of CE or ME engine COPY_DATA or poll stuff, several options there
14:34 karolherbst: rmrfchik: I am sure we can somehow track down the issue
14:35 karolherbst: and we should really stop on using waits on hardware without timeouts :p
14:36 rmrfchik: how I can help?
14:36 karolherbst: ohh wait, here is a timeout.. silly me
14:36 karolherbst: rmrfchik: try to figure out if something special triggers that
14:36 karolherbst: if that happens at random -> bad
14:37 karolherbst: maybe stopping the youtube video caused that
14:37 kloofy: let's just say i am occupied with one project here, but probably will get some time to implement it , if someone were to make a xorg page donation for this stuff, then i can organise this code, otherwise i still would not have time and resources to do this from my spare time
14:37 rmrfchik: i still think its linked to transparency somehow
14:37 RSpliet: karolherbst: no I've observed random hangs on NVA3
14:37 karolherbst: if that was vdpau accelerated, nouveau might have accelerate it through vdpau
14:38 karolherbst: RSpliet: :/
14:38 kloofy: i would get some time after 3-4months or so only if a little donation for the efforts could be organised
14:38 rmrfchik: because I have enabled effect (sorry, I'm translating back to english) "slow show and hide windows"
14:38 kloofy: then probably i would make both the sched codes and this kinda a implementation to work out
14:38 kloofy: but for now, it's bye bye from me, have a good one
14:38 rmrfchik: and when window brings up there is a chance to lockup
14:39 karolherbst: rmrfchik: interessting
14:39 RSpliet: rmrfchik: unlikely, although it might occur more if you use a 3D desktop compositor (as compared to a 2D desktop env like XFCE)
14:39 rmrfchik: (xfce can composing too)
14:39 karolherbst: yes, but not 3d based
14:39 RSpliet: I suspect there might be something wrong in the context switching firmware or its golden values
14:39 rmrfchik: ahh
14:39 karolherbst: it doesn't use opengl at all
14:40 rmrfchik: well, let me switch kde to xrender
14:40 karolherbst: well, you can also use xfwm4 with kde
14:40 karolherbst: you can easily switch there
14:40 RSpliet: rmrfchik: it'd only be a stopgap solution, it reduces the likelihood of occuring but not eliminate it altogether
14:41 rmrfchik: anyway I use compositing because with nouveau all new windows appears with garbage at first.
14:41 rmrfchik: like "BAM GARBAGE" and then here is you window
14:41 rmrfchik: with compositing no such thing happens
14:42 rmrfchik: switched to xrender, will see results
15:32 epdv1: I've just installed the nouveau driver (NVE4 / GK104M [GeForce GTX 860M] (rev a1) temperature sensor). When I try to detect temperature, I get the following output (using "sensors -u"): http://pastebin.com/iGnVR40W
15:33 epdv1: What am I doing wrong?
15:33 epdv1: Em, sorry, the question is about the temp sensor, whose value cannot be read
15:34 epdv1: BTW, using latest Linux kernel (4.7.2).
15:37 pmoreau: No idea… I guess `sensors` has the same error?
15:37 karolherbst: epdv1: card is suspended most likely
15:38 karolherbst: and returns -EAGAIN or something like that
15:38 pmoreau: Ah right, didn’t thought of that
15:38 epdv1: Without "-u" it just shows "N/A" for the value
15:38 karolherbst: right
15:38 karolherbst: the gpu is off
15:38 karolherbst: so it can't do anything
15:38 karolherbst: and we can't really ask it something either
15:38 karolherbst: and waking up on hwmon access is kind of dumb
15:39 karolherbst: epdv1: run something like glxgears offloaded on the gpu and sensors should print stuff
15:39 karolherbst: this is expected behaviour
15:39 epdv1: Ah, okay - I'm not a linux expert, just trying to get my optimus laptop working
15:39 karolherbst: ohh okay I see
15:39 karolherbst: did you try DRI_PRIME=1 glxinfo?
15:40 karolherbst: epdv1: but if you don't really want to use open source drivers and simply don't care, you should use nvidia + bumblebee
15:40 epdv1: I removed bumblebee, as I should use Prime ... I'll try
15:40 karolherbst: allthough nvidia won't tell you the power consumptions
15:40 epdv1: Nvidia didn't work successfully, either
15:41 karolherbst: I guess you messed the installation of bumblebee up a bit
15:41 karolherbst: usually you should always use distribution packages
15:41 karolherbst: and don't install anything yourself
15:41 karolherbst: the package manager usually does the right thing
15:42 epdv1: http://pastebin.com/EQ18gh2V
15:43 karolherbst: nice
15:43 karolherbst: then you can do DRI_PRIME=1 glxgears
15:44 karolherbst: and sensors will start to print the usefull values
15:44 epdv1: Using archlinux, but couldn't get enough info about how to use optimus - seems somewhat tricky
15:44 karolherbst: well
15:44 karolherbst: it works
15:44 karolherbst: you just did
15:45 epdv1: http://pastebin.com/A6Y9hHSj
15:47 karolherbst: epdv1: you can ignore that error, that is just glxgears being silly
15:47 karolherbst: the gpu will turn off after 5 seconds after last use
15:47 epdv1: http://pastebin.com/hYmRAaT0
15:47 karolherbst: seems to work then :)
15:47 epdv1: Okay, thank You :)
15:47 karolherbst: well, the gpu still runs on lowest clocks
15:47 karolherbst: so performance is… bad
15:48 karolherbst: you can change the performance state by hand though
15:48 epdv1: Oh - can I fix that?
15:48 karolherbst: but with unpatched nouveau, it might be unstable
15:48 karolherbst: it depends, do you need a fast gpu yet? this issue will be resolved by itself in a few months (hopefully), just need to get patches into mainline kernel
15:49 karolherbst: you can change the performance state through /sys/kernel/debug/dri/1/pstate
15:49 karolherbst: as root
15:49 karolherbst: cat pstate for various perf states (usually 07, 0a, 0d, 0e and/or 0f)
15:49 epdv1: Ah, okay, I'll probably better wait for the fix
15:50 karolherbst: yeah, better is
15:50 karolherbst: also you would hang your kernel when you change the state while the gpu is suspended
15:50 epdv1: I'm using graphics mainly for minecraft ;)
15:50 karolherbst: uhhh
15:50 karolherbst: for that, it won't be fast enough
15:50 karolherbst: there you really want the higher perf state
15:51 karolherbst: but if the intel one is fast enough for now, you can wait
15:52 epdv1: I don't have any perf issues with minecraft, and it also runs with lower performance (even on my old laptop)
15:52 karolherbst: ohh, k
15:52 karolherbst: maybe they improved things then
15:53 epdv1: My problem is currently: my system gets too hot. That's why I wanted to find out about sensors - and fan speed
15:53 karolherbst: mhh
15:53 karolherbst: most likely the cpu
15:53 karolherbst: the gpu don't really get hot
15:54 karolherbst: especially if the gpu is turned off
15:54 karolherbst: but CPUs on laptops get up to 99°C by design
15:55 karolherbst: well only as long as under heavy load
15:55 epdv1: Okay, so at least I can disclose the GPU as a source of failures :)
15:55 karolherbst: though
15:55 karolherbst: right
15:55 karolherbst: doesn't sensor print the cpu temperature?
15:55 epdv1: Yes, usually about 55 degrees, on heavy load more than 80 deg.
15:56 karolherbst: k, well seems like the cpu it is then :p
15:57 epdv1: Some days ago my system switched off because of the heat - I don't want to have this again, as data might get lost ...
15:58 epdv1: Before some update, fan was sometimes very loud, obviously it switched to max speed, when the CPU was too hot - but that's better then overheating the CPU ...
15:59 epdv1: Unfortunately, there where many updates, so I cannot say exactly, what caused the problem.
15:59 karolherbst: your fan isn't controlled by the OS
15:59 karolherbst: but by your firmware
15:59 karolherbst: (hopefully)
16:00 epdv1: Hm, thamk You, so this might be the problem - it seems, firmware has also been updated
16:00 karolherbst: maybe you can change fan settings within the firmware, or just clean your laptop a bit :p
16:01 karolherbst: usually at full load, my CPU is at around 95-98°C
16:01 karolherbst: it is just the design of new mobile chips
16:03 epdv1: Hm, firmware has not changed since July 30th.
16:04 imirkin_: rmrfchik: did you get your issue figured out? if not, can you summarize? (i'm lazy and don't feel like reading scrollback)
16:04 epdv1: CPU temp at 95-98° is bad in my opinion, as sensors say e.g.: Core 0: +54.0°C (high = +84.0°C, crit = +100.0°C)
16:04 epdv1: So, I'd say temp. should note rise above 84°
16:05 karolherbst: epdv1: right, but that's just how those new cpus work, especially intel
16:05 karolherbst: increase clock/volt until you hit 99°C, then drop
16:06 epdv1: Thank You for clarifying that! Now I know my laptop is designed to give up early :(
16:06 karolherbst: I also have like random crashes or shutdowns for unknown reasons
16:06 karolherbst: sometimes it happens after a month
16:06 karolherbst: sometimes earlier
16:08 epdv1: Hm, thank You!
19:04 karolherbst: he
19:04 karolherbst: ...
19:05 karolherbst: silly alt+tab, doesn't work, at all
19:09 karolherbst: seriouosly, why does every web search engine suck so much these days?...
19:21 NanoSector: i like duckduckgo, but google sometiems gives me more relevant results
19:22 karolherbst: even google results are terrible
19:24 NanoSector: true
19:25 NanoSector: most of the time i'm like "that's not even what i asked for D:"
20:21 karolherbst: RSpliet: did you figure out already how to find the location of the address of the pmu stored in sysrem for fermi?
20:22 imirkin_: you can see the pmu code uploaded in a mmiotrace
20:22 karolherbst: mhh well yeah, but I wanted to port nvagetpmu over to kepler
20:22 karolherbst: and nvagetpmu reads it out from sysmem through the 0x700000 window
20:23 imirkin_: 0x700000 window? is that the mem peephole thing?
20:23 RSpliet: karolherbst: I personally don't really care where the PMU firmware comes from, I only need it once
20:23 RSpliet: imirkin_: aye
20:23 karolherbst: ...
20:23 karolherbst: at least I know it is the usb keyboard of my laptop turning it on, damn you broken keyboards...
20:24 karolherbst: :)
20:24 karolherbst: RSpliet: well if you just need it once, you can find it in the mmiotrace as imirkin_ said
20:25 RSpliet: it doesn't use the 0x10a18x code window to upload PMU, rather sets up a channel for it and then DMA's it in
20:26 karolherbst: hakzsam: when do you plan on using reator over the weekend? I plan to do some stuff there
20:26 karolherbst: RSpliet: I see
20:26 RSpliet: so the opcodes don't appear in the trace
20:26 karolherbst: but isn't the channel setup inside 0x10a47c or so?
20:27 karolherbst: or is that for gt215 only
20:27 RSpliet: yes, that's where the virtual address lives
20:27 karolherbst: mhh, k, this is exactly what I've tried on my, but the 0x700000 window points into random stuff
20:27 RSpliet: the pagetable translates that virtual address into a physical address in the hosts DRAM, that's how it works on GT21x, and that's how nvagetpmu finds the firmware
20:27 RSpliet: 700000 window takes a physical address
20:28 karolherbst: yeah well, I did the same as on gt215 just for testing
20:28 karolherbst: but I guess that won't work
20:29 karolherbst: mhhh wait
20:29 karolherbst: 0x10a47c should contain the physical address
20:29 karolherbst: wouldn't make sense otherwise
20:29 RSpliet: on
20:29 RSpliet: *no
20:29 karolherbst: let me check something
20:29 hakzsam: karolherbst, I'm using it right now, and I plan to use it few hours on saturday, but not on saturday evening+ :)
20:29 hakzsam: (I'm dealing with F1 2015)
20:29 karolherbst: RSpliet: then I don't see how the gt215 code could even work
20:30 RSpliet: the DMA engine on the PMU has a page-walker?
20:30 karolherbst: uhhhh
20:30 karolherbst: that makes sense...
20:30 karolherbst: crappy crap
20:30 karolherbst: but I also meant the nvagetpmu code
20:31 karolherbst: it reads from 0x10a47c and feeds the value a bit transformed into 1700
20:31 karolherbst: and starts to read from 700000
20:31 RSpliet: ohh wait, yes you're right
20:31 RSpliet: that's the pointer to the channel information
20:31 karolherbst: yes
20:31 karolherbst: and this thing is bogus on my kepler at least
20:32 RSpliet: sure about that? either way, that's a physical address in host mem. I found the PDE entries from there
20:32 RSpliet: but those entries don't make sense
20:32 karolherbst: right
20:32 karolherbst: when I read from some location -> gpu crash
20:37 RSpliet: anyway... with a bit of fiddling you can pull the firmware through the 0x10a180 hole. It behaves strangely if I put it in a tight loop, but surely that must be fixable with adequate pauses and redundancy
20:37 RSpliet: nice and hacky
20:39 karolherbst: 0x10a180 is just 0 for me, I guess nvidia resets that?
20:41 RSpliet: if you set 0x10a180 to 0x0, 0x10a184 contains the word at address 0
20:41 RSpliet: 0x2000000 makes reads from 0x10a184 auto-increment
20:41 karolherbst: uhhh
20:42 karolherbst: sure about 0x2000000?
20:43 RSpliet: yep
20:45 karolherbst: I only get RRRRRRRR
20:46 RSpliet: ehh?
20:46 RSpliet: nvapoke 0x10a180 0x2000000, nvapeek 0x10a180, nvapeek 0x10a184, nvapeek 0x10a180
20:46 karolherbst: ahh
20:47 karolherbst: does it read from the pmu code directly?
20:47 RSpliet: it reads from IMEM
20:47 RSpliet: 0x10a1cx does the same for DMEM
20:47 RSpliet: anyway
20:47 RSpliet: bbl
20:47 karolherbst: k
21:26 karolherbst: RSpliet: it seems that the 0x10a18x window works for me
21:27 karolherbst: very good
23:20 guest42: sup
23:21 guest42: trying to update mesa / graphix driver to latest version any help
23:22 guest42: GL_RENDERER = Gallium 0.4 on NVE7 GL_VERSION = 3.0 Mesa 11.0.2 GL_VENDOR = nouveau
23:23 urmet: sounds like your configuration is set up, just update as normal?
23:25 guest42: how do i update normally i just ran sudo apt-get upgrade then ran glxgears-info im trying to upgrade to mesa 12
23:27 guest42: i dont know that much when it comes to open source but im trying to get my driver to do a better job with open gl
23:29 urmet: probably other people know better than me but you most likely need to upgrade your kernel too in addition to mesa and I have no idea about debian(ubuntu) versions
23:38 sarnex: guest42: can you send me the entire output of glxinfo
23:40 guest42: http://hastebin.com/ofuracajah.pl
23:40 guest42: glxinfo
23:44 guest42: i know its old im trying to figure out how to update /wo fucking up my games i actualy run steam games like css and tf2 just fine play league of legends as well as running several emulators and i dont really want to set all that up agen so im trying to figure out how to do this the right way
23:46 sarnex: guest42: if you send glxinfo i can help you better
23:51 guest42: haste bin is glx info dump
23:52 sarnex: sorry my client messed up
23:52 guest42: http://hastebin.com/ofuracajah.pl
23:53 sarnex: guest42: you have 4.1, the app you are using is using the compat profile which is 3.0. we are never going to support more than 3.0 on the compat profile
23:53 sarnex: OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.0.2
23:54 guest42: thats cool i might just be asking the wrong people google dosent have much info i might have to talk to nivda thanx anyways
23:55 guest42: the latest version is 4.3 and mesa 12 u wouldent know the comand line to update would u
23:56 sarnex: what distro are you on
23:57 guest42: kubuntu
23:57 guest42: 15.04
23:57 sarnex: for ubuntu you need to use the oibaf ppa
23:58 guest42: ok i installed the keyrings earlier but couldent figure out the file name
23:58 sarnex: sudo add-apt-repository ppa:oibaf/graphics-drivers
23:58 sarnex: and then sudo apt-get update and upgrade
23:59 guest42: ok ill run it agen