00:32Yoshimo: It seems that i screwed up when switching between binary and opensource driver. What could have gone wrong if switching to Nouveau results in a blackscreen without gui login and only a working terminal? As soon as i install nvidia-352 and all the other dependencies that were purged it comes back as nothing happened.
00:38jayhost: imirkin I imagine isberd could stand for "Is Barycentric Coordinates?"
00:45Tom^: Yoshimo: you probably missed the xf86-video-nouveau xorg driver.
00:45Tom^: Yoshimo: but yea pastebin the Xorg.0.log when it blackscreens otherwise
02:10Yoshimo: Tom^: https://pastee.org/ghc4m
03:21Yoshimo: Tom^: i guess that wasn't meant for me? ;)
03:22Tom^: sure it was, the info you provided helps for others to help you. even if i dont know what the issue is.
03:24Yoshimo: looked like a typo, sorry
03:24Tom^: oh you meant the 123/set
03:24Tom^: xD yea that was buffer error :P
05:34pmoreau: Yoshimo: You still have some NVIDIA libgl stuff: "Failed to load /usr/lib/x86_64-linux-gnu/xorg/extra-modules/libglx.so: libnvidia-tls.so.346.96"
06:18Yoshimo: pmoreau: shouldn't removing all nvidia packages kill that one too?
06:41Yoshimo: would just deleting that file be enough?
07:12yoshimo: https://pastee.org/hrfu9 , what are these nouveau 0000:01:00.0: priv: GPC0: 419df4 00000000 (1a40820e) about?
07:14pmoreau: I think they are related to the secure firmwares. I have them as well when loading Nouveau on the GM200, and mupuf as them on his GM206
07:15yoshimo: [ 1.178995] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 022554 [ IBUS ] , that too?
07:15pmoreau: I don't recall having that one
07:16pmoreau: Which version of Nouveau are you using? The one from 4.4.3 or did you built the out-of-tree version?
07:18yoshimo: it should be karols maxwell-reclocking branch, if i did everything correctly
07:18yoshimo: so it is out of tree
07:19pmoreau: But does it have the logic to load secure firmwares?
07:19pmoreau: Yep, looks like it does
07:20pmoreau: So are you still experiencing a black screen? Or is it working now?
07:21yoshimo: i killed the file we mentioned earlier, and it finally is solved
07:22yoshimo: seems like updating the binary in the past left some files
07:22pmoreau: But great that it now works :-)
07:23pmoreau: So if you run glxinfo, you get Nouveau on that GM204?
07:23imirkin: you'd need mesa-git for that
07:24imirkin: jayhost: isberd... i'm guessing rd = read, be is in reference to the be in directbewriteaddresshigh/low, and is... input source? who knows.
07:25yoshimo: pmoreau: https://pastee.org/9mk6d glxinfo output
07:26pmoreau: Eh, only 3.3? Shouldn't it be at least 4.0 on Maxwell? Or is it due to missing tesselation support there?
07:30yoshimo: i would guess so, tesselation is part of 4.0 according to mesamatrix
07:37imirkin: no tess for maxwell
07:54yoshimo: karolherbst: could 1.178995] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 022554 [ IBUS ] be your code?
08:00yoshimo: i thought it might be an attempt at reading power or so
08:01karolherbst: no, power is read through the i2c system
08:02yoshimo: we don't have access to that on gm20x yet, do we?
08:03karolherbst: we have
08:03karolherbst: but not all gpus have power sensors
08:11yoshimo: ok, as long as that can happen
08:24imirkin: anyone have a kepler and dEQP?
08:24imirkin: i'd like to know whether dEQP-GLES3.functional.transform_feedback.basic_types.interleaved.points.lowp_float passes or not
08:24imirkin: you can run it as ./deqp-gles3 --deqp-case='dEQP-GLES3.functional.transform_feedback.basic_types.interleaved.points.lowp_float'
08:26imirkin: hakzsam: perhaps you do?
08:28pmoreau: imirkin: I have a GK107 at hand, how do I install deqp?
08:28imirkin: pmoreau: grab https://android.googlesource.com/platform/external/deqp/
08:29imirkin: pmoreau: do you have xorg 1.18.1?
08:29pmoreau: Most likely, it's a fresh Arch install
08:30imirkin: ok, then just apply this patch: http://hastebin.com/negiwihoyi.avrasm
08:30imirkin: and then build with... (sec)
08:30pmoreau: Mesa Git?
08:30imirkin: cmake -DDEQP_TARGET=x11_egl_glx .
08:31imirkin: doesn't matter
08:31imirkin: [well, it might matter if you get crashes... i pushed an xfb-related fix just now, not sure if this test will trigger the issue or not]
08:33imirkin: pmoreau: and then go into modules/gles3 and run the command above [after you've built of course]
08:34pmoreau: Might take a bit of time, need to clone Mesa & co
08:35imirkin: why? just use system mesa for now
08:35pmoreau: Oh right, it's not Mesa I need to patch
08:35imirkin: if this test passes on kepler, i'll be very dissapointed in nvidia.
08:39pmoreau: It expects python2
08:39imirkin: python == python2.
08:39imirkin: it's sad that arch is broken =/
08:39pmoreau: python == python3
08:40imirkin: even sadder that they don't perceive that as breakage.
08:40imirkin: no, that's like saying that g++ is c++11
08:40imirkin: things break when you do that
08:41jayhost: imirkin okay. I guess the registers r0-Rn don't corrospond to triangle cords then.
08:41pmoreau: Well, isn't g++ defaulting to C++11 nowadays? :-D
08:41imirkin: the standard, forever, was you just execute python, and it works. then python3 comes along, non-backwards compatible, that means it has to get a different binary name.
08:41imirkin: jayhost: they're just GPRs
08:42imirkin: pmoreau: anyways, i guess long story short, arch isn't usable for deqp. good to know.
08:42imirkin: thanks for checking it out though
08:43pmoreau: Well, I just moved the exe, and it's compiling now
08:43karolherbst: pmoreau: I thoguth the ABI defaults to the new one, but API is still the old one :O
08:43jayhost: What would be the process of turning the assembly into C-Ish. Going through manually?
08:44karolherbst: jayhost: and why would you want to do that?
08:44imirkin: jayhost: yep
08:44imirkin: karolherbst: because i asked him to
08:44karolherbst: ahh okay
08:44jayhost: Anything with
08:45jayhost: "Code :"
08:45imirkin: karolherbst: if you have better suggestions for figuring out what blob shader logic is doing, let me know.
08:45imirkin: jayhost: no, just pick one TCP and one TEP
08:45imirkin: and go from there
08:45karolherbst: imirkin: make a nive graph?
08:45imirkin: karolherbst: no idea what that is... if this is something actionable that he could do, please explain it to him
08:49karolherbst: imirkin: and when you got time, can you look through the two opts I got here? https://github.com/karolherbst/mesa/commits/to_upstream
08:52pmoreau: imirkin: FATAL ERROR: GLX call failed: 'catory.m_glXCreateContextAttribsARB( getXDisplay(), m_fbConfig, DE_NULL, True, attribs)' at tcuX11GlxPlatform.cpp:332
08:52imirkin: pmoreau: right. you need fresh mesa, sorry!
08:52pmoreau: No problem :-)
08:52imirkin: or i can give you a patch to deqp... but i think you should get fresh mesa anyways
08:53pmoreau: I was planning to get one, since I'll be hacking on SPIR-V on that new laptop as well ;-)
08:56imirkin: do you knwo what's plugged into reator right now btw?
08:57pmoreau: GK106 and GM107 IIRC
09:18pmoreau: --" I had forgotten to set MAKEFLAGS, and it was compiling with one core out of 8…
09:21imirkin: make -j8? :)
09:23pmoreau: I usually have `export MAKEFLAGS=--jobs=8` in my .zshrc, but since it's a new machine, I don't have my dotfiles on it yet…
10:46karolherbst: ohhhh I found something nice
10:46karolherbst: nvac gpu, 9400m inside a mac mini
10:48imirkin: pmoreau: so were you able to get stuff built?
11:32RSpliet: karolherbst: ah excellent. clock changing works very stable for that board (without flicker, no dedicated VRAM), so a nice target if you want to develop DVFS for PMU-less NV50-like boards
11:40pmoreau: imirkin: Sorry, had to run to catch the bus.
11:40pmoreau: Going to try again
11:41karolherbst: RSpliet: the fan is broken though, but I wanted to use it for max os x development at some point, it was sold as bricked, so it was rather cheap
11:42karolherbst: RSpliet: its a 2.53GHz core 2 duao thugh
11:42karolherbst: and I think 4 or 8 DDr3 ram :)
11:46imirkin: karolherbst, pmoreau - if one of you could trace this deqp test on kepler (or fermi) on the blob, that'd be useful: dEQP-GLES3.functional.shaders.texture_functions.textureoffset.sampler3d_float_fragment
11:46imirkin: it looks like we're messing up 3d texture offsets
11:46pmoreau: Hum… Making the Intel the primary GPU was a bad idea… I just get a black screen upon boot. :-/
11:58imirkin: and also a trace of dEQP-GLES3.functional.shaders.fragdata.draw_buffers would be most interesting
11:58imirkin: [and whether it passes or not... if it fails, then i don't care about the trace]
12:08pmoreau: Meh… Why do I have only 2.1 support… What went wrong
12:11pmoreau: Who is that stupid person who wrote that installation script I used… :-D
12:32pmoreau: Working better :-) (I really need to migrate all my dotfiles… I keep forgetting about make jobs…)
12:32pmoreau: So, now let's test
12:33pmoreau: imirkin: Pass! :-)
12:34imirkin: pmoreau: for which one?
12:34pmoreau: The one you asked earlier today, transform feedback
12:34pmoreau: I'm not there yet to the blob ones
12:35imirkin: pmoreau: ok. well, that's VERY disappointing then.
12:35imirkin: i guess i have to have some sort of special workaround for nvc0
12:42imirkin: pmoreau: so yeah, no need to do a blob trace of that test.
12:43imirkin: pmoreau: but a blob trace of dEQP-GLES3.functional.shaders.texture_functions.textureoffset.sampler3d_float_fragment would be interesting.
12:43imirkin: i need a blob trace of that test on fermi, i guess
12:43imirkin: since nouveau fails on fermi for it
12:55imirkin: skeggsb: http://hastebin.com/rabicoraxo.xml - that's a pretty high order to be kmalloc'ing...
13:01RSpliet: imirkin: is that like 64-128KiB?
13:22RSpliet: simonpatapon: hello. In good IRC spirit: don't ask to ask, just ask!
13:22simonpatapon: how is it going
13:24simonpatapon: I m quad screen but last debian update broke my settings
13:24simonpatapon: when i try to activate my second set of screens
13:25simonpatapon: i do xrandr --setprovideroutputsource 1 0 then user arandr or gnome-setting to activate both and set position
13:25simonpatapon: since last update, activating one screen cashes X and get me back to gdm3
13:25simonpatapon: heres a syslog http://pastebin.com/kGjHVTFP
13:26imirkin: last update being from xorg 1.17 to xorg 1.18 perhaps?
13:26imirkin: if so, you probably need https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=b824d36c28124955eda4aced5e637aa75eea4d6c
13:26imirkin: although that shouldn't cause X to crash
13:28simonpatapon: im on 1.18 yes
13:29imirkin: not sure what log you pasted, but that is not the Xorg log... that might be more interesting
13:30simonpatapon: where are those logs, /var/log/Xorg seems to be old logs
13:31imirkin: dunno, i don't do distro support...
13:31imirkin: on my box it's /var/log/Xorg.0.log
13:31simonpatapon: ok let me see
13:33simonpatapon: ok now in ~/.local/share/xorg
13:35simonpatapon: here you go, sorry for my noobyness http://pastebin.com/hGst6a25
13:35RSpliet: karolherbst: sorry you had to wait for pushing my data this weekend, VBIOS is in the repo
13:35RSpliet: I'll push some trace later on...
13:35karolherbst: RSpliet: thanks
13:35RSpliet: you wanted... me to run your inspection tool too right?
13:38imirkin: simonpatapon: that log seems perfectly happy
13:41imirkin: simonpatapon: no crash, no nothing... so... i dunno why X is exiting, but there's no indication of the reason in that log.
13:41simonpatapon: sorry, thats the new session i guess
13:42simonpatapon: this one crashes http://pastebin.com/NKdFEPUM
13:42simonpatapon: sorry again
13:42imirkin: simonpatapon: anything in dmesg?
13:43imirkin: (this is indicative of a gpu hang)
13:43simonpatapon: lots of traps
13:44imirkin: [the whole thing]
13:44simonpatapon: thank for your time
13:44simonpatapon: I remeber you helping me back when i bought the new screens
13:45imirkin: nah, that all seems happy
13:46imirkin: X exits or something, various processes crash, which is expected
13:46imirkin: the only thing i can think of is that new versions of X do weird things with the mouse pointer
13:46imirkin: which in turn triggered badness in our display update logic
13:47imirkin: this is fixed in recent kernels, but you're on a 2+ year old kernel, so... dunno
13:47imirkin: i'd check to see if you can repro the issue with kernel 4.4
13:47imirkin: you could also downgrade X, that might fix it too
13:48simonpatapon: ok, ill look fot that
13:49imirkin: [as before, no clue how to do any of this on your distro, and i can't really help you with that]
13:50simonpatapon: I understand
13:50hakzsam: imirkin, what do you want me to do?
13:50RSpliet: karolherbst: mind telling precisely, command-per-command, what kind of information you want from this GTX650?
13:52karolherbst: RSpliet: yeah, current stable_reclocking_kepler_v2 branch
13:52karolherbst: RSpliet: boot with blob
13:52RSpliet: got that built and loaded
13:52karolherbst: RSpliet: compile in nouveau root
13:52karolherbst: RSpliet: LD_LIBRARY_PATH=lib bin/nv_cmp_volt
13:52RSpliet: that only gives the header as output, then it exits
13:53RSpliet: considering the use of a while true loop, yes rather odd :-P
13:53karolherbst: does it crash or something=
13:54RSpliet: karolherbst: http://fpaste.org/334901/45730126/
13:55karolherbst: so either best_cstate or best_pstate is null
13:55RSpliet: or both
13:55karolherbst: yeah right
13:55karolherbst: but that would mean for your gpu there is no cstates/pstates
13:58RSpliet: you can take a look at the VBIOS to verify
13:58RSpliet: but the program doesn't handle that case? seems quite important for pre-keplers?
14:00karolherbst: what do you mean by pre kepler?
14:00RSpliet: karolherbst: anyway, there's a CSTEP table, a BOOST table, a PM_MODE (I assume that's PSTATE, maybe we should fix nvbios naming) table
14:00karolherbst: this is a kepler card
14:01RSpliet: Curie, Rankine, Tesla, Fermi? :-P
14:01karolherbst: gk107 isn't it?
14:01RSpliet: yes, this particular card is a kepler
14:01karolherbst: ahh you meant in general
14:01karolherbst: well for pre fermi this tool makes no sense
14:02RSpliet: anyway, let's focus on extracting your info :-P
14:02karolherbst: RSpliet: I guess best_cstate is null and best_pstate not
14:02RSpliet: likely yes
14:02karolherbst: if best_cstate == NULL; best_cstate = pstate->base
14:02karolherbst: I think it was base
14:03RSpliet: is that what you'd like me to add?
14:03karolherbst: after the outer list_for_each loop
14:03karolherbst: best_cstate = &pstate->base; actually
14:04RSpliet: still segfaults
14:05karolherbst: ahh right
14:05karolherbst: update my branch pls :D
14:05karolherbst: I did something stupid and I reverted to the original state
14:06pmoreau: Anyone against me pushing glibc 2.23 "support" to valgrind? I was still able to run mmt with the patch.
14:06RSpliet: karolherbst: okay
14:06RSpliet: btw:(gdb) p best_pstate
14:06RSpliet: $4 = (struct nvkm_pstate *) 0x0
14:06hakzsam: pmoreau, make a PR maybe?
14:06karolherbst: wait, no pstates?
14:07RSpliet: plenty of pstates
14:07karolherbst: ohhhh I know
14:07karolherbst: I see it now
14:08RSpliet: but yes, without your modfication both best_cstate and best_pstate are null
14:08karolherbst: yeha I know where the issue is
14:08karolherbst: there are no cstates for a pstate
14:08karolherbst: RSpliet: how long will you keep the gpu?
14:09RSpliet: preferrably just today
14:09RSpliet: it'll be in the lab for a bit longer, so I can nick it one or two weekends
14:10karolherbst: okay, then a fast dirty hack
14:10RSpliet: but make sure in the next hour I take all the data you need for a week of hacking up ;-)
14:12karolherbst: RSpliet: k, update branch and build pls :)
14:16RSpliet: is that quick and dirty enough?
14:17karolherbst: doesn't seem to be any voltage issues
14:17RSpliet: yep, unlikely that a voltage too high causes crashes, just temperature issues
14:17RSpliet: do you expect it to run at 1058MHz?
14:18karolherbst: there are only three clocks for your gpu
14:18karolherbst: so yes, it should run at 1058
14:18karolherbst: but why doesn't it run stable ..
14:18RSpliet: sorry, what I meant was: would nouveau have picked 1058 as well
14:18RSpliet: idk, want me to try and trace through it?
14:19karolherbst: would be awesome
14:19karolherbst: maybe there is something wrong
14:19RSpliet: good, I'll push an MMIOTrace in about 10 minutes
14:19karolherbst: can you push one with nouveau too?
14:21karolherbst: RSpliet: nouveau ran at 1.1V I think?
14:21karolherbst: it could be, that the VID is messed up and the previous one would work, but I don't want to believe we get issues like that
14:26RSpliet: I don't have a copy of your branch running on this machine, so getting a nouveau trace'll be tricky
14:27karolherbst: ohh okay
14:27RSpliet: just pushed a trace
14:27karolherbst: that's without reclocking
14:28RSpliet: there should be a few clock changes in there
14:29RSpliet: how did your tool make up that expected voltage? the value "1097167" is nowhere in the VBIOS to the best of my knowledge
14:29karolherbst: but it can't be a volting issue, or nouveau has a different code for setting and reading voltage :/
14:29karolherbst: RSpliet: easy
14:29karolherbst: see the voltage map table?
14:30karolherbst: pstate 0xf has voltage entry 4 attached
14:30karolherbst: which means this: -- ID = 4, mode: 0 link: 2, voltage_min = 1062500, voltage_max = 1137500 [µV] c0 16742478 c1 -3435 c2 0 c3 0 c4 0 c5 0--
14:30RSpliet: yeah, I see that
14:30karolherbst: now you get c0 * 0.1 + c1 * 168
14:30karolherbst: here is the rather complete table for now: https://gist.github.com/karolherbst/3618ce3bf994779a3e0d
14:31karolherbst: you can imagine how nice it was to RE the coefficients :D
14:31karolherbst: mode 1 c5 is a nice one though
14:31karolherbst: temperature^2 ... :D
14:32karolherbst: there might be still chipset specific "speedo" factors inside those coefficients :/
14:32karolherbst: but I wasn't insane enough to also RE those out
14:32RSpliet: okay, but NVIDIA chooses a lower voltage, I'd assume it'd round up instead
14:32karolherbst: I wasn't exactly precise
14:32karolherbst: we don't know what nvidia calculates
14:33karolherbst: and how nvidia rounds
14:33karolherbst: and we also don't know if it chooses as the best voltage setting
14:33karolherbst: maybe it uses a lower voltage if it is 0.01V off
14:33karolherbst: maybe only for 0.005V
14:33karolherbst: and because I have no clue about this, we only can get this close :D
14:34RSpliet: sure, well, anyway, if nouveau picks 1.1V it should work
14:34karolherbst: so nouveau might end up setting the voltage one/two steps too high/low
14:34RSpliet: that shouldn't be harmful, just a waste of energy
14:35RSpliet: anyway, anything else that might be remotely useful?
14:35karolherbst: it would be nice to know if it crashes due to memory or due to clock
14:36RSpliet: I ran upstream on it, and that didn't crash
14:37karolherbst: ohh right
14:37karolherbst: because upstream doesn't clock at all
14:37RSpliet: upstream refuses to change the clocks because it can't find a suitable voltage
14:37RSpliet: (whereas on my DDR3 card it works fine)
14:39RSpliet: (which is interesting in it's own right... but I'll let you take a look at that when time is due, first fix what is broken, then fix what isn't)
14:39karolherbst: I am out of ideas though
14:40karolherbst: RSpliet: it only crashed under load, right?
14:40karolherbst: reclocking itself workd
14:40RSpliet: it crashes as soon as I try to use PGRAPH
14:40RSpliet: running XFCE is not an issue
14:41imirkin: and XFCE doesn't use PGRAPH??
14:41imirkin: are you cpu-accelerated?
14:41karolherbst: maybe not enough
14:41imirkin: or rather, cpu-rendered
14:41imirkin: coz EXA uses PGRAPH...
14:41karolherbst: RSpliet: maybe nouveau clocks some engines differently
14:42karolherbst: and one engine is too much off
14:42RSpliet: ah, in that case it probably does use PGRAPH and I once again need to sharpen my definitions
14:42karolherbst: I could imagine that nouveau is a bit confused about the cstate table or something
14:42karolherbst: RSpliet: k, you need something
14:42RSpliet: but XFCE is not a GL accelerated workload, so I take it it only does blits, colourspace conversions and uploads (...?)
14:43imirkin: in that it doesn't use glFoo? true
14:43imirkin: however perhaps you might have a look at how the EXA stuff is implemented
14:43imirkin: it uses the 3d pipeline for plenty of stuff
14:44imirkin: and i doubt your gpu cares about the userspace api function name to determine whether it hangs or not :p
14:45karolherbst: RSpliet: https://gist.github.com/karolherbst/7affe9cc153716fda8c4
14:45RSpliet: imirkin: it's been ages since I've taken a look at that, but looking at it I'm surprised it relies so much on shaders
14:46karolherbst: RSpliet: compile like this: gcc pwr_read.c -L /home/karol/Dokumente/repos/envytools/build/nvhw/ -L /home/karol/Dokumente/repos/envytools/build/nva -lnva -lnvhw -lpciaccess -lpthread
14:46karolherbst: and run it under the blob full reclocked
14:46karolherbst: ohh wait
14:46karolherbst: it won't work
14:46karolherbst: you also have to adjust this path: https://gist.github.com/karolherbst/7affe9cc153716fda8c4#file-pwr_read-c-L466
14:47karolherbst: ahh well nvm, I could also try to read it out of the trace somehow ...
14:50karolherbst: RSpliet: I am sure if I think about it for a day and then wait two days, and after giving up the fourth day I shall have the answer on the fifth :)
14:50RSpliet: karolherbst: I don't think this card has an INA3221
14:50RSpliet: by the very least it's not listed in the VBIOS
14:50karolherbst: RSpliet: mhh this tool prints clocks too
14:50karolherbst: but I guess there is a better way
14:53karolherbst: meh, nv_init can somehow print the clocks
14:53karolherbst: no idea how though
14:54RSpliet: nvbios lists the clocks
14:55RSpliet: as taken from the VBIOS, but for most domains there's no last level PLL to reconfigure
14:55RSpliet: hence they're spot on
14:57RSpliet: hmm actually, looking at this VBIOS, that's not entirely true, most of the graphics-related domains seem to use a PLL... Kepler really changed a lot since Tesla :-P
14:58imirkin: RSpliet: there were also a number of changes between Riva TNT and Tesla
14:58imirkin: [about the same length of time]
15:00imirkin: kepler: 2012, tesla: 2006, geforce2: 2000 :)
15:00mooch: yeah, i'm currently trying to emulate the tnt
15:00imirkin: [ok, i went overboard with riva tnt]
15:01mooch: it's, quite frankly, obscenely complicated
15:01imirkin: mooch: it only gets harder
15:01imirkin: tnt doesn't even do T&L
15:01mooch: i know
15:02mooch: it terrifies me
15:02imirkin: nvidia might be releasing these faster than you can emulate them :p
15:03mooch: i only currently have a really shitty and somewhat inaccurate implementation of pfifo and all that
15:03mooch: and only the pio mode
15:03mooch: and they really are
15:41pmoreau: imirkin: The 0x01800000 envydis is complaining about, is the result of `code |= util_logbase2(typeSizeof(i->sType)) << 23;` in `nv50_ir_emit_nvc0.cpp:emitCVT()`.
15:42imirkin: pmoreau: i know
15:42pmoreau: (where `i->sType` == `TYPE_U64`)
15:42imirkin: i suspect that envydis just needs to be taught better :)
19:35jayhost: imirkin. It'll probably take me a month to understand decompilation but I'll get there
20:24imirkin: jayhost: well, you don't have to do it... but tbh i'm not working on it, so... your call
20:56jayhost: imirkin I'll for sure be working on it. It's fascinating stuff. No idea how long it will take.