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