03:56 karolherbst: hakzsam, pmoreau: I checked the preprocessed output of the isinf thing and I get the function decleration from /usr/include/bits/mathcalls.h
03:57 karolherbst: but I guess glibc-2.23 moved stuff around and now it doesn't get declared anymore
03:58 pq: when in doubt on what to #include, see the manual
04:00 karolherbst: pq: no the question is rather why isinf is gone when compiling in c++11 mode with glibc-2.23
04:00 karolherbst: isinf seems to be only a macro there
04:00 karolherbst: where for me (glibc-2.22) it is a C function
04:00 karolherbst: and cmath #undefs isinf
04:00 pq: ooh, C++ woes
04:01 karolherbst: which doesn't change a thing for me, because I get the isinf C function decleration from /usr/include/bits/mathcalls.h
04:01 karolherbst: with c++11 there is std::isinf now, but this shouldn't just remove part of the C library API
04:02 pq: heh, I'd have expected std::math::traits<double>::isinf() or such
04:02 karolherbst: :D
04:02 karolherbst: nah
04:03 karolherbst: I thoguht traits are for statis stuff
04:03 karolherbst: *static
04:03 pq: perhaps, it's been long since I touched C++
04:04 karolherbst: c++11 is awesome :p
10:05 imirkin: pmoreau: could you check if dEQP-GLES3.functional.shaders.texture_functions.texturegrad.samplercube_float_vertex passes on blob?
10:08 imirkin: actually even if it fails, i'd still like a mmt trace of it
10:08 imirkin: on any gpu
11:03 jayhost`: imirkin changed perl script to python so I can do http://hastebin.com/vegumasudo.avrasm and then I abstract as much as I understand in http://hastebin.com/lanalaxoqe.parser3
11:03 imirkin: 000001f0: 0747ff03 eff07f80 st b32 a[0x74] $r3 0x0
11:04 imirkin: store a[0x74] in r3
11:04 imirkin: that's backwards
11:04 imirkin: you're on the right track
11:04 imirkin: but you need to collapse it down a lot more
11:04 imirkin: i.e. you have a straight translation of what the shader is doing
11:04 imirkin: however what i want to see is closer to like
11:04 imirkin: store a*b+c^d+73 into a[0x74] -- that sort of thing
11:05 imirkin: also
11:05 imirkin: 00000128: 0787ff0e efd80100 ld b32 $r14 a[0x78] $r2
11:05 imirkin: so that's a bit confusing
11:05 imirkin: that means "load a[0x78] from invocation $r2 into $r14". or something along those lines. it's not literally an invocation iirc
11:05 imirkin: but it's derived from that $invocation_info iirc
11:07 jayhost`: Cool, What is A in Ald, Invocation info, and isberd?
11:08 jayhost`: I'll work on it
11:08 imirkin: ALD = load shader input
11:08 imirkin: there are a bunch of different memory spaces
11:08 imirkin: A[] is the shader input/output memory space
11:08 imirkin: ALD/AST interact with it
11:30 imirkin: from what i can tell, ISBERD is "Input Space BE Read", where BE is defined by those $directbeaddresshigh/low or whatever they're called
11:31 imirkin: i'm not *100%* sure how it differs from a ALD with the proper lane info, but... somehow.
11:31 imirkin: or maybe ALD lost some of its flexibility
11:31 imirkin: or maybe ALD.PHYS is no longer a thing
11:31 imirkin: i dunno
11:36 glennk:mentally inserted an 'A' into that acronym when reading it
11:37 imirkin: :)
11:37 imirkin: glennk: perhaps you'd be interested in ISBERD.O then
11:53 jayhost`: hmm okay
11:54 imirkin: jayhost`: note that ALD reads from the shader input space, while AST writes into the shader output space, so they're different
11:54 imirkin: jayhost`: there's also a ALD.O which will read from the shader output space
13:09 pmoreau: imirkin: No problem, will do that tonight (except if I'm just sucked into configuring my new computer :-D)
13:10 imirkin: pmoreau: ok no worries
13:10 imirkin: it's not urgent
13:10 imirkin: i'm just curious how they do the manual derivatives stuff in a vertex shader
13:10 pmoreau: :-)
13:11 pmoreau: I'll try to find a way to make that computer available to you, in a not too distant future
13:11 imirkin: don't worry about that
13:11 pmoreau: It's meant to be a Reator-like, available to Nouveau devs
13:11 imirkin: doing the occasional trace for me is more than enough
13:12 pmoreau: But what if I feel lazy? :-p
13:12 imirkin: then i shall wait
13:13 pmoreau: :-D
13:15 pmoreau: imirkin: Is the second version of the commit message better: https://lists.freedesktop.org/archives/mesa-dev/2016-March/109813.html
13:16 imirkin: "the register allocation pass can skip that value since it is not being used"
13:16 imirkin: not quite right
13:16 imirkin: more like "the RA pass doesn't have to worry about whether it's defined by a short register or not"
13:16 imirkin: or something like that
13:18 pmoreau: If it doesn't have an instruction, it isn't used, is it?
13:19 pmoreau: Even if it was only passed to another function, `getInsn()` would return the `call` instruction I guess.
13:21 karolherbst: so if anybody has still issues with reclocking their kepler/maxwell cards, please ping me until I reply every 5 minutes
13:21 pmoreau: lol
13:21 karolherbst: I mean it :p
13:22 pmoreau: Even Max gen2? O:-D
13:22 karolherbst: I don't want anybody complaint that all the other cards reclock but that one not
13:22 karolherbst: ahh well, memory will be tricky there
13:22 imirkin: pmoreau: i don't think it's linked to the call instruction
13:23 imirkin: coz it's a pre-colored node
13:23 karolherbst: pmoreau: I am just a bit sad that for some cards my changes will reduce performance, because lower clocks are choosen. I just hope nobody notice
13:24 pmoreau: Alright, in that case I understand better why my formulation is not quite right :-)
13:24 pmoreau: karolherbst: I'll give it a run on the only Kepler I have
13:24 karolherbst: nice :)
13:24 karolherbst: and please add your vbios
13:25 pmoreau: imirkin: Test passes, let me generate the MMT now…
13:25 glennk:wonders how tricky changing clocks on hbm2 is compared to gddr5
13:26 karolherbst: glennk: in can only get easier
13:26 glennk: it ought to be simpler
13:27 imirkin: pmoreau: thanks
13:27 pmoreau: Pascal will have HBM2, but not Polaris, right?
13:27 karolherbst: pmoreau:
13:27 karolherbst: pmoreau: I am more worried about NVLink
13:28 pmoreau: imirkin: Have fun: https://phabricator.pmoreau.org/F38036
13:28 glennk: nvlink is only a thing on power8 afaik
13:29 imirkin: pmoreau: great
13:31 karolherbst: did maxwell also sound like a really big change at first? Because with pascal I get the feeling that everything changes...
13:31 karolherbst: glennk: right, nvlink is for power and arm64
13:32 imirkin: hmmmmmm ok. it renormalizes every time.
13:32 imirkin: which makes sense
13:32 imirkin: i was just hoping i didn't have to do that
13:33 karolherbst: ohhh
13:33 karolherbst: there will be nvlink on desktop between gpus
13:33 karolherbst: well nouveau doesn't even do SLI so...
13:56 imirkin: pmoreau: nouveau passes now =]
13:59 imirkin: gr, stupid whack-a-mole. now dEQP-GLES3.functional.shaders.texture_functions.texturegrad.samplercubeshadow_fragment fails.
14:00 pmoreau: Great for the float_vertex one! :-)
14:00 pmoreau: Need anything for the shadow_fragment?
14:03 imirkin: someone to explain why the thing i did is breaking it
14:06 imirkin: oh
14:06 imirkin: coz i messed it up.
14:10 imirkin: it appears that past-me outsmarted present-me. oh well, future-me will defeat them both
14:11 imirkin: Passed: 117/117 (100.0%)
14:11 arizo: any news?
14:11 imirkin: arizo: https://nouveau.freedesktop.org/wiki/
14:12 imirkin: [hm, i guess i should update that about GM20x landing in 4.6...]
14:16 arizo: imirkin: i have fermi, nothing new for me
14:17 imirkin: depends as of when
14:17 imirkin: GL 4.1 support now available on fermi
14:17 arizo: but if games is dx?
14:17 arizo: it can't be translated into GL
14:18 imirkin: why not?
14:18 imirkin: that's what wine does...
14:18 imirkin: [among other things]
14:18 arizo: they told they are only planning to make DX to GL bridge
14:19 imirkin: wine does that
14:19 arizo: or is it already done?
14:19 arizo: but dx11 are not supported rigt?
14:19 imirkin: that's right
14:19 imirkin: they're working on it
14:19 imirkin: but not done afaik
14:19 imirkin: best ask the wine folk for info on that, i have no idea what the status is
14:20 arizo: i have they will activate reclocking for fermi
14:20 imirkin: that remains a tbd item
14:20 arizo: ?
14:20 imirkin: to be done
14:20 arizo: to be done?
14:20 arizo: nice
14:20 arizo: i don't want to recompile the enire os due to proprietary driver
14:36 imirkin: pmoreau: if you have a nv50 handy, can you check if dEQP-GLES3.functional.shaders.texture_functions.texturegrad.samplercube_fixed_vertex passes on the blob?
14:36 imirkin: it fails on nouveau even with all my fixes =/
14:37 imirkin: while the frag one passes
14:38 imirkin: the only failures are in the texturegrad cube vs case, but i have no idea how to fix them...
14:39 imirkin: or it might just be impossible given hw restrictions =/ dunno
14:41 pmoreau: imirkin: Any NV50?
14:41 imirkin: ya
14:41 pmoreau: K
14:41 imirkin: oh dear... this logic will totally not work for cube arrays either...
14:41 imirkin: good thing those aren't supported in GLES
14:44 karolherbst: pmoreau: would you mind uploading your vbios or would it be too big of an hazzle now? Because then I could already check if there are any surprises
14:44 pmoreau: I have to setup dEQP on the old laptop
14:46 pmoreau: karolherbst: How do you get it from the blob?
14:46 karolherbst: pmoreau: nvagetvbios
14:46 karolherbst: *nvagetbios
14:46 karolherbst: you might have to add -s prom though
14:48 karolherbst: yep, nvagetbios -s prom works for me with blob
14:48 pmoreau: I get some errors: can't probe PCI 1
14:48 karolherbst: root
14:48 pmoreau: I am running it as root
14:48 karolherbst: is it a laptop or desktop?
14:48 pmoreau: laptop
14:49 pmoreau: with a gmux
14:49 karolherbst: ahhh
14:49 karolherbst: mhh
14:49 karolherbst: it even works with no driver loaded here
14:50 karolherbst: I get the probe issue only when I run as non root
14:50 pmoreau: Yeah, it's weird…
14:53 karolherbst1: and doing nvagetbios on a non POSTED card crashes the kernel..
15:00 karolherbst: pmoreau: no idea otherwise :/
15:07 pmoreau: karolherbst: I'll try again with Nouveau
15:12 karolherbst: stupid pm-suspend. it deactivates wake-on-lan ...
15:22 karolherbst: uhh, anybody know bindiff?
15:37 imirkin: pmoreau: any luck?
16:09 karolherbst: do we want to add documentation of other devices also to rnndb?
16:27 imirkin: karolherbst: what did you have in mind?
16:28 karolherbst: imirkin: MCP79 ethernet card
16:29 karolherbst: but
16:29 karolherbst: that entire thing is usefull for all kind of hardware actually
16:29 imirkin: i dunno... ask mwk
16:29 imirkin: he's the defacto rnndb maintainer
16:29 karolherbst: I am pretty sure other RE projects also might have tools like that, but it would make sense to somewhat generalize all that stuff
16:40 mwk: karolherbst: I'm fine with anything nvidia
16:41 mwk: I planned on adding APU docs myself one day, actually
16:41 karolherbst: mwk: any reasons why not to make some parts generic?
16:41 karolherbst: *making
16:42 mwk: what parts and how generic?
16:43 karolherbst: like nvapeek or nvapoke, or rnndb
16:43 pmoreau: imirkin: I get: "FATAL ERROR: glGetIntegerv(GL_NUM_EXTENSIONS): glGetError() returned GL_INVALID_ENUM at gluRenderContext.cpp:203"
16:43 mwk: and what kind of generic?
16:44 imirkin: pmoreau: errrr what? sounds like the GLES lib wasn't properly installed
16:44 imirkin: pmoreau: or something like that...
16:44 karolherbst: mwk: to be able to use those tools for non nvidia devices, so that other projects which rely on RE can use it too
16:44 mwk: as I said - I'm fine with anything nvidia - GPUs, bridges, chipsets, Tegras
16:44 mwk: mostly since there's overlap between these anyway
16:46 mwk: as for other stuff... separate rnndb/ directory would likely be the way to go
16:46 pmoreau: I can see the libraries in the filesystem, and glxinfo reports ES 2.0. Any other way to check what could be happening?
16:46 mwk: not sure about the nva stuff
16:47 imirkin: pmoreau: huh, ok. weird.
16:47 imirkin: pmoreau: well that's sad =/
16:47 imirkin: it totally could support GLES 3.0...
16:47 pmoreau: :-/
16:48 karolherbst: mwk: well I could imagine that peek, poke, scan... can be pretty usefull for other devices as well
16:48 karolherbst: it was just a thought I had the past days I was toying with my ethernet card
18:10 karolherbst: kugel: ping
18:24 imirkin: pmoreau: could you try to write a shader_test that uses textureGrad in combination with a samplerCube and then mmt trace it to get the shader?
18:24 imirkin: pmoreau: it doesn't have to be fancy, or even pass, i just want the shader that's generated on nv50
21:29 jayhost`: imirkin well I wrote it all by
21:29 jayhost`: "hand" but its messy/incorrect? so just going to write script instead