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