13:01 karolherbst: mhh currently thinking of not going to SHA and do a lot of nouveau stuff instead...
13:02 karolherbst: would be cool if somebody could come over the weekend during that time or so :D
16:33 karolherbst: mupuf: ... okay this is odd. first I thought there is a header field in the thermal policy table to tell which entry to use, cause those bytes are 00 for single entry tables and one might be 1 for tables with two entries
16:33 karolherbst: but at least on kepler those bytes doesn't really matter if we just downclock
16:33 karolherbst: it seems like the driver just picks the lowest
16:33 karolherbst: allthough I know there is more to it
16:34 karolherbst: but practically if we go with a simple and still effective implementation, we can just iterate over all and pick the lower one
16:36 karolherbst: ohh wait, that one value might be a ff
16:51 mwk: beautiful.
16:51 mwk: just what the fuck is that.
16:54 imirkin_: i guess it didn't end up mattering enough?
16:55 mwk: well, they did fix that for NV11/NV15
16:56 imirkin_: the GF2's came out pretty quickly right?
16:57 imirkin_: so it basically double-multiplied the last row?
16:59 mwk: *shrug*
16:59 mwk: no
16:59 mwk: output TXC.S is input TXC <dot> matrix row
16:59 mwk: but output TXC.Q is (output TXC.S, input TXC.TRQ) <dot> matrix row
17:00 mwk: ie. it wrongly uses output TXC.S instead of input TXC.S for some reason to compute TXC.Q
17:00 imirkin_: ah
17:03 imirkin_: is txc.q used for anything?
17:06 imirkin_: i guess maybe with NV_texture_shader it could be...
17:06 imirkin_: but that wasn't a thing until later
17:06 mwk: of course it is
17:06 mwk: s and t are divided by it, post-interpolation
17:06 imirkin_: oh hm
17:07 imirkin_: i assumed they used the position's thing...
17:07 mwk: both
17:07 imirkin_: ok
17:13 karolherbst: uhm, in case you are interested shadow warior for free here: https://www.humblebundle.com/store/shadow-warrior-special-edition
17:37 mwk: imirkin_: final s = interpolate (tl s / tl w) / interpolate (tl q / tl w)
17:37 mwk: that's the exact formula for fixed-function
17:37 mwk: in the usual case of q == 1, it reduces to interpolate(tl s / tl w) / interpolate (1 / tl w)
17:38 imirkin_: oh right
17:38 imirkin_: hm
17:39 imirkin_: some day i'll figure out how interpolation works
17:39 mwk: some day I will too
17:39 imirkin_: so i/j barycentric coords are generated
17:40 imirkin_: and the xyz coords are transformed to be barycentric-friendly
17:40 mwk: that's the definition
17:40 mwk: but AFAIK all hardware actually does that by computing plane equations instead
17:40 imirkin_: and then you just combine the friendly coords by doing a*i+b*j+z
17:40 imirkin_: ah hm
17:41 mwk: with Tesla, I should be able to look directly into whatever memory holds the equations
17:41 mwk:hopes to find some answers this way
17:41 imirkin_: (er, xyz is totally wrong, ignore that. i think you know what i meant... the 3 values at the coords)
17:41 mwk: yea
17:42 imirkin_: so the "w" is used on gl_Position
17:42 imirkin_: but i wasn't aware of it being used for anything else
17:42 mwk: it's quite crucial
17:42 imirkin_: that w is used for the barycentric coordinate generation
17:42 mwk: for perspective-correct interpolation of vertex attributes
17:43 mwk: basically every attribute that you want to interpolate is divided by w before interpolation
17:43 imirkin_: i thought you just attached texture coords to each vertex
17:43 imirkin_: and then interpolated based on that vertex position
17:43 mwk: and then divided by interpolate(1 / w) in fragment program
17:43 imirkin_: by that attrib's w?
17:43 mwk: by pos.w
17:43 imirkin_: so each attrib has a separate w?
17:43 imirkin_: right, pos.w
17:43 imirkin_: so... wtf is txc.w?
17:44 mwk: txc.q, you mean?
17:44 imirkin_: sure, wtvr
17:44 mwk: mostly it's just 1
17:44 imirkin_: why is it ever included in an interpolation calculation?
17:44 mwk: but if you want to do weird homogenous transforms, you can set it to something else
17:44 imirkin_: hm ok
17:46 mwk: eg. if the triangle should act as a "window" to some cubemap or wtvr
17:46 mwk: or a mirror
19:14 rhyskidd_: planning the Pascal work (RE and documenting) I can get done in the next few days
19:14 rhyskidd_: any more thoughts about the ELPG doc work I put up last week?
19:22 karolherbst: hard... doing this: u16 = min(u16, (u16 + s16) / 32); ... I thought changing the u16 into s16s might help, but apperantly it doesn't
19:23 karolherbst: ohh wait, does the compile things the latter argument is s32?
19:23 karolherbst: *compiler
19:58 rhyskidd_: can someone help me understand the purpose of the nwhw/ folder in envytools?
19:58 rhyskidd_: i.e. why is the simulation of nv ISA instructions in software helpful?
20:06 luv: hi there, might a little off-topic but can't hink of a better place to ask than here ... I'm trying to reverse engineering communication between X and nouveau - only interested in nv-control at the moment
20:06 luv: https://github.com/NVIDIA/nvidia-settings/blob/master/doc/NV-CONTROL-API.txt
20:07 luv: I am trying to figure out what X actually does (how it communicates with the nvidia kernel driver) when setting the fan speed and clocking cpu/mem, setting a perf level
20:09 luv: with the nvidia kernel driver you actually have to run X and use the nv control api (via nvidia-settings for example) to do that ... that's pretty stupid on a headless server and moreover it's buggy as hell (for example killing the X server makes the card go to a different performance mode and there is nothing you can do about it ... and other bugs as well)
20:11 luv: so i'd like to reverse engineer that between X and the nvidia kernel driver in this respect and write an open-source minimal program to control the fan/clocking/perf level without X ... so just thought I would ask for any hints before I dive in :)
21:32 mwk: rhyskidd: for reference purposes, mostly
21:32 mwk: it's validated against acctual hw with hwtests
21:33 mwk: just one of many RE tools
21:33 imirkin_: luv: check valgrind-mmt
21:34 luv: thanks
21:34 luv: looks handy :)
21:37 imirkin_: luv: but really any kind of ioctl capture is probably enough for the NV-CONTROL Thing
21:38 luv: yeah, even a simple strace of nvidia-settings seems to be a good start
21:38 imirkin_: well, nvidia-settings will just talk over the X api
21:38 imirkin_: [i assume]
21:39 luv: yeah .. that's what i thought as well but in the strace i can see it opens /dev/nvidiactl and does a bunch of ioctl syscalls
21:45 luv: oh ... it looks like some stuff is done directly (https://developer.nvidia.com/nvidia-management-library-nvml) and some is via X