00:46 antipsychiatry: Mossad dont inform israeli people about this fraud called: psychiatry
01:49 imirkin: skeggsb: you really need to do something about https://bugs.freedesktop.org/show_bug.cgi?id=91413
03:48 kloofy: this guy was right about antipsychiatry, never coworked with such institutions, haven't given a signature that i need horse amount of meds and forces stay, most conspiracistic scammers there working behalf of large set of pointless cocnpiracistic people
04:24 kloofy: well i draw an anology between the tv show called weakest link, and psychiatry, weakest link is such show where the idea is to give persons right to vote out weakest links that do not perform neededly
04:25 kloofy: what actually happens is that those weakes ones scam/fabricate out the strongest ones indeed in reality, and that what happens oftenly in psychiatry too
04:26 kloofy: it's just based of the fact, that there are more of those unsatisfied persons who fabricate things against higher ranked persons then the other the other way around
04:33 kloofy: it's just expensive when family works together to make it happen with their set of similar persons, where the defence mechanism will be halted for say talents to pull some frames back in time, though it's inevitable problem those frauds, sane person when getting along with their family which is most important will be able to avoid giving chanches to zombies
04:35 kloofy: some think that family is something special and no such issues should appear there, but few people go over that specialness and resort to playing god their own
04:38 kloofy: in such institutions it's done so to protect parents only..this could be fraud yeah, but there are certain instances that protect children too, but actually noone protects the underlying so called special persons who are likely to diserve an envy, that is the most important stuff
04:42 kloofy: yeah so it's inevitable wether there is jelousy involved among family members and in society the fabrications and violation grow exponentially, i seem to be jammed in such a case when being absolutely honest here, quite a tough situation
04:42 kloofy: but bye
04:51 kloofy: ouh yeah forgat, my so called friends, they have long since planted evidence in the end they could form a major plant and i'd loose that is fake evidence, so it's always social groups aside from family can't be depended on here at least their always against persons who can compile legit runs, in my case i had been whitewashed/violated in the family exactly the same way, i'd rather difficult, who applied pressure in
04:51 kloofy: the end to make them to cowork against me
04:51 kloofy: cheers.
07:37 kloofy: Calinou: sorry for highliting for the last time, i reccoment as it seems to kickstart your rom/firmware researches on devices like FPGA's and see if you at all want to move somewhere else from there, mid-level devices can be connected together, and yeah with kintex ultrascale and arria 10 bigger devices, the 600-700mips throughput is real
07:38 kloofy: sorry 600k-700k mips
07:40 kloofy: and for the final time also, i had patents for this too, showing that that it is possible to fetch fixed function pipeline kernel with an interrupt trace, i have not really done that yet, but its possible on/with all vendor chips
07:41 kloofy: but surely modified versions of the llvmpipe or this new intel stuff, would work too
07:45 kloofy: and for the clarfication, all though i have not taken a real look, i think that intel as company has been economically very successful, lets say financially since seems they have had good tacticians, which allowed them to buy off/acquire basically techonologically bigger company
07:48 mupuf: imirkin, karolherbst: it is quite possible that clock gating should be deactivated before power gating
07:49 mupuf: in any case, following what the tk1 does it probably a good idea
07:53 kloofy: and for those chips yeah the highest in those mid-level series, i did rough caclulation, all the locis consists around 10billion of transistors, which is the calcs that can be roughly trusted, well connecting to of those together with hypertransport will beat pascal
07:55 kloofy: i can work on both technologies asics and fully programmable ones like fpga's and cpld's but definitely the last ones bring the bigger smile to my face
07:57 kloofy: minor rest again among asics chips for different vendors there also does not appear to be an even minor problem, designers seems have been smart and consistent there too recently
08:01 kloofy: Calinou: i reccomend the si-programming.guide.pdf in addition to register reference and ISA for radeon, how to drive the card, you should be able to see, that firmware isn't important, every mmio reg can be polled etc. rewritten with engines and they have logics that also work good
08:07 kloofy: i talked just a bit with agd5f his an open guy, he appears to be emplyd by amd to take care of the firmware bits and some other stuff, well he confirmed the only needed stuff, that tiles are per pixmap/surface and you can have as many as you want
08:09 kloofy: it's just carrier importance only for nouveau project, that karolherbst skeggs mupuf imirkin and others deal with firmware integrations, cause there is noone emplyd by nvidia to handle that
08:09 kloofy: if amd guys do a good job for the firmware i don't think there would be any security risk to have it in binary forms
08:10 kloofy: overall there are mass surveilance techniques that are nastier them some loggers via electronic firmwares anyways
08:11 kloofy: them/than
08:18 kloofy: back to work now, it takes time to offer software for programmable devices that is the only deal at the moment, hw is there at least, that is the satisfying situation for me, software can be added it's totally possible but is still a work and even a bit extensive
08:19 kloofy: i also recommend to read one more thesis, where one persons uses verilog-A to lay out a minor fpga fabric
08:21 kloofy: my understanding is that this optimized tool quartus II has a free edition that has all the features included
08:22 kloofy: it does not support analog verilog or vhdl , while iverilog supports some minimum features of that, but hey still a nice situation for the designers to compose circuits on those devices without paying huge amounts of money
08:27 karolherbst: mupuf: problem is, the tk1 doesn't do anything, I already checked. The only means to disable clock gating is throgh debugfs
08:28 kloofy: there are open source tools to do all sorts of design, but never experiented with those, i just know for sure that altera tools work ok, and probably xilinx ones too
08:29 karolherbst: and on tk1 only graph is clock gated anyway
08:30 kloofy: there is also ami semiconductor that has good chips and some which i forgat a known fpga, that is clocked to 1ghz with frequency that had some vendor i never heard about before
08:32 karolherbst: ohh wait, and CE2 is also clock gated
08:33 kloofy: overall world large and wide and there are always persons who do solid work too in different areas including computer technology
08:33 kloofy: is
08:35 kloofy:is surveilanced daily basis too, but i won't violate any license agreements to do stuff anyways, i've always chosen legit tools, my synthesis tools are based of llvm permissive licenses
08:36 karolherbst: mupuf: there is a nice dbg_set_powergate function though in the tk1 sources
08:37 kloofy: i find writing c more conveniant then vhdl or verilog, and verilog, the fact is that synthesis can take care of many repetitive steps too anyways
08:37 karolherbst: which also gets only called through ioctls
08:39 karolherbst: basically clock gating is enabled when gk20a_init_gr_support or gk20a_gr_reset is called
08:39 karolherbst: and I really would do the same in nouveau
08:43 kloofy: and btw. i don't mind in contrast to hexedit, if someone uses my ideas and acheives something, my ideas are free to be used, i do not financially charge or come back saying it was my idea, now pay for me, the other day i just meant that i've had ideas and i just might be treated with respect too
08:47 kloofy: the info i've provided is backed up with scientiftic researches i've gathered from net anyways so, i would not make it on my own even if i am right i have no such rights, i always need references, that some respectful human thinks the samewise
08:49 kloofy: but yeah i've playd a bit cat and mouse just thinking the theory all my own and then finding prove for those ideas who look really neat, proof has always been there, that someone exactly thinks the same
08:50 kloofy: if you want to sabbotage this does not matter, cause net is full of independent scientists, whose theories are most oftenly consistent with my neat looking ideas
08:54 kloofy: i am bit embarrassed that 33 year old man talks about some sort of bits, and science, but i was not planning this i was hampered in the beginning of my life, i tried to do the research quietly and early on, but was blocked all the way, now i have been lagging behind a lot, and other violators have better chanches
08:54 kloofy: but anyways good luck!
09:02 kloofy: ah yeah one more thing, i am aware of the thing that going overseas theyd wonder where is you universities or overall countries scientiftic research that you want to get payment for reprenseting your education, i am not aware how the situation is in estonia overall aside from the fact that people just are not involved in active field of science
09:03 kloofy: maybe they are shy maybe dumb, i do not know for all of them to be certain, those who have faught against me are more like trashydumb, but there could be someone who is shy but smart too
09:03 kloofy: so bye
09:46 karolherbst: imirkin: mhh, I think that hang is somewhat kernel module related, cause it also happens with 12.0.0-branchpoint
09:58 karolherbst: now I am wondering if we are able to dual issue add + min, because my patch only enables min/max pairs now...
09:58 karolherbst: ohh wait
09:58 karolherbst: no, it is fine
09:59 karolherbst: my patch only affects the case where both instructions have the same opclass
10:19 karolherbst: imirkin: yep, it is something in the kernel module :)
10:30 karolherbst: gnurou broke it :O
10:30 karolherbst: https://github.com/skeggsb/nouveau/commit/8fc2737c6b4da675358f12b3b714af0f4a9c390c
10:31 karolherbst: or I simply need a newer kernel
10:32 karolherbst: skeggsb, gnurou: any idea why above commit causes a fence timeout with shader-db?
10:44 mupuf: karolherbst: on what hw?
10:44 mupuf: I have had this issue on my tk1 for months
10:44 karolherbst: kepler
10:44 karolherbst: my machine
10:44 karolherbst: reverting that commit helps
10:45 mupuf: oh, that is great to know! That means I could finally start doing daily testing of piglit on the tk1
10:45 karolherbst: the parent commit also does something related to that
10:46 mupuf: how did you find this commit? Bisect?
10:46 karolherbst: yep
10:46 mupuf: very good, thanks a lot
10:46 mupuf: I was assuming it was an issue only on my tk1
10:46 karolherbst: much faster if you don't need to reboot your machine :D
10:48 karolherbst: at first I thought it is due to me rebasing bens tree and remove the drm-next commits
10:48 karolherbst: but if you have the same issue, then something is most likely indeed broken
10:50 mupuf: well, yeah, but it is an issue with gbm too
10:50 mupuf: never had the issue otherwise
10:51 karolherbst: and now I have to figure out why enabling postraconstfolding on kepler causes some shaders needing more instructions or gprs...
10:51 karolherbst: mupuf: mhh, yeah maybe it is indeed a gbm issue
10:51 mupuf: anyway, my workaround was to get rid of the destructer of gbm
10:52 mupuf: but this is of course not satisfyin
10:52 mupuf: g
10:52 karolherbst: right
10:57 mupuf: bbl
12:05 karolherbst: I am sure I will post that branch to the ML later today: https://github.com/karolherbst/mesa/commits/postraconstanfolding
12:05 karolherbst: I have some things in mind I still have to check (mask of the immediate, maybe other things)
12:06 karolherbst: if somebody has any complaints already, please go ahead
12:10 karolherbst: I will also run piglit on my tesla against those changes
12:28 jneto: kernel 4.4 introduced some bugs.
12:28 jneto: reclocking isn't working with my NVS 3100m (NVA8).
12:28 jneto: https://bugs.freedesktop.org/show_bug.cgi?id=96411
12:29 karolherbst: jneto: ever tried something newer? chances are, it is fixed
12:29 karolherbst: and what you mean by "glitches"? it is just messed up and unable to be used?
12:30 jneto: yes, my current kernel is 4.7.2 and the bugs are there.
12:30 karolherbst: k
12:31 karolherbst: did you try higher pstates?
12:31 jneto: no
12:31 karolherbst: I think we enabled something on those kernels for teslas
12:31 karolherbst: maybe memory reclocking
12:31 jneto: only lower.
12:31 karolherbst: and maybe 03 is just too slow
12:32 jneto: 4.3 is ok, pstate works.
12:32 karolherbst: right, but did you verify that all clocks are changing?
12:32 karolherbst: according to the last line
12:33 jneto: how do I check this?
12:33 karolherbst: last line vs 03 line
12:33 karolherbst: mhh, yours is a GDDR5 tesla
12:33 karolherbst: RSpliet: any ideas?
12:33 karolherbst: ohh wait
12:33 karolherbst: it is gddr3
12:34 karolherbst: my mistake
12:34 jneto: ah, ok. yes the clocks are changing.
12:34 karolherbst: there are indeed some gddr3 related changes
12:34 karolherbst: jneto: all of them?
12:34 jneto: yes.
12:34 karolherbst: on 4.3?
12:34 jneto: yes
12:34 karolherbst: k
12:34 karolherbst: if you have time you can try to git bisect the issue
12:34 karolherbst: or wait until RSpliet says anything
12:35 karolherbst: jneto: you could try to revert this commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramnv50.c?id=4d9faafa0fdda2f4ba04b5cdffc0af1bab2312f4
12:35 karolherbst: but I would have to guess what the issue is
12:40 karolherbst: any of those commits should be at fault then: https://gist.github.com/karolherbst/172442f17d2f828f597f11070db16e9a
12:41 karolherbst: jneto: I don't believe you that the memory clock changes on your gpu on 4.3, because gddr3 memory reclocking was enabled in 4.4
12:42 karolherbst: ohh, I am silly
12:42 karolherbst: no, you are right I guess
12:42 karolherbst: nva8 is gt218
12:42 karolherbst: not someting in between "G94-G200"
12:47 jneto: look for RSpliet messages from 20:18-20
12:47 jneto: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2016-06-05
12:53 jneto: I found other annoying bug.
12:53 jneto: When I open some videos with mpv (vdpau enabled), my screen freezes.
12:54 jneto: Again, these videos are ok on 4.3, this bug was introduced in 4.4.
12:54 jneto: nouveau 0000:01:00.0: mpv/vo[2756]: failed to idle channel 9 [mpv/vo[2756]]
12:55 jneto: This is the last message from nouveau.
15:10 karolherbst: mupuf: did you see the fermi trace I posted yesterday?
15:10 mupuf: karolherbst: yes, didn't I answer to it this morning?
15:10 karolherbst: uhh, let me check
15:11 karolherbst: ohh right
15:11 karolherbst: I actually read that
15:12 karolherbst: sadly I don't have my fermi anymore to try things out :(
15:13 RSpliet: karolherbst: what needs going on a Fermi?
15:13 RSpliet: there's one plugged in here
15:13 karolherbst: RSpliet: clock gating
15:13 karolherbst: for 20200 60 flip 0x3 to 0x1, that would be the test
15:13 karolherbst: and if nothing bad happens, it would be good
15:14 RSpliet: on nouveau?
15:14 karolherbst: yeah
15:14 karolherbst: does nouveau print power consumption?
15:14 karolherbst: mhh, I mean is it exported via hwmon on the one you have there
15:14 RSpliet: unlikely
15:14 RSpliet: don't think they added power sensors until Kepler
15:15 karolherbst: they did
15:15 RSpliet: anyway
15:15 karolherbst: fermi has ina219 usually
15:15 karolherbst: and keplers have usually a ina3221
15:15 RSpliet: you can check my NVCE VBIOS to double-check what's inside
15:15 karolherbst: k
15:15 RSpliet: running an upstream 4.7 kernel atm
15:15 karolherbst: usually only mid+ end gpus have them though
15:15 RSpliet: what
15:15 RSpliet: s the 60 for btw?
15:15 karolherbst: range
15:15 karolherbst: nvapoke 20200 60 ...
15:16 karolherbst: there are a few regs for clock gating, each for another engine
15:16 RSpliet: oh all registers following you mean?
15:16 karolherbst: yep
15:16 karolherbst: like what nvapoke 20200 60 value would do
15:16 RSpliet: https://paste.fedoraproject.org/421706/73002199/
15:17 RSpliet: is that an expected default state?
15:17 karolherbst: nvapoke 20200 60 27722445
15:17 karolherbst: yeah, those 44 at the end are engine set to run
15:18 karolherbst: RSpliet: yep, your card doesn't have any sensors
15:18 karolherbst: so the best way to verify it, is to clock to max
15:18 karolherbst: let temperature stabilize
15:18 karolherbst: enable clock gating
15:18 karolherbst: see if temperature goes down a little
15:19 RSpliet: which bit should be altered?
15:19 karolherbst: 0 and 1 to 1
15:20 karolherbst: the poke I gave you should do it ;)
15:20 RSpliet: okay that didn't crash my machine
15:20 RSpliet: but I don't think I should change clocks much
15:20 RSpliet: given memory reclocking is far from finished :-P
15:21 karolherbst: well
15:21 karolherbst: doesn't matter
15:21 karolherbst: because clock gating usually only affects the engines
15:21 karolherbst: like graph or pcopy
15:21 RSpliet: I know
15:21 RSpliet: but... ah fuck it, yolo
15:21 karolherbst: ohh you mean for stability
15:21 karolherbst: mhh
15:21 karolherbst: :D
15:21 karolherbst: well
15:21 karolherbst: you can also just disable memory reclocking
15:21 RSpliet: think the engines are quite stable
15:21 RSpliet: should be disabled by default
15:21 karolherbst: we should enable engine reclocking on fermis anyway
15:21 BoRiS: :-)
15:22 karolherbst: even if that doesn't do much in avarage, but 25% more perf is 25% more perf
15:22 RSpliet: oh, it's disabled yeah, that requires a reboot... don't have time for that right now
15:22 BoRiS: yeah
15:22 karolherbst: and some crazy workloads benefit even more
15:22 karolherbst: RSpliet: k, no problems
15:22 RSpliet: sorry
15:22 RSpliet: but at least the poke doesn't turn my GPU tits up
15:22 karolherbst: RSpliet: but it is good to know that just enabling it, doesn't cause any harm yet
15:22 karolherbst: yep
15:23 RSpliet: but on Tesla there used to be a mountain of parameters that you needed to push to random registers (JOE's) before that had any effect
15:23 RSpliet: think mupuf renamed to BLCG regs
15:23 RSpliet: params for subcomponents that describe... mupuf knows that stuff better than I do ;-D
15:23 karolherbst: yeah, might be
15:23 karolherbst: at least I know for sure that it didn't affect stability of my kepler
15:24 karolherbst: maybe I try to figure things out on my tesla
15:24 karolherbst: because my tesla doesn't any fans
15:24 karolherbst: and it gets quite hot
15:26 mupuf: RSpliet: I renamed them to BLCG and SLCG
15:26 mupuf: based on nvidia's documentation of the tk1
15:27 RSpliet: block-level and... subdev-level?
15:27 mupuf: not sure we actually made sense of what SL means
15:28 mupuf: karolherbst: actually, the rule is easier
15:28 mupuf: high-end cards got INA219
15:28 mupuf: because they monitor the rails continuously
15:29 karolherbst: well, on kepler they all get ina3221s
15:29 mupuf: not true
15:29 karolherbst: there are a _few_ exceptions to this
15:29 mupuf: middle-range get the INA3221 because there is one ADC for 6 measurements
15:29 karolherbst: but usually you only find ina3221s
15:29 mupuf:thinks we just did not get a lot of expensive keplers ;)
15:29 karolherbst: mupuf: Tom^ 780 ti has a ina3221 too
15:30 karolherbst: and that is already pretty much high end ;)
15:30 mupuf: in any case, this is not necessary to make rules ;)
15:30 mupuf: ohm interesting
15:30 Tom^: i have no such thing!
15:30 Tom^: whats that anyways :p
15:30 karolherbst: mupuf: I am sure every nvf1 we have a vbios from has a ina3221
15:31 karolherbst: mupuf: yep, every single one
15:31 karolherbst: and we have 7
15:31 RSpliet: oh I never pushed mine I see...
15:31 RSpliet: "mine"
15:31 karolherbst: :D
15:31 RSpliet: as if the computer lab is mine
15:32 karolherbst: we already know the truth :p
15:32 mupuf: karolherbst: fair point :D
15:32 karolherbst: don't hide it
15:32 mupuf: but anyway, it does not matter. What matters is that on Fermi, only high-end cards have power sensors
15:33 karolherbst: yeah
15:33 RSpliet: and the Fermi in my machine does not appear to be one of them
15:33 karolherbst: but it is save to say that mid end gpus also sometimes have one
15:34 RSpliet: saying safe things is boring
15:34 karolherbst: I know
15:34 karolherbst: :D
15:35 RSpliet: meh, I want to take a week off and just lock myself up in my room to fix this bloody thing
15:35 karolherbst: a week well spent
15:35 RSpliet: 'd be so much more effective than wasting half an hours here and there
15:35 RSpliet: yeah, can't really justify that though
15:36 mupuf: RSpliet: so true
15:38 karolherbst: well at least I have the week + monday off when xdc is :)
15:38 karolherbst: as if I would do anything constructive there :D
16:58 imirkin: skeggsb: did you see RSpliet's patch for bios opcode 0xaf? apparently that happens in GP104 VBIOSes
16:59 imirkin: jneto: someone else recently reported vdpau hangs with recent kernels on a NVA8... BoRiS i think it was.
17:13 kloofy: and listen we have solved the differences with airlied i really truely belive in that, i never intended to block his advancing, my idea was to get stronger and develop further together where i sometimes advocated what looks the right thing to do for me
17:14 kloofy: and on the #asm channel what looks like a fight does not have any real conflict in it actually
17:16 kloofy: if that so called a trustworthy hacker/gentelman has had troubles i can assure you non of those have been arranged by me
17:18 kloofy: and i just really signalled that i have some of the fuzz round my life, that we'd not endorse conflicts that i can not control or handle publicly
17:20 kloofy: i am just tiny doll here, but whole army of people behind doing god knows what , so that is why
17:22 BoRiS: imirkin: Yeah, that was me!
17:23 BoRiS: I foudn the Xorg commit that broke it
17:23 imirkin: BoRiS: jneto says it worked with 4.3 but broke in 4.4 - is that what happened for you?
17:23 imirkin: BoRiS: oh right ... that weird poll thing
17:23 BoRiS: imirkin: yeah
17:23 imirkin: was that in Xorg 1.18.x or just the upcoming 1.19 release?
17:24 kloofy: i said quite lot and threattened but probably all know that i am busy for the next 20years and really busy, to go trolling because of some bans and start sort of war only because of that
17:24 BoRiS: in the upcomign 1.19 release
17:24 BoRiS: thats where the bug is in
17:24 imirkin: BoRiS: have you let anyone know in #xorg-devel ?
17:25 BoRiS: imirkin: I wrote in the xorg mailing list but no one really responded
17:25 imirkin: jneto: are you also running a bleeding-edge Xorg?
17:25 imirkin: BoRiS: yeah, that happens =/
17:26 imirkin: BoRiS: file a bug
17:26 imirkin: and make sure to cc the commit author on it
17:26 BoRiS: yeah, it was keith p's commit
17:26 jneto: imirkin: xorg-x11-server-Xorg-1.18.4-4
17:27 kloofy: i think everyone wants to be a trusted person in this scammy world that is all what i need, some credit of trust, that i most of the time talk about things that do exist are real and stuff
17:27 imirkin: jneto: hm, ok. so... different issue =/
17:28 imirkin: jneto: oh! mpv. i bet with GL output?
17:28 imirkin: if so, that's expected to die. don't do that.
17:28 kloofy: if not listened i got crazy at times but this won't be an issue, real troubles i have faced too, where i still think how to behave and sovle them
17:28 imirkin: use mplayer. or if you must use mpv, use vdpau output.
17:29 jneto: imirkin: yes, I'm using opengl output.
17:30 imirkin: mpv threads vpdau and GL calls. this breaks nouveau.
17:31 jneto: iirc, vdpau output was much more unreliable.
17:31 imirkin: ok. well GL output + vdpau decoding is more or less guaranteed to break with mpv.
17:31 imirkin: mplayer works great
17:32 imirkin: and it also supports decoding all videos, unlike every other player i've tried, which supports decoding a subset of all videos.
17:37 jneto: ok, I'll try it.
17:38 kloofy: but also it suddenly occured to me, that even those mentioned people who ban be have not ignored my theories, what is even more delightul not only havin read them through, but also acted upon them..yeah that is advisable but not compulsory in any way
17:38 imirkin: although i did notice that mplayer -vo vdpau with DRI3 enabled does seem to suck for some reason
17:38 imirkin: i dunno why.
17:38 kloofy: because i do talk most of the times where i have real hunches and stuff backed up too
17:38 imirkin: used to work much better with DRI2
17:38 kloofy: anyways good bye
17:41 jneto: what about compton? there is something it does that annoys nouveau?
17:44 imirkin: jneto: the less you use nouveau the more likely you are to achieve a stable system
17:44 kloofy: ouh well so that way all the things i have envisioned have game true and have been basically implemented in larger degree, makes me wonder me as my creative and volatile soul is not being ignored that much as said, especially by arilied probably who can read stuff like an a real deal
17:44 imirkin: jneto: compton is a GL compositor
17:45 imirkin: jneto: just using the nouveau ddx is pretty stable. it's a very simple piece of software.
17:45 imirkin: once you start messing with GL, all kinds of things crawl out of the woodwork
17:48 imirkin: i use nouveau every day and almost never have any crashes. but i don't have any long-running GL applications.
17:48 jneto: ok, no compton then.
17:51 imirkin: hm. something in mesa 12.0+ *destroys* vdpau when i use OSD in mplayer
17:52 kloofy: as some final comment about my own stuff, i have gotten some credit of trust recently due to providing information to the masses, and occationally talking about smart stuff, i am deciding if i cure myself to 75%degree which is enough for me to enjoy life occatinally too, depending on wether i get lots of angry and jelous people attacking me again when i feel the best
17:52 kloofy: so it's still yet dilemma which i try to solve, non-the less my life will be low-profile anyways
17:52 imirkin: i guess it's bisect time!
17:52 kloofy: i mean in both cases, bye
17:52 imirkin: gr.
19:02 hakzsam: imirkin, unlikely, I already got that message while running shader-db
19:21 karolherbst: ohh no pcie relinking is done for pascal yet :)
19:21 karolherbst: maybe I will take care of that
19:27 karolherbst: imirkin: with my postra constant folding things, a few piglit tests start to fail: some ext_transform_feedback tests "accuracy 4 depth_resolve small depthstencil" and a few others things
19:27 karolherbst: might this be expected?
19:27 karolherbst: but maybe I indeed broke it
19:28 imirkin: mmmm... a little unexpected
19:28 imirkin: the accuracy tests are a little flaky
19:28 imirkin: but TF should be solid
19:28 karolherbst: k, I will take a look
19:29 karolherbst: I am sure this commit might break something: https://github.com/karolherbst/mesa/commit/b71a4781ad717bfaa7810afdfbaf3702ca0ebf89
19:30 karolherbst: I think that isFloatType -> typeSizeof is actually not quite right maybe :/
19:30 karolherbst: but I also have no clue about that, just following what somebody told me months ago
19:31 imirkin: i was probably saying that in the context of nv50
19:32 karolherbst: well, I ran piglit on my tesla
19:35 karolherbst: with the other patch: total instructions in shared programs : 1696530 -> 1695771 (-0.04%)
19:36 karolherbst: (swapping src0 and src1 when possible)
19:42 karolherbst: huh
19:42 karolherbst: that didn't broke it
19:42 karolherbst: my swap sources commit broke those tests
19:42 karolherbst: odd
19:45 karolherbst: imirkin: " 23: mad u32 $r6 u16 $r3h $r1l $r6 (4)" -> " 23: mad u32 $r6 u16 $r1l 0x0003 $r6 (8)"
19:45 karolherbst: with " 20: mov u32 $r3 0x00000003 (8)"
19:45 karolherbst: does this sounds right?
19:45 karolherbst: no clue what that "h" is for
19:46 karolherbst: mhh, well has to be wrong, because this is the only change
19:46 imirkin: no, that sounds wrong
19:46 imirkin: h = high
19:46 imirkin: $r3h == 0
19:46 imirkin: $r3l == 3
19:47 karolherbst: ahh
19:47 karolherbst: but why does my change changes that?
19:47 imirkin: so that should just become mov $r6 $r6
19:47 karolherbst: potential opt I assume
19:47 imirkin: [which will then get nuked later on iirc]
19:48 karolherbst: yep, but still
19:48 karolherbst: ohh wait
19:48 karolherbst: I immediate the value without checking if the reg access hi or lo
19:48 karolherbst: ohhh I see
19:48 imirkin: :)
19:48 imirkin: iirc i mentioned something about that before too
19:48 karolherbst: mhh
19:48 karolherbst: then I have missed that
19:48 imirkin: but perhaps my comment didn't make sense to you
19:49 imirkin: that's what the isFloatType() was kinda guarding
19:49 imirkin: i think.
19:49 imirkin: i dunno at this point, it's all a little lost in my memory.
19:49 karolherbst: okay
19:49 karolherbst: at least I know what I break here
19:49 karolherbst: have to go through that once more
19:49 imirkin: pre-RA we expand integer mul's into that 16-bit dance
19:49 karolherbst: but the change on kepler is quite promissing
19:49 karolherbst: ahhh
19:49 karolherbst: I see
19:50 karolherbst: that's why I never had to care about that while in ssa form
19:50 imirkin: but after all the const folding
19:50 imirkin: [which is done on purpose, for the most part]
19:50 karolherbst: the BB in SSA: https://gist.github.com/karolherbst/aa53d680717586d4a8570512a72fd78d
19:50 imirkin: i guess that expandMuls() thing could be slightly cleverer
19:50 imirkin: [in fact i thought i had done that at one point...]
19:51 imirkin: right, but we can't loadpropagate quite yet
19:51 imirkin: since the regs have to line up in order for it to matter
19:51 karolherbst: no, I meant we still can nuke that mad away
19:52 karolherbst: r140s is the high part of %r129 right?
19:52 karolherbst: and that is 0x0
19:52 karolherbst: now that I think of that
19:52 karolherbst: the entire bb doesn't make much sense :D
19:52 karolherbst: like everything gets nuked away at some point
19:53 imirkin: expandIntegerMUL
19:53 imirkin: the logic could probably be more fine-grained
19:54 imirkin: you could try swapping sources in there too
19:54 karolherbst: uhh, first I wanna fix my patches though :) and most likely I won't care enough about tesla to actually do that :/
19:54 karolherbst: I guess I will just create a trello card so we don't forget about that
19:55 imirkin: ok
19:56 karolherbst: what does that "s" means in the split by the way?
19:57 imirkin: short
19:58 karolherbst: ahh
19:58 imirkin: i think
19:58 imirkin: i.e. 16-bit
19:58 karolherbst: does that sounds right? https://trello.com/c/TnbFrUmM/162-nv50-optimize-splitted-immediate-used-in-mul
19:58 karolherbst: changed title: https://trello.com/c/TnbFrUmM/162-nv50-optimize-splitted-immediate-used-in-mul
19:58 karolherbst: ohh the link persists
19:58 karolherbst: https://trello.com/c/TnbFrUmM/162-nv50-optimize-mul-with-splitted-immediate
19:59 karolherbst: hihi
19:59 karolherbst: k
19:59 karolherbst: ohh wait
19:59 karolherbst: that mov was for mad
20:01 Exagone313: Hi, a friend of mine helped me before to install nouveau, and made me extract some parts of the nvidia installer, to play videos, but I'm not sure what the script extracts, https://github.com/imirkin/re-vp2/blob/master/extract_firmware.py Apparently it's a known script so you might know it. Also, depending to your reply, is this still useful? Thanks for your help.
20:01 karolherbst: it is, but won't work on newer gpus like maxwell
20:01 Exagone313: ?
20:01 Exagone313: what does it extracts?
20:01 mupuf: Exagone313: and will need work because we changed the naming convention of files
20:02 mupuf: imirkin: ^^
20:02 karolherbst: Exagone313: firmware files for the video decoding engines on the gpu
20:02 karolherbst: we didn't write our own, yet
20:02 Exagone313: I see
20:02 karolherbst: and most likely never will, because it is painful lot of work
20:03 karolherbst: but if anybody wants to write own ones, please go ahead :)
20:05 imirkin: mupuf: not for vdpau
20:05 imirkin: mupuf: filenames only changed for the gr ctxsw fw
20:06 Exagone313: How are those files used? Are they needed only for nouveau? Because finally I remember I use modesetting here (with a NV126 so maxwell), and I remember having trouble watching videos before using them (with nouveau?)
20:06 imirkin: Exagone313: maxwell is not supported for now
20:06 imirkin: Exagone313: that firmware is necessary to operate the video decoding engines... nouveau uses it, and obviously the proprietary nvidia driver uses them
20:07 imirkin: since the data is not redistributable, i opted to create an extractor that finds them in the nvidia blob
20:07 imirkin: Exagone313: but no one's taken the time to figure out how to operate the maxwell video decoding engine (yet)
20:08 imirkin: it is structurally different than the earlier engines, but for all we know not many changes will be necessary
20:09 imirkin: you can find the status of video decoding acceleration at https://nouveau.freedesktop.org/wiki/VideoAcceleration/
20:09 karolherbst: imirkin: which VP versions did you RE by the way? VP4 or something else?
20:09 imirkin: karolherbst: VP2
20:09 karolherbst: ahh I see
20:09 karolherbst: who did the other ones?
20:10 imirkin: also, to be clear, i worked out how to operate the firmware-provided interfaces, not the underlying engines themselves
20:10 imirkin: mlankhorst: did VP4 on fermi+
20:10 imirkin: er, without the : :)
20:10 imirkin: i stole that work and hooked it up on tesla for the VP4- and VP3-using ones
20:10 karolherbst: I see
20:11 karolherbst: I am not quite sure if I really want to buy a maxwell2 for my next system, but it will most likely look like that :O
20:11 karolherbst: no idea yet if I want to have that fun to RE VP6/VP7
20:11 imirkin: well, if you want to hack on nouveau, that's all well and good. if you want to get actual work done, get an amd gpu
20:12 karolherbst: nahm maybe I will have two gpus then
20:12 karolherbst: in the desktop
20:12 karolherbst: and use nvidia for hacking and amd for actualy desktop usage
20:12 imirkin: :)
20:12 karolherbst: i kind of like that hybrdig gpu thing
20:12 karolherbst: chances are low that you actually mess up your desktop :D
20:12 imirkin: definitely convenient for various hackery
20:12 karolherbst: yep
20:12 imirkin: and you can load/unload nouveau kernel module at will
20:12 imirkin: it's def the way to go
20:13 karolherbst: :)
20:13 karolherbst: its normal for me
20:13 karolherbst: only downside is that I can't turn off the gpu
20:13 karolherbst: makes it a little harder to switch to nvidia
20:13 karolherbst: well, for what is pcie hotpluggable :D
20:14 Exagone313: Do you need people having VP6+? Not that I want to break my gpu, but if I could help I would like to
20:14 karolherbst: sure, anybody willing to help out is welcomed
20:14 imirkin: Exagone313: need someone to do the RE for VP6+
20:14 karolherbst: but before that, imirkin can tell you how long it took for him to RE VP2 :D
20:14 imirkin: my experience suggests this can only be done by someone with direct physical access to such a GPU
20:15 imirkin: mmmm... like 3 months. and i spent a lot of time on it - a lot more than just evenings + weekends.
20:15 karolherbst: :)
20:15 imirkin: of course i was learning how nvidia hw worked at the same time, which was very confusing
20:15 karolherbst: REing NVENC would also be a grand thing
20:15 Exagone313: I have a GTX 960 and a GTX 760, but I don't use the GTX 760. I moved from Windows after came back on it.
20:15 imirkin: as there was no (and still is no) documentation about it that's accessible to beginners
20:16 karolherbst: Exagone313: I really suggest you to use the 760 with nouveau
20:16 karolherbst: more perf
20:16 karolherbst: and more stable
20:16 karolherbst: and everything better supported
20:16 Exagone313: Yes, I could now. When I was still using Windows I didn't want to
20:16 karolherbst: right, for obvious reasons
20:17 Exagone313: because dual booting and changing hardware would be such a pain
20:17 karolherbst: mhh, right
20:17 karolherbst: I have some patches to get really good and stable perf with kepler gpus
20:17 karolherbst: and usually we are at 60-80% perf compared to nvidia
20:18 imirkin: just to be clear - nouveau is alpha quality software... at best.
20:19 Calinou: >critisizes their own software
20:20 imirkin: it's not a criticism... statement of fact
20:20 karolherbst: that's imirkin for you
20:20 imirkin: karolherbst: btw, how hard is it for you to make a mmt trace with vdpau?
20:20 karolherbst: whenever he has a chance, he says how crappy nouveau and how good amd is ;)
20:20 karolherbst: imirkin: well, no clue, I once did one I think?
20:20 karolherbst: why?
20:21 Exagone313: Just, if I use the GTX 760, if I can't play LoL, I switch back to 960 :P
20:21 karolherbst: with the 960 it will be worse, just saying
20:21 Exagone313: It works with modesetting
20:21 imirkin: well, orbea sent me a sample vdpau file that gets messed up when decoding very early on... i figured maybe a trace would prove instructive
20:21 karolherbst: mhh right
20:21 imirkin: Exagone313: and how do you think modesetting works?
20:21 imirkin: "magic"?
20:22 Exagone313: I have no idea. I'm not experienced in drivers
20:22 Exagone313: A developper wouldn't call it magic.
20:22 karolherbst: if you want the best nouveau experience possible, you kind of need to use a kepler card
20:22 imirkin: instead of using the simple and well-tested nouveau ddx, it runs a GL implementation of the X accel API on top of the GL driver
20:22 karolherbst: tesla is also well supported, but old, fermi too, but there you have the perf problem again
20:23 imirkin: you don't really have a choice with maxwell+ (for now... i might get one in the next few days to play with)
20:23 imirkin: but in either case, whether a particular game works or not will generally not be based on your DDX choice
20:24 karolherbst: I always feel bad to say to users they should compile ther own nouveau module :(
20:24 Exagone313: If I'm motivated, I'll try it during the week.
20:24 imirkin: karolherbst: it's easier and more straightforward to tell them to go get an AMD gpu :)
20:24 karolherbst: there is no fun in doing that though
20:24 Exagone313: I compiled nouveau and mesa (just that I switched back to the mesa version of my distro, arch)
20:25 Exagone313: because it was updated
20:25 karolherbst: Exagone313: uhhh, you are not using toms package by any chance?
20:25 Exagone313: My CPU is good enough
20:25 Exagone313: karolherbst: for?
20:25 karolherbst: compiling nouveau
20:25 Exagone313: No, I used the git
20:25 karolherbst: ohh wait
20:26 karolherbst: if you use your 760, you should use that package: https://aur.archlinux.org/packages/nouveau-kepler/
20:26 Exagone313: it's not up-to-date right now, I'll have to do it
20:26 Exagone313: ok
20:26 karolherbst: it contains all the stuff I done to improve the reclocking situation
20:26 karolherbst: and then you can crank up the perf level through the pstate file
20:26 Exagone313: Do you have an uninstall part in your Makefile?
20:26 karolherbst: and yes, we are working on automatic stuff
20:27 Exagone313: Because manually removing files to install packages is a pain
20:27 karolherbst: well, you can't really reliable remove kernel modules
20:27 imirkin: Exagone313: it reuses the kernel build system.
20:27 Tom^: karolherbst: isnt rm reliable?
20:27 Tom^: karolherbst: :p
20:29 karolherbst: Tom^: if you would know the paths, yes
20:30 Exagone313: I think https://aur.archlinux.org/packages/nouveau-kepler/ won't work
20:31 Exagone313: oops nvm
20:36 Exagone313: Something I'm not sure, is nouveau included in Mesa (apart the DDX)? So what this package install? A bit confused
20:36 imirkin: nouveau isn't a single thing
20:36 imirkin: it's a collection of things
20:36 imirkin: kernel, libdrm, xf86-video-nouveau, and mesa
20:37 Exagone313: lol, I think I don't have everything
20:37 Exagone313: That would explain why nouveau didn't work on the 760 (it's plugged on the second slot)
20:57 mupuf: imirkin: ah, right!
20:59 Exagone313: So currently I have the video firmware from nvidia, mesa 12.0.1 (from arch repo), xf86-video-nouveau from this commit https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=1da8a937be19e41c51a3d516bd98cee988bca44b (Jun 2). What the aur package you pointed me installs?
21:03 karolherbst: mupuf: do you know anything about how clockg ating might work on tesla?
21:04 mupuf: karolherbst: it is sort of the same
21:04 mupuf: except the enable bits for clock gating are in PMC, IIRC
21:04 mupuf: in PMASTER
21:04 karolherbst: how are they called?
21:04 Exagone313: I think I know, the kernel module.
21:04 Exagone313: (for my question)
21:04 mupuf: karolherbst: maybe I did not find the time to rename them
21:04 mupuf: they may be called JOE
21:05 karolherbst: https://gist.github.com/karolherbst/41774e777feec04feaac81914b4b690e
21:05 karolherbst: those? :D
21:05 karolherbst: unlikely I would say
21:06 karolherbst: mupuf: uhh cool, I have two temp sensors on my tesla gpu, one on the gpu, one from apple smc
21:06 karolherbst: the apple one is a bit more accurate
21:07 karolherbst: 0.2°C resolution
21:07 mupuf: karolherbst: well, yes, but there are more of them
21:07 mupuf: clock gating is hard to test without a power meter
21:07 karolherbst: I know
21:07 mupuf: which is why I did not work on it much
21:07 karolherbst: but my gpu is fanless
21:07 mupuf: there is this bug report also about nv86 running too hot
21:07 karolherbst: so the temperature difference should be enough
21:07 karolherbst: maybe
21:07 mupuf: there is a ton of stuff there about tesla
21:08 mupuf: but dude, forget about tesla
21:08 mupuf: it is a clusterfuck
21:08 karolherbst: my tesla idles at 76°C, just saying
21:08 mupuf: and kepler is the goal now
21:08 orbea: I upgraded from mesa-2016.08.17_59bb821 to mesa-2016.09.04_98f734e and found that the gl ribbon in the Retroarch menu displays incorrectly now. Any ideas? Before: http://ks392457.kimsufi.com/orbea/stuff/pics/scrots/libretro/2016-09-04-140159_1680x1050_scrot.png after: http://ks392457.kimsufi.com/orbea/stuff/pics/scrots/libretro/2016-09-04-140105_1680x1050_scrot.png apitrace:
21:08 orbea: http://ks392457.kimsufi.com/orbea/stuff/trace/retroarch.trace.xz
21:08 mupuf: kepler, fermi to some extent :)
21:08 karolherbst: mupuf: sure, I am just wondering, because I planed to use my mini as a server, but I really don't like a 76°C hot gpu inside it
21:08 karolherbst: :D
21:09 karolherbst: well 73°C on 03 pstate
21:11 mupuf: I see, then power gating would be more beneficial
21:12 karolherbst: yeah
21:12 karolherbst: but also more complicated
21:12 mupuf: yes
21:12 karolherbst: most likely
21:12 mupuf: well, there is one easy fix already. find the bug I linked you to
21:12 karolherbst: I just hoped to get good results fast
21:12 karolherbst: uhh
21:12 mupuf: there, you will find a reg that controls clock gating of engines
21:12 mupuf: 2 bits per engine
21:12 mupuf: 3 == auto IIRC
21:12 karolherbst: any idea how the bug was called?
21:13 mupuf: keywords: nv86 hot
21:13 karolherbst: mhh
21:14 karolherbst: https://bugs.freedesktop.org/show_bug.cgi?id=71455 ?
21:14 karolherbst: this one?
21:14 karolherbst: even those that is a nv4x one
21:15 karolherbst: ohh wait, that's something else
21:15 karolherbst: https://bugs.freedesktop.org/show_bug.cgi?id=37922
21:15 karolherbst: this sounds more like it
21:16 mupuf: karolherbst: last one, yes
21:17 mupuf: the PMC enable write is really important because it contains the master enable switch IIRC
21:17 karolherbst: I try the one comment with the reg writes
21:17 karolherbst: mhh
21:17 karolherbst: the pmc enable all didn't enable anything in addition
21:17 karolherbst: though
21:19 mupuf: 1588 is the magic reg
21:19 karolherbst: yeah I figured
21:19 karolherbst: it is set to 0 for me
21:19 mupuf: well, now, read the doc from rnndb
21:20 karolherbst: seems to be nothing, but I check the xml
21:20 karolherbst: ohh, the documented one is "<reg32 offset="0x588" name="CLOCK_GATING_2" variants="NV17:NV20 NV25:GF100">"
21:20 karolherbst: no idea why it doesn't pick it up for -a ac
21:21 karolherbst: lookup -aac 1588 ffffffff:
21:21 karolherbst: PBUS.CLOCK_GATING_2 => { PGRAPH = 0x3 | PPPP = 0x3 | 0xffffffcc }
21:24 imirkin: orbea: repro'd
21:24 karolherbst: mupuf: ohh oaky, I am stupid :D nvm me
21:25 imirkin: nouveau 0000:02:00.0: gr: GPC0/TPC1/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 7000d [GPR_OUT_OF_BOUNDS]
21:25 imirkin: *probably* related
21:27 karolherbst: mupuf: okay, poking 3 into that reg really messes up the machine...
21:28 mupuf: 3 == force off?
21:28 mupuf: I forgot
21:28 karolherbst: ssh is slow as hell now
21:28 karolherbst: and glxgears worked without issues with 0-2
21:29 mupuf: then 3 == force off :D
21:29 karolherbst: :O
21:29 mupuf: :D
21:29 karolherbst: reading helps
21:29 karolherbst: "Both need to be set in order to disable the engine."
21:29 mupuf: read the doc before bashing registers, you crazy!
21:29 karolherbst: :D
21:29 karolherbst: huh
21:29 karolherbst: I expect dislaimers from nvapoke before doing anything dangerous you know!
21:29 karolherbst: like any sane software would do!
21:30 orbea: imirkin: you think its something nouveau or more mesa?
21:30 imirkin: orbea: definitely nouveau
21:31 imirkin: i think it's hakzsam's recent program reupload work
21:31 imirkin: checking now
21:31 orbea: ah, thanks :)
21:32 mupuf: karolherbst: hehe
21:33 imirkin: hah, nope
21:33 karolherbst: :O
21:33 karolherbst: mupuf: I managed to kill glxgears, but I have X running at 200% cpu
21:34 karolherbst: am I happy to have a realtime kernel etup on that machine
22:03 karolherbst: imirkin: I am wondering now, the pass should be able to break similiar thinks on tesla ... I doubt I did something terrible wrong in my swap source patch
22:04 karolherbst: I am wondering why it didn't happen before
22:04 karolherbst: maybe just luck within RA doing something which that pass won't break?
22:06 imirkin: sorry, not sure what you're talking about =/
22:06 karolherbst: that post ra constant folding
22:07 imirkin: nv50 has a ton more restrictions
22:07 karolherbst: that " 23: mad u32 $r6 u16 $r3h $r1l $r6 (4)" -> " 23: mad u32 $r6 u16 $r1l 0x0003 $r6 (8)" thing
22:07 karolherbst: because if the former thing would came out of RA with the source swapped already
22:08 karolherbst: the current pass should also do the opt
22:08 karolherbst: and messing it up
22:08 imirkin: don't know that it will
22:08 imirkin: coz of the isFloatType thing
22:08 imirkin: which this won't be
22:08 imirkin: so it'll go down the other path
22:08 imirkin: which handles this junk properly
22:09 karolherbst: mhh I see
22:09 imirkin: if (i->getSrc(1)->reg.data.id & 1)
22:09 imirkin: val.reg.data.u32 >>= 16;
22:09 karolherbst: ahh okay
22:09 karolherbst: I think I understand now
22:11 imirkin: that's why this pass isn't directly appropriate for non-nv50
22:11 imirkin: so you can't just flip it on for fermi+
22:13 karolherbst: okay, so would you suggest to write a new one for fermi+ or still try to make one for both?
22:14 imirkin: i haven't thought about it
22:14 imirkin: or if i have, i've long forgotten
22:22 karolherbst: I see, well maybe I will understand all that at some point to make no mistake implementing it
22:22 karolherbst: I think fermi+ even supports bigger values than 0xffff
22:23 imirkin: orbea: ok, i have a fix... give me a min to push
22:23 imirkin: [want to double-check it on top of master]
22:27 karolherbst: imirkin: I think I will write a nvc0 version, because it indeed seems quite different, and there is also some limm thing going on as well
22:27 karolherbst: I think we can even immediate if src2 != dst, but much smaller values
22:32 imirkin: orbea: pushed. https://cgit.freedesktop.org/mesa/mesa/commit/?id=61e978524a0e5de4f8570b44bcb9b907a9187684
22:32 imirkin: karolherbst: that sounds right.
22:32 imirkin: karolherbst: note that the emit code likely doesn't handle all this properly
22:35 imirkin: orbea: fwiw it was only an issue on GK110/GK208 gpu's (due to the SM35 ISA)
22:37 orbea: imirkin: thanks, compiling now
22:52 orbea: its fixed here too, thanks!
22:52 imirkin: coolio