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