01:36rhyskidd: would appreciate any comments on initial implementation of GP1xx new therm sensor: https://github.com/Echelon9/linux/commit/cd3a6b2ad13a85eff4595f62f4efcedf1c2b6fbe
01:36rhyskidd: envytools rnndb changes for the same here: https://github.com/Echelon9/envytools/commit/4675a94da5ea4a10acf03a4f409e2e3bbdbc3eba
02:38imirkin: rhyskidd: normally we just do the masks directly instead of bit shifts like + if (((packed_tsensor >> 29) & 0x3) == 0x2)
02:38imirkin: i.e. we'd do like if packed_tsensor & 0xc0000000 == 0x80000000
02:40mwk: rhyskidd: the rnndb part is invalid; you defined STATE as a single-bit bitfield, but it clearly has a value that doesn't fit
03:58rhyskidd: imirkin / mwk: thanks for the comments, will turn around a v2 of each
11:44mwk: skeggsb: do you know what a "PPC" is, by any chance? or what the acronym expands to?
11:48hakzsam: imirkin: nope, I don't remember the details, sorry
16:27mupuf: rhyskidd: shadow == overriden with nvafaketemp?
17:12karolherbst: rhyskidd: the 0x20460 regs are valid for earlier chipsets though
17:12karolherbst: rhyskidd: currently you make them gp100+ only, but that's simply not true
17:14karolherbst: I think, let me check again
17:17karolherbst: rhyskidd: okay, it was a different reg I was thinking about
17:18karolherbst: rhyskidd: also, please make PRs against envytools first before writing the patches against nouveau
17:22karolherbst: I got confused with the 0x20450 reg
17:39rhyskidd_: karolherbst: i've checked through nvbios repo and no prior uses of that reg that I can find
17:40rhyskidd_: it does appear to be a completely new feature of the Pascal series
17:41karolherbst: rhyskidd_: yeah, I kind of thought of 0x20450/0x2044c
17:41rhyskidd_: was writing the two patches on a train without wifi, so was bored and easy enough to bash both out and then refine via review comments
17:41rhyskidd_: (i'm expecting a few back and forths as I get the style right and any silly mistakes fixed)
17:46rhyskidd_: mupuf: i'm trying to get more on the SHADOWed concept, but I don't see any nvafaketemp tool & just a single IRC comment alongside your XDC2013 paper about it
17:46mupuf: rhyskidd: sorry, nvaforcetemp
19:09rhyskidd_: mupuf: No deliberate linkage of the SHADOWed comment to the functionality in nvaforcetemp. it's a separate hardware concept
19:09rhyskidd_: from REing
19:09mupuf: oh, odd. where did you get this from then?
19:10rhyskidd_: there's a comment in nvgpu's GPL source
19:10rhyskidd_: the tegra registers
19:18rhyskidd_: i'd seen one of the Trello cards was to better make use of the tegra docs, and this was a low hanging fruit. help my Pascal as well
19:19karolherbst: rhyskidd_: would be nice to have a way to "fake" the temperature on gm20x+ GPUs
19:20rhyskidd_: let me take a look at it
19:21rhyskidd_: i know this initial gp1xx implementation of therm doesn't touch all the pwm aspects
19:21rhyskidd_: which I saw when I was building off the gm107 and earlier code (and your pending patches for gm200 therm)
19:23rhyskidd_: i'll try to catch Lyude as well, as I saw she was working on pwm & reclocking on modern-ish series
19:25Lyude: i'm here atm, sup
19:25karolherbst: Lyude: you are working on reclocking I heard :O
19:26Lyude: karolherbst: no, powergating, I do test reclocking with heavy loads with it though to make sure nothing's broken though
19:26Lyude: I will be working on re'ing the ISO hub as well so we can have watermark support
19:26karolherbst: iso hub would be nice
19:27Lyude: Yeah, I'd think it might also be required to actually get DPM that doesn't flicker the screen wouldn't it?
19:28RSpliet: Lyude! Yes, getting the ISO hub going would be a great step forward. That's a prerequisite for dynamic VFS :-)
19:28karolherbst: Lyude: will you be at the XDC by the way?
19:28Lyude: karolherbst: yep! i'm on the attendee list as well o:
19:28RSpliet: I nearly invested a few hours in it myself today, but well... sunshine got the best of my time
19:28karolherbst: still need to book my flight and so, but will do so this week
19:29rhyskidd_: Lyude: was working on Pascal's new temp sensor support on the acela over the weekend, RFC patches in the IRC log for envytools and nouveau
19:29karolherbst: rhyskidd_: post to the ML, otherwise people forget
19:29Lyude: new temp sensor support? I thought we couldn't access those
19:30rhyskidd_: registers are in PTHERM
19:30karolherbst: Lyude: yeah, but I only looked at all the known regs
19:30rhyskidd_: which I *think* we get high security access to on Pascal now ...
19:30karolherbst: Lyude: seems like they use new regs with 1/256 precision
19:30karolherbst: Lyude: no clue why it has to be so precise....
19:30Lyude: karolherbst: maybe it's so that they can see rising temperatures more quickly and speed up the fan in response? idk
19:31karolherbst: Lyude: maybe
19:31karolherbst: but doubtful
19:31karolherbst: they already added 1/32 precision into the vbios
19:31Lyude: also, since when did we get high security access to PTHERM?
19:31karolherbst: and this should have been enough already
19:31karolherbst: rhyskidd_: reading stuff isn't the problem usually
19:32rhyskidd_: ah ok, then i mispoke re PTHERM
19:33karolherbst: Lyude: last time I looked on the list, there were 12 attendees on it :D
19:43rhyskidd_: XDC attendance has grown quite a bit since then!
20:35karolherbst: meh, GL_QUERY_RESULT_AVAILABLE results in index = -1 in get_query_result_resource
20:35karolherbst: which is currently not working on nouveau
20:35karolherbst: trying out tobijk patches
20:42imirkin_: that's surprising, since i'm the one who added it...
20:43karolherbst: well , 'KHR-GL45.direct_state_access.queries_functional' fails
20:44karolherbst: and glGetQueryBufferObjectiv with pname=GL_QUERY_RESULT_AVAILABLE seems to "return" the wrong values
20:47karolherbst: same value is "returned" as with pname=GL_QUERY_TARGET
20:59tobijk: karolherbst: mh the state should be in hq->state or something, yet that is nothing considered to be final
21:00karolherbst: and something is wrong regarding atoms in 'KHR-GL45.shader_atomic_counter_ops_tests.ShaderAtomicCounterOpsAdditionSubstrationTestCase'
21:00tobijk: not sure what you tested, as i havent touched something with externel query queriing (:o)
21:06karolherbst: mhh, robustness stuff
21:06karolherbst: I hope that doesn't messes with that test
21:10tobijk: mh my paches messing with that stuff? :/
21:10karolherbst: that "3: LOAD TEMP.x, BUFFER, IMM.xxxx" is wrong, isn't it?
21:11karolherbst: mhh, maybe it shouldn't better
21:11imirkin_: how so?
21:11imirkin_: uint after = atomicCounter(counter);
21:12tobijk: its inverted somehow
21:12karolherbst: "Reads the variable, atomicly." allthough a LOAD alone shouldbe atomicly already, or not?
21:13karolherbst: maybe not so much for 64 bit loads?
21:13tobijk: if (after != returned) outColor= vec4(1.0f); ?
21:13karolherbst: tobijk: it's a test value
21:13karolherbst: 0.0f means something went wrong
21:14karolherbst: tobijk: atomicCounterSubtractARB returns the value prior increment
21:14tobijk: yeah and if its the same, return 0
21:14karolherbst: which means: messed up
21:14tobijk: we do default = 0, if not equal =1
21:15karolherbst: default is 1.0
21:15tobijk: yep we optimize the other way round
21:15karolherbst: how so?
21:16karolherbst: MOV TEMP, IMM.xxxx
21:16tobijk: ups its .yyyy
21:16karolherbst: which writes 1 into TEMP
21:16tobijk: nver mind :>
21:17karolherbst: but yeah, the TGSI looks find I guess
21:17karolherbst: in doubt, apitrace
21:22karolherbst: uhh, the atomic operations are even across shader stages, fun
21:23tobijk: no touchy da atomic operations ;-)
21:24karolherbst: this is gonna be fun to debug