08:51karolherbst: imirkin: what about the min/max commit?
08:51karolherbst: ohh, should read mails first :D
09:53kloofy: it's a bit scary about how many bugs are you notating here, and how few people try to solve/fix those bugs
09:55kloofy: makes me wanna wonder, if i have offered help, why are you refusing had you been refusing of additional workforce, but guess it leads to my id problems a need to sabbotaga whatever i do
10:02mupuf: karolherbst: I do not think you will manage to do a comparaison between nouveau and nvidia for sched codes
10:02karolherbst: mupuf: why not?
10:02karolherbst: mupuf: I was talking about compiled binaries extracted from mmts
10:02mupuf: how about this instead: dumping into files all the generated shaders by nvidia and then ordering them by sched code
10:03mupuf: that will give you all the most likely conditions
10:03karolherbst: then we forget about branching
10:03mupuf: why would we?
10:04mupuf: oh wait, I got it, you mean writing an OoT sched code generator and comparing your output with nvidsia
10:04mupuf: that actually is a sweet idea
10:05mupuf: you can't just pipe the code through nouveau's compiler and expect it to compute the same sched code, that was my point :)
10:05karolherbst: I just wanted to reused the sched generating code
10:05karolherbst: but maybe this would be too messy to actually do
10:05mupuf: Very probably :D
10:06mupuf: is the code complex already?
10:06karolherbst: we also have envydis which should help here
10:06karolherbst: the main problem would be to translate the file into nv50 ir
10:06karolherbst: we have no idea what actually matters
10:06mupuf: oh well, you should RE the shit out of it first, and not try to make real code
10:06karolherbst: maybe some mods also change the sched opcodes
10:07mupuf: right, the code assumes nv50 IR, so that would likely be a lot of work
10:07mupuf: just ignore the nouveau compiler and start from scratch
10:07karolherbst: mupuf: well my idea was this: parse the generated binaries and push it through some sched opcode generating algorithm
10:07mupuf: .... well .... actually ... you still need to parse the bloody demmio output
10:07karolherbst: and see how much we differ with nvidia
10:07karolherbst: mupuf: you mean demmt, right?
10:07mupuf: yes, sorry
10:08karolherbst: we have envydis for this
10:08karolherbst: but mhh
10:08mupuf: but it is not an IR
10:08karolherbst: I still think it is a bit of work
10:08karolherbst: doesn't matter
10:08karolherbst: I don't need a real IR
10:08karolherbst: what I need is where an instruction gets executed
10:08karolherbst: not what the instruction really does
10:08karolherbst: and a bit of source handling
10:09mupuf: what you need is all the information possible
10:09karolherbst: like sf
10:09karolherbst: mhh, right
10:09mupuf: there are many instructions, you need to know the registers, the type of operation, etc..
10:09karolherbst: but I menat for using the current algorithm
10:10karolherbst: those opclasses in nv50ir doesn't map 1to1 to the actual part used to executed those instructions
10:10karolherbst: I think unit is the right word for this?
10:10mupuf: no idea what you are talking about :s
10:11karolherbst: I mean the instruction execution units
10:11karolherbst: like the fpu on a cpu
10:11karolherbst: this is really important to know for tesla (and maybe fermi as well, less on kepler)
10:11RSpliet: yes, unit is correct, floating point unit, arithmetic logic unit...
10:13mupuf: karolherbst: are you sure it is as simple as just knowing the unit?
10:13mupuf: there are no dependencies for registers?
10:13karolherbst: mupuf: no, but it is a part of it
10:13mupuf: like RAW or WAR
10:13karolherbst: mupuf: gt200+ is weird here a little
10:13karolherbst: mad can be executed on two different units
10:13karolherbst: and then the type also matters
10:14RSpliet: karolherbst: keep in mind, iirc, kepler has 6 FPUs for 4 concurrent warps
10:14RSpliet: which is weird, but... double check those kind of details as well ;-)
10:15mupuf: ah ah, sounds like there will be a lot of fun here :D
10:15karolherbst: mupuf: yes
10:15karolherbst: mupuf: The individual streaming processing cores
10:15karolherbst: of GeForce GTX 200 GPUs can now perform near full-speed dual-issue of multiply-add operations (MADs) and MULs (3 flops/SP) by using the SP’s MAD unit to perform a MUL and ADD per clock, and using the SFU to perform another MUL in the same clock
10:16karolherbst: from nvidia ocs
10:16karolherbst: but hey, the sfu can be busy doing sin stuff or something
11:11kloofy: mupuf: just couple of sentences, i posted yeah two of the solutions one for fermi kepler and one for maxwell how to plumb the correct sched codes into gallium , they were two links opennvidia and max-as
11:11kloofy: i really am in difficulties to understand the terminlogu you use, but just look at those projects to handle the codes
11:17kloofy: and remember my notes, this is the battle that is easily winnable only if you want to do it, and i offered two ways to do the scheduling, but i am getting onto your nerves again, so i have enough things to do to keep me occupied and quiet here now
13:37karolherbst: mupuf: anything comes to your mind which would help with reducing power consumption except clock/power gating?
13:38kdvr: hi, i have gone through multiple documents / troubleshooting etc but I can't find anything that could help me yet. Whenever I disconnect my monitor or switch (through hdmi switch) I lose my mouse cursor and chrome for instance does not show anything anymore, the only way to resolve is by logging out and logging back in.
13:39karolherbst: kdvr: did you try to restart your window manager/compositor?
13:40kdvr: I am running xfce, is there an easy way to restart without loosing the current open apps?
13:40karolherbst: xfwm4 --replace
13:40kdvr: I can try now
13:42kdvr_: nope that did not work... Mouse is gone and I can't seem to type anything anymore in chrome (which I am using for freenode)
13:42kdvr_: just logged out and logged back in
13:43karolherbst: but does anything changes at all?
13:43kdvr_: no, it just flickers and that is it
13:43karolherbst: what are your kernel/X versions?
13:45kdvr_: kernel: 4.7.2-201.fc24.x86_64
13:46kdvr_: let me see how I can get the X version on fedora
13:47karolherbst: and maybe it also helps if you tell us what gpu you have
13:48kdvr_: NVIDIA Corporation GM206 [GeForce GTX 960]
13:49kdvr_: sorry I am not that fast hold on :P
13:51kdvr_: I am running X.Org X Server 1.18.4
13:52kdvr_: All on Fedora 24
13:52kdvr_: I can provide any log needed :P just have to tell me hahaha, I am a n00b in debugging
13:53karolherbst: maybe dmesg or the x log tell us something
13:54kdvr_: alright, thanks btw for your time
13:55kdvr_: Dmesg: http://pastebin.com/93aKEV8H
13:56kdvr_: And the Xorg.0.log: http://pastebin.com/zrWe3kSt
14:00karolherbst: mhh the .old x log please
14:02kdvr_: Here you go Xorg.0.log.old http://pastebin.com/7wMGztLJ
14:03kdvr_: It all looks chinese to me :P
14:04kdvr_: I was hoping for errors when I would disconnect or reconnect
14:05karolherbst: me too
14:07kdvr_: Is there a way to get more verbose information for you?
14:50mupuf: karolherbst: DVFS, clock gating, power gating are the typical techniques
14:51mupuf: keeping the gpu cool also helps
14:51mupuf: but you need to factor in the cost of the fan
14:51mupuf: after this ... improve performance to reduce power usage (when vsync is on)
14:51karolherbst: right, but I meant stuff besides that
14:53mupuf: so yeah, that's it
14:53mupuf: after this, it really is tuning the DVFS algorithms
14:54mupuf: try to keep the clocks as low as possible while still not impacting the performance of dynamic workload
14:55karolherbst: okay, I ust hoped there would be something left to do, but I guess reing power gating will be quite a thing
14:56karolherbst: but even clock gating already helps a lot, even reducing power consumption under some workloads
14:56karolherbst: I just asked cause I try to finish collecting all information I want to add to my talk, maybe I just forgot something
14:57mupuf: sure sure
14:57mupuf: well, clock gating is still left for REing and will be tough
14:57mupuf: but bashing all the regs should help already
14:57karolherbst: it is enough for kepler+
14:57karolherbst: nvidia seldom touches them
14:57mupuf: nope, does not work on my e6
14:57karolherbst: like I only saw it after suspend
14:58karolherbst: mupuf: are you sure?
14:58mupuf: yes, I am
14:58karolherbst: what gpus are in reator currently?
14:58mupuf: I tried for a long time to make them work
14:58karolherbst: maybe I would take a look at some point
14:58mupuf: not sure
14:58mupuf: it is off right now
14:58karolherbst: I will check
14:58karolherbst: not anymore :D
14:59mupuf: ok, have fun! I am with pmoreau in Utrecht, Roy's city of origin
14:59mupuf: we are abut to go for a walk
14:59karolherbst: gk106 :)
14:59mupuf: ok, great!
14:59karolherbst: I am sure it will work :p
14:59mupuf: try, I did not see any drop in power usage when enabling
14:59mupuf: well, if it does, /me is happy
14:59karolherbst: uhh, it booted into the blob again
15:00mupuf: fuck, no idea what people did, but they really screwed up grub
15:00mupuf: grub-reboot's state should always be resette
15:00mupuf: or someone changed grub's conf
15:00mupuf: hakzsam: ?
15:00karolherbst: well, it sometimes happens
15:01karolherbst: what is the linux grub entry? 0 or 1?
15:01mupuf: try either one or the other :p
15:02mupuf: both are linux though :D
15:02mupuf: 0 is what I remmeber
15:02karolherbst: right :D
15:02karolherbst: grub from the nvidia partition does something bad I assume?
15:03mupuf: well, it is not the same boot partition
15:03mupuf: ah, it booted on nouveau now
15:03karolherbst: sure, but to repair that I always chroot into the nouveau partition and run grub-reboot 0 there
15:04karolherbst: and this leads me to the nouveau partitioan on reboot
15:04karolherbst: no idea if chroot is required here
15:04mupuf: normally, you just need to reboot once and it always go back to nouveau
15:05karolherbst: regarding power consumption: on lowest clocks the effect is rather slim
15:06karolherbst: k, it works
15:06karolherbst: but well
15:06karolherbst: the difference...
15:06karolherbst: on 0f max boost
15:06karolherbst: 43.77 W -> 40.60W
15:07mupuf: ok, I guess I did not see any difference because I did reclock the gpu
15:07karolherbst: on 07
15:07karolherbst: 18.9W -> 18.4W
15:07karolherbst: maybe you thought the 0.5W are usual noise or something
15:07mupuf: well, the effect is supposed to be much larger
15:07karolherbst: due to power sensors configured like shit
15:07karolherbst: on kepler not so much
15:07karolherbst: on maxwell, yes
15:07mupuf: yeah, right, the sensor output used to be super noisy
15:07karolherbst: on maxwell I get 30% drops on 0f
15:08mupuf: ok, great
15:08hakzsam: /root/reset_grub.sh works fine
15:08hakzsam: on blob partition
15:08mupuf: hakzsam: oh, right!
15:08hakzsam: and grub-reboot 2 from the nouveua one
15:08mupuf: I had forgotten about this script
15:08karolherbst: mupuf: even for some workloads at full load I got 10% drops on maxwell
15:09karolherbst: glxgears .D
15:09mupuf: on tesla, I could get something similar when enabling clock gating
15:09mupuf: err, clock throttling on idle
15:09karolherbst: I see
15:10karolherbst: I guess it is safe to implement it on nouveau then, because it kind of works on every kepler and maxwell gpu
15:11mupuf: well, let's see!
15:11karolherbst: mupuf: but we should also RE those bits to globally disable clock gating, just in case there are some gpus where it is indeed disabled
15:11mupuf: want to write the patch?
15:12mupuf: right, we'll need to find them
15:12karolherbst: well, I planned to work on that with gnurou a bit or he do it or somebody else
15:12mupuf: we can use ezbench to try an A/B with clock gating enabled or not
15:12karolherbst: I really don't feel ike implementing it, because there are more complex/difficult things to do
15:12mupuf: we'll see the impact on perf and power :)
15:12karolherbst: and any new dev could implement it instead
15:12karolherbst: mupuf: no impact afaik
15:12mupuf: ah, right, new comer
15:13mupuf: karolherbst: and you base this data on what?
15:13karolherbst: would be a good task to get used to the code base
15:13mupuf:requires runs of every games and benchmarks possible :p
15:13karolherbst: mupuf: well, nothing :p I just have it enabled since always
15:13mupuf: and since you never take it off, you don't see any perf impact
15:13karolherbst: well I sometimes checked and it didn't make any difference
15:13mupuf: so, the only way of testing is to do an A/B comparaison
15:13karolherbst: also nvidia doesn't touch those regs again
15:14mupuf: sure sure, but still ;)
15:14karolherbst: I know
15:14karolherbst: but I assume there is no difference really, maybe in workloads with really spiky loads
15:14karolherbst: and with spiky I mean several spikes within milliseconds
15:15karolherbst: afaik it might happen that the clock signals gets disconnected with vsync a lot
15:15karolherbst: but if we vsync we don't need more perf anyway
15:16karolherbst: and I would assume that's the biggest tradeoff, that you have a slim lattency on starting things
15:16kdvr: karolherbst: sorry to be a bother :P but do you think I can enable more verbose logging for my monitor disconnecting /reconnecting issue?
15:16karolherbst: kdvr: no idea if that helps, I am no expert in that X stuff
15:16karolherbst: I kind of hoped somebody else would have any ideas
15:16kdvr: ok cool :-) me too
15:16karolherbst: mupuf: but I think we need some reference counting ok within the kernel for the engines
15:17mupuf: what for?
15:17karolherbst: or at least I fear we need that for fermi
15:17karolherbst: clock gating
15:17karolherbst: we could also do manual clock gating on kepler as well
15:18karolherbst: mhh reference counting is the wrong term here
15:18karolherbst: more like usage counting
15:18karolherbst: and if an engine isn't in used anymore, we could clock/power gate it
15:18karolherbst: if automatic gating doesn't work
15:51mupuf: karolherbst: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=22b6c9e8fef4553017a92ed5e27451e0b2f9c5ce <-- this is definitely something we need to do
15:51mupuf: karolherbst: right, this is only for power gating
15:51mupuf: and yes, we will need to monitor the command buffer
15:52mupuf: or a bind to an engine
15:52karolherbst: mupuf: yes, but this is for maxwell I think
15:52mupuf: will fix stability issues
15:53karolherbst: on maxwell I assume
15:53karolherbst: I think on kepler the voltages are usually higher as they have to be in the vbios
15:53karolherbst: or the other way around: on maxwell vbios the voltage is more tight to the actualy requiernment
15:55karolherbst: mupuf: in the future we should just nack changes from gnurou if they also affect desktop gpus, just so that he actually have to implement it for all chips :p I already told him I will nack any tegra only clock gating patches
15:55karolherbst: well, but I think we can always merge the code together at some point
15:55karolherbst: just a waste of time really
15:56mupuf: yeah, I get your point, but I would say no
15:56mupuf: let him do the work for tegra and let us mimic it for the rest
15:57mupuf: and ask questions
15:57mupuf: otherwise, he may just not have the time to do anything
15:57karolherbst: yeah, I wouldn't want to be so strict about it too, because of other problems which might come up
15:57karolherbst: but I would at least try to convince him to start with more general solutions first
16:52karolherbst: mupuf: :O I just saw that a gm204 has a max voltage of 1.27V
16:53karolherbst: seems normal for those gpus
17:29kloofy: i have disorders my own from 2005 when things all collapsed for me, after getting over decade of conspiracy, my consentration travels around so bad, kinda troublesome to do stuff still , and pack things inside my brain not leaving enough of those chanches for people to crack me up even further
17:30kloofy: sort of can't resist at all it's dead easy to distract me with a nasty atitude those days
17:36karolherbst: does anybody know of any nouveau kernel documentation we have?
17:38imirkin: there is none.
17:38kloofy: so for those firmware dudes, there is a method to clock circuits up even more intelligently on programmable devices, i know karolhebst knows how it's done, but normally pll generates the signal which can be multiplied and yet additionally phase shifted normally on mid-level devices in hw for 6-8 shifts
17:38imirkin: skeggsb has various promised to write some
17:39imirkin: but afaik that's all theoretical
17:39kloofy: and it's done by using so called multiple clock signals
17:39karolherbst: I see
17:39imirkin: at one point i wrote something, but i (a) lost it and (b) it'd be very outdated by now, as it was about 3 nouveau rewrites ago
17:39kloofy: i.e multi clock domains
17:39karolherbst: imirkin: k
17:39imirkin: do you have concrete questions?
17:39imirkin: or just want something to read?
17:39karolherbst: neither :D
17:41imirkin: trouble sleeping and want something less addictive than sleeping pills? :)
17:41imirkin: if so, i can also recommend any text on general relativity.
17:41karolherbst: nah, I know better things to do when I can't sleep
17:41kloofy: so for the asics that specific information isn't that relevant, for designers in competition that can be replicated or forumated doing things from scratch
17:47kloofy: as of generating the clock signals and timing is largely guided also by tools who help with their feedback to plant things right, the fairly crucial part happens somewhere in the kernel for cpu designs, and that part is how to schedule instructions in the firmware
17:47kloofy: and in the kernel the stream to start with
17:49kloofy: the static scheduling tdm time derived stuff, i haven't myself fully understood, how it works, but i am non the less going with dynamic scheduling my own anyways
17:53kloofy: dynamic scheduling is a version where input output ports are sort of pollable and when they are not in busy/occuipied states, the stream is scheduled for those units
17:54kloofy: but static version is kinda something that compiler calculated the latency and they name it some distance, and probably they play with injection rates accordingly
17:56kloofy: as said, i am working on understanding it better but, at the moment there are things which i do not fully understand in the static scheduling version, and it's quite probably that i won't use this so called more area effecient and cheaper method, cause i can get the dynamic one very cheap too
17:59kloofy: as for the gpu's the scheduling is driver managed and improving it is lot simpler also for gpu rom for programming devices that would function the same, but doing that for the cpu is largely probably more complex, i am also doing the proper cpu firmware
17:59kloofy: cause i tend to think that good price and mid-level hw cpu cores would end up being too slow
18:06kloofy: i have all the proper verilog and tool based methods to make a very fast circuit for single core with several warps doing the alus and also to partition the cores for multicore options
18:06kloofy: but generally i have not studied on cpu's extensively yet how that in kernel scheduler works
18:09kloofy: but overall if things go well i'd after this work first distrubute scrambled netlists and later open up the platform to be open source if i managed to earn a little money
18:10kloofy: if vendors manage to keep the programmable hw cheap, we have a lot of computational power to play with
18:12kloofy: haven't yet found from here persons to collaborate with, i know imirkin based of the times when he yet communicated with me which was some old times
18:12kloofy: that he has such programmable experience on those devices
18:14kloofy: though overall my stamements are we do not have situations that hw does not provide chanches for the interested programmers or that there is information missing on the net how to fab and program different chips
18:17kloofy: back those days programmers captilized things on very crappy hw, brilliant minds forming different corporations, today it's as hw production has been boosted so eneormously it's easier to do software heroics and find the satisfaction cause of using really fluently running hw probably
18:17kloofy: which is also desgined to be power effecient, very small and powerful etc.
18:20kloofy: i am one of those who likes small devices due to the life style and stuff happening around me, i was at times very unpeasently dissapointed that the strategy to produce software or choose the correct hw to make it happen was not going anywhere
18:22kloofy: i concur with ajax there that it was enough of dissapointement to deal with first atom processors who filled that area, which were so weak that they barely were capable to function for web browsing sake
18:23kloofy: and the strategy was just the sales, that non expert persons likely think that it's 21st century and do that mistake of buying that hw until one gets more educated and knows that is crap
18:29kloofy: *this is, so yeah i take that opportunity and try to design powerful mobile chips, i am willing to collaborate, but have not yet met a person who has interest here
18:34kloofy: i think it's mature time in electronics when amiguous plans can be taken on without too much risk being involved
18:37kloofy: i.e i think about very ambiguous plans and it's questionable wether i have such ambitions i've yeah described it's the way i build my thoughts, rather then step by step with smaller missions to just tolerate the stress better, i.e it's a dilemma but i am using the first strategy
18:42kloofy: though that strategy yeah is mostly referring to a sickness which also is the case with me, i before falling ill badly would had chosen the little step my step progressing and not building too many dreams, i mean just as linuses opinion about it was
18:44kloofy: imo it just depends how much stress human has, if i naturally i am stressed out and in a need to tolerate it anyways in greater extend than it does not make a difference to take on large projects which are stressfull for implementing too
18:49kloofy: so i am off, it seems i normally scare people away with this, most people do not want to take any stress on, where as my past experienace and opinion nowdays it's just stress has to be tolerated
19:04kloofy: as all know body parts are in connection to work together and sometimes depenndant on really small and at first missable details, most of time even if person looks very talented outside, one does not get along with small detail that does not function as it should be which was inherited
19:04kloofy: that causes the heart and stuff to unexpeditely fibritillate and human freaks out in times when one has to perform on harder things
19:05kloofy: and usually unfortunently the fightback is projecting all the shit to normal persons, which is mad, cause they are unhappy what parts god gave them subcontiously
19:07kloofy: and it has to be regulated somehow that they can't punish innocent people in a way, but that is a dreamland cause there are more of those ill ones then the others
19:07kloofy: what helps is that when a country gets some sort of wealthier social status
19:11kloofy: it's very difficult for them who have things to loose cause of zombies projecting their faults to him daily basis, ones the conspiracy is opened up and groups formulated to coin them, it could be the life time suffering road
19:17kloofy: this is pointless situation, but that is how things go, people who suffered with getting the parts, make others who don't suffer in life a perfect balance, nasty and cruel view for the latter
19:19kloofy: in other words, it's not that sick person who suffers in life, but people around one normally take a majorly bigger hit
20:47karolherbst: imirkin: I think I will try to completly remove that OP_SUB thing, any reason this is a bad idea?
20:48imirkin: you're in for a lot of pain
20:48karolherbst: I am just asking if that's a goo idea :D
20:48karolherbst: not that I do that and then later on it should stay
20:48imirkin: static const uint32_t commutative[(OP_LAST + 31) / 32] =
20:48imirkin: // ADD,MAD,MUL,AND,OR,XOR,MAX,MIN
20:48imirkin: 0x0670ca00, 0x0000003f, 0x00000000, 0x00000000
20:48imirkin: see that bitmask?
20:48imirkin: you're gonna have to adjust it.
20:48imirkin: same for the nvc0 versions
20:48karolherbst: why do you do stuff like that? :D
20:48imirkin: so ... like i said, just leave the OP_SUB in
20:49imirkin: i dunno. "it was like that when i got there"
20:49imirkin: [my excuse for just about everything]
20:49karolherbst: I see
20:50karolherbst: k, then I just whipe out every occuranty of that and add a nasty assert into instruction or something
20:50karolherbst: actually before starting new things, I should finish my old stuff first...
20:52karolherbst: I think I will finish up that postRAConstantFolding thing
20:52karolherbst: because this is quite usefull
20:53karolherbst: around -0.40% instruction count
20:53karolherbst: even gpr usage drops
21:23karolherbst: "Wait on fence 1 (ack = 1, next = 1) timed out !" I got this
21:23karolherbst: I think I never got this before running shader-db
21:24karolherbst: did anything change which could lead to this?
21:24imirkin: try reverting the patches he pushed recently.
21:25karolherbst: it happens in nvc0_screen_destroy
21:26imirkin:still blames hakzsam
21:29karolherbst: mupuf, skeggsb, gnurou: do you think we should add a subdev for power/clock gating? then nvkm_engines could call nvkm_cpgateing_* where appropiate and we can move all the loginc into that subdev
21:30karolherbst: or would you rather see it in common engine code?
21:32karolherbst: imirkin: I also see that my mem usage was pretty high recently, because the cache was whiped out....
21:33karolherbst: reverting his stuff seems to help
21:35karolherbst: imirkin: well, or not
21:35karolherbst: still happens
21:47mupuf: karolherbst: a subdev for bashing all regs?
21:47mupuf: imirkin: always blame the absents ;)
21:47mupuf: power gating should be a method of all engines
21:48karolherbst: yeah sure, but how would you implement it chip specific?
21:48mupuf: like any other subdev?
21:48karolherbst: mhh yes, that's why I thought it is a good idea to have an actual subdev for this
21:49karolherbst: which takes an enum in its functions
21:49mupuf: what you are asking us is to tell you what architecture is the right one when we obviously don't know yet
21:49karolherbst: to select the engine it gets applied to
21:49mupuf: what the heck? No
21:49mupuf: the subdev's job would be to just bash the values on init()
21:49mupuf: and resume()
21:49mupuf: that's it
21:49mupuf: nothing more, noitjing else
21:50mupuf: why do you want to expose everything?
21:50mupuf: we won't care about this
21:50mupuf: we just want to enable it and be done with it
21:51karolherbst: okay, so we should keep it simple for now until we know more and have to extend things?
21:51mupuf: the further away we are from nvidia, the worse it gets
21:51mupuf: but we won't have to, for sure ;)
21:51mupuf: AKA, if a platform is too complex --> Let's not care abput it
21:51karolherbst: well, how would you implement it then if we have to disable the clock gate for a specific engine on demand?
21:52karolherbst: allthough stuff like that can be added later to that subdev anyway if we need it
21:52mupuf: why would you want to do this?
21:52mupuf: nope, if you need to do this, you need to move it to the engine
21:53mupuf: AKA, new method
21:53mupuf: but remember, clock gating can also apply to other non-engine blocks
21:53mupuf: and they need to be covered
21:54mupuf: so instead of having to create one subdev per block, there would be the goto subdev for it
21:54karolherbst: that's why I was thinking to call stuff in their init functions to the new subdev
21:54mupuf: just make helper functions if you want
21:54mupuf: but seriously, you are overengineering the heck out of this thing
21:54mupuf: java, get out of this body!
21:54karolherbst: yeah, I tend to do that
21:55mupuf: it is good to understand concepts
21:55karolherbst: they also say that at work to me sometimes :O
21:55mupuf: but forcing a shit ton of them on your code makes it rigid
21:55mupuf: well, then it must be true ;)
21:55karolherbst: I know it is true :D
21:56karolherbst: still I think it is a good idea to create one new subdev for the entire power/clock gating logic
21:56karolherbst: and if we have to provide access to the functionality if really needed in certain cases
21:56karolherbst: it just looks like it on fermi
21:57karolherbst: it is a big mess, no idea why, but it looks like it
21:57mupuf: karolherbst: power gating is a no-no
21:57karolherbst: what do you mean?
21:57mupuf: clock gating, when it is just basjing values, then it is OK
21:58mupuf: otherwise, it HAS to be a method of the engine class
21:58mupuf: just like power gating
21:58karolherbst: and every engine would implement it then (
21:58karolherbst: + help of helper functions)?
21:58mupuf: yes, make helper functions if there is code that can be shared
21:59mupuf: but don't make a different subdev, it is against the idea of subdev anyway
21:59mupuf: the subdev is just there as a mean to avoid creating one subdev per clock-gated block
21:59mupuf: that's it
22:00karolherbst: what is the idea of a subdev anway?
22:02mupuf: represent a sub-device? :D
22:02mupuf: A block of hw that does not execute code (unlike enigne)
22:02mupuf: like gpio, ptherm, etc...
22:02karolherbst: yeah, that makes sense
22:03karolherbst: well, the clock gate bytes are in ptherm actually
22:03karolherbst: but do we want to put that thing in there?
22:03imirkin: an engine can be attached to a fifo
22:03mupuf: imirkin: that too
22:03imirkin: a subdev can't
22:04imirkin: in general a subdev is a logical piece of code that manages a group of registers
22:04mupuf: karolherbst: hmm, well, the helper function can be in the ptherm subdev
22:04imirkin: usually a whole range at a time
22:05mupuf: ok, going to bed guys
22:05mupuf: see you!
22:11karolherbst: but seriously, what is nvidia doing here: https://gist.githubusercontent.com/karolherbst/c6004d342552d1cf96165905ceac5e69/raw/cc560cec5b841e696ea317b3481a6f7093a663e0/gistfile1.txt
22:12imirkin: confusing you.
22:12imirkin: successfully, it seems.
22:12karolherbst: maybe we can simply ignore that and set the clockg ate to fermi to auto too
22:12karolherbst: and be done with it
22:13karolherbst: without causing any harm
22:13karolherbst: also nvidia does it only on the graph
22:13karolherbst: and only for some fermis
22:16karolherbst: I've added some context: https://gist.githubusercontent.com/karolherbst/3b3e7f03304dfeffc02db84a163b8ee1/raw/a49db20e78efe7abb7638de45958d24d9a8e52b1/gistfile1.txt
22:18karolherbst: is there simply some really odd devince initialization thing going on and nvidia indeed turns off/on those engines ?
22:21imirkin: karolherbst: i think it might suspend the engine somehow and then power it back up
22:21imirkin: there are various kernel module parameters you can pass in
22:21imirkin: which turn that off
22:23karolherbst: any reason why nvidia does that?
22:25imirkin: power saving
22:25karolherbst: then I highly assume we can just enable it once for fermi and be done with it
22:25karolherbst: and nvidia sets it to run just to disable that engine