02:23mupuf: karolherbst: hmm, I can review your patches, sure :)
02:23mupuf: This is sunday after all!
02:23mupuf: As for increasing the resolution, you will get it down at the cost of bandwidth
02:24mupuf: we need to configure it like the blob does. Do we have any proof they change the configuration?
02:24mupuf: if so, we need to read the parameters from the vbios
02:24mupuf: or maybe they are hardcoded
02:24mupuf: which would be possible
02:25pmoreau: `envydis -m g80 -V g84 -O cp -w` is the correct command to "translate" to a textual form the resulting binary from nouveau_compiler on a MCP79, right?
02:27mwk: pmoreau: nope
02:28mwk: -V mcp77 is correct
02:28pmoreau: Ok, thanks
02:28mwk: and -w assumes textual input like "0x12345678 0x9abcdef", use -i for actual binary input
02:28pmoreau: Looks like they report the same problem anyway. :-D
02:29mwk: yeah, they're identical if you don't use the new opcodes
02:29pmoreau: (I was giving a textual representation, but good to know about -i)
02:29mwk: you're debugging a compute shader, right?
02:29pmoreau: OpenCL kernel
02:29mwk: yeah, that'd be it
02:29pmoreau: Someone broke my hello_world example… :-/
02:31pmoreau: Updating Mesa again, let's see if it has been fixed.
02:32karolherbst: mupuf: well, the configuration is pretty trivial
02:32mupuf: karolherbst: yep, one reg right?
02:32karolherbst: mupuf: yeah, and trivial
02:32karolherbst: mupuf: you can let the sensor collect 128 sample value and store the avarage into the shunt/bus voltage regs
02:32karolherbst: and for 128 samples the ina219 needs 62ms or something
02:33karolherbst: also you can limit the bus max voltage to 16V (32V being deafult) and so on
02:33karolherbst: I will check how the blob configures the reg
02:33karolherbst: mupuf: I also played around with the calibration reg a bit, but somehow it's no reliable enough :/
02:33mupuf: well, lowering the max voltage is a good idea
02:34mupuf: yeah, never got anything out of it!
02:34karolherbst: I did
02:34karolherbst: but only for one of the three sensors on your nvc8
02:34karolherbst: but the value was right though
02:34mupuf: anythign useful*
02:34karolherbst: well you have to still calculate the stuff together :/
02:35karolherbst: I found something real nice!
02:35karolherbst: mupuf: https://github.com/adafruit/Adafruit_INA219
02:35karolherbst: but the ina219 docs are also usefull for calibration, it's just a mess :/
02:36mupuf: Ah ah, TI has the best doc out there :D
02:36mupuf: there is much worse than their doc
02:36karolherbst: yeah , true
02:37karolherbst: but the ina209 is a monster
02:37karolherbst: I would really like to know where this one is used
02:37karolherbst: most likely some high end quadro cards
02:40karolherbst: config 0x277f on my ina3221
02:40karolherbst: 1024 samples per value
02:40karolherbst: orr wait
02:42karolherbst: 4.156 ms conversion time (1.1ms default)
02:42karolherbst: 8.244 ms bus conversion time (1.1 ms default)
02:43karolherbst: the former was for the shunt obviously
02:43karolherbst: and 1024 samples (1 being default)
02:43karolherbst: and only the used channel is activated
02:43karolherbst: by deafult all are
02:44karolherbst: okay, so that means the blob just maxes out the samples collected
02:44karolherbst: and turns of channels not being used
02:45karolherbst: conversion time means how long does it take until the value gets updated, right?
02:53mupuf: Well, since they are polling at 10 Hz, you can definitely increase the conversion time to a very high value
02:53mupuf: but ... we need to check if it is a synchronous operation or not
02:54karolherbst: it is
02:54mupuf: as in, does it do continuous sampling and we just poll the last value?
02:54karolherbst: it isn't
02:54karolherbst: depends actually
02:54mupuf: or, is it a one shot thingy
02:54karolherbst: you can configure it
02:54mupuf: not sure you can do the latter on an i2c bus
02:54karolherbst: there is a trigger and a continous mode
02:54karolherbst: but there is also a ready bit
02:54mupuf: ok, make sure it is on the continious mode then :)
02:54mupuf: oh, that's for the trigger mode then
02:54karolherbst: not for the ina3221 though, there is no ready bit
02:55karolherbst: by the default they are configured to shunt/bus continous
02:56karolherbst: there is also a summed shunt/vbus reg on the ina3221, so you can get the values of all channels at the same time
02:57karolherbst: ahh on the ina3221 the ready bit is in another reg
02:57karolherbst: "CVRF: Conversion Ready Flag" and
02:57karolherbst: mhh oh, it's for every value
03:04karolherbst: ohh, I read the stuff out wrongly :/
03:08karolherbst: continous, 140µs conversion time (minimal), 1024 samples,
04:17gndgnd: hi :)
04:19gndgnd: this is better ..
04:19gndgnd: i wanted to ask some questions about optimus laptops and linux drivers
04:20gndgnd: i have a nvidia 940M gpu and i7 skylake cpu. i was trying to use bumblebee with oficial ubuntu drivers but not impressed by the speed
04:21gndgnd: im working a lot with realtime opengl stuffs so i would like to maximize my power somehow
04:24pmoreau: gndgnd: There is no reclocking support for Maxwell cards on Nouveau
04:31gndgnd: pmoreau: are you speaking about neouveau-1.0.12 ?
04:32gndgnd: *nouveau sry
04:32pmoreau: Well, Nouveau is made of multiple parts: a kernel module, a Mesa backend, and a X driver.
04:33pmoreau: The kernel module is the one dealing with reclocking, and regardless of its version, it has no support for reclocking on Maxwell.
05:01gndgnd: pmoreau: do i understand it correctly that reclocking is about energy saving ?
05:02gndgnd: right now im more interested in computing power
05:04pmoreau: gndgnd: Both: using lower clocks consume less energy, but you have less computing power, while higher clocks do the opposite.
05:04pmoreau: Since Fermi or Kepler (I don't remember), NVIDIA cards boot on the lowest clock
05:05pmoreau: So in your case, having reclocking would allow you to switch to higher clocks.
05:14gndgnd: pmoreau: oh i see.. is there any roadmap for maxwell gpu support ?
05:15gndgnd: and do you have any suggestions what would be the most fast configuration ?
05:34pmoreau: gndgnd: Given that some of the firmwares for Maxwell gen 2 were released, there might be more interest in getting those to work, but otherwise there is no roadmap
05:34pmoreau: Use the binary driver
05:37gndgnd: pmoreau: thank you! thats kinda sad.. anyway sorry for pestering you with questions :)
05:38pmoreau: No problem
06:16karolherbst: mhh 940m is 1gen maxwell though
06:16karolherbst: mupuf: there?
06:18karolherbst: gndgnd: could you give me your vbios? Maybe I take a look at the maxwell reclocking situation, I am kind of the impression that it _may_ work
06:20karolherbst: mhh still only the GM107 hooked up though
06:47karolherbst: mupuf: I would need your gm107 and gm206 again :) the gm107 just for reclocking purposes
06:53karolherbst: gndgnd: I will take a look at first gen maxwell today (hopefully), maybe you can reclock. Anyway, why aren't you happy with bumblebee performance?
06:54karolherbst: the 940M isn't _that_ much faster than the high end intel gpus, and there is additional pcie overhead, but besides that stuff should be faster (except glxgears and other high fps "benchmarks")
06:55karolherbst: gndgnd: i7 skylake means intel hd 530?
06:57karolherbst: pmoreau: holy moly, the intel HDs have a memory bandwith of around 32GB/s, the 940M has only 16...
06:57pmoreau: Oh wow!
06:57karolherbst: the 940 has though doubled computing power
06:58karolherbst: it's so sad :D
07:00karolherbst: ohh right, since skylake there is also DDR4
07:00karolherbst: but I guess on moible it is still DDR3 only
07:01karolherbst: ohh no, actually there are these slots which can have DDR3 or DDR4 sodimms
07:01huehner: karolherbst: if you need anything readout or testing of my gm206 let me know
07:02karolherbst: huehner: I don't think anybody _ever_ tested out reclocking on those
07:02huehner: or just bios
07:02karolherbst: thing is, I have no idea how that will work on those actually
07:02huehner: as i.e. nvbios thinks it has ddr2
07:03karolherbst: huehner: well you can give us your vbios though
07:04karolherbst: pmoreau: do you have access to your gm200?
07:04pmoreau: No, I'm home right now
07:04karolherbst: ohh wait, it's a gm200..
07:05karolherbst: I need 1gen maxwells :D
07:05karolherbst: I am pretty sure they get reclocked like keplers, because I remembering getting some maxwell card reclocked on reator
07:05karolherbst: I was playing around with the pcie stuff there
07:05karolherbst: and maybe with my volting fixes it actually works
07:15karolherbst: pmoreau: ohh by the way, did you find some time to verify the mmiotrace fix? or if you could reproduce the error?
07:16pmoreau: I was still hitting issues compiling the blob…
07:17karolherbst: against 4.5?
07:17pmoreau: Even 4.4
07:17karolherbst: mhh odd
07:17karolherbst: which driver version?
07:17pmoreau: I'll try adding the patch to the kernel package, that way I can use the stock NVIDIA driver
07:17pmoreau: 340.96 IIRC
07:17karolherbst: ohh that's too old for 4.4
07:18karolherbst: you would need a patch
07:18karolherbst: _much_ too old
07:18karolherbst: I think 4.3 would work though with the latest 340 release
07:18pmoreau: It's okay, if I use the packages from Arch it works
07:19karolherbst: if nvidia don't compiler: either older linux or newer nvidia drivers ;)
07:19pmoreau: Can't use newer driver: I need Tesla support ;-)
07:19karolherbst: ahh right :D
07:20karolherbst: arch uses a patch by the way
07:20karolherbst: I think
07:21pmoreau: Could be
07:24pmoreau: Where is the latest version of the patch please?
07:26karolherbst: the mmiotrace patch?
07:26pmoreau: I'll start a kernel compilation while I do some home cleaning stuff
07:26karolherbst: but verify that it still doesn't work without the patch :)
07:26karolherbst: and another thing
07:27karolherbst: do you see something like "using GB pages for direct mapping" somewhere in the top of dmesg?
07:27karolherbst: it's after the mtrr stuff
07:28pmoreau: I'll have a try once the compilation finishes
07:29karolherbst: well you should see that with your current kernel as well
07:29mupuf: karolherbst: I can plug a gm right now
07:29karolherbst: or maybe not
07:29mupuf: which one do you want?
07:29mupuf: about to leave for a bit
07:29karolherbst: mupuf: mhh gm206 first
07:29mupuf: turn off reator first then
07:29karolherbst: but if its possible also the gm10x one :D
07:29karolherbst: just turned it on to check the mapping stuff
07:29mupuf: ok, will plug both
07:30pmoreau: mupuf: +1 for the gm10x :-) I could try my compute patches on it
07:31mupuf: ok, both are plugged
07:31mupuf: karolherbst: please make sure they both work
07:31karolherbst: both are at least in lspci :)
07:32karolherbst: mupuf: on reator you don't get 1G direct mappings by the way
07:32karolherbst: maybe that's why mmiotraceing still works there or something
07:38mupuf: karolherbst: sehr gut
07:38mupuf: will be back in a few hours and I will review yiur code
07:39karolherbst: there is still no hwmon stuff for the 2gen maxwell, what do I do wrong :/
07:39mupuf: one thing though, check if you handle the different ways the vbios could be lying : No i2c chip, wrong rail, etc..
07:39mupuf: karolherbst: told you, the chip is probably not accessible
07:39karolherbst: mupuf: on stefans gm206 it worked
07:39mupuf: read gnurou's email about secure boot
07:40karolherbst: most likely something is odd
07:40karolherbst: maybe the gr firmware is actually required otherwise nouveau won't build all the subdevs or something
07:41mupuf: why would stefan's work then?
07:42karolherbst: I think he has the firmware
07:42karolherbst: ohh wait
07:42karolherbst: the iccsense ctor is called
07:42karolherbst: and it doesn't fail because of no i2c bus
07:49karolherbst: ohh nice, bios parsing issue
07:52karolherbst: and maybe I should finish the rebase ..
07:54karolherbst: nice :D
08:00karolherbst: mupuf: https://gist.github.com/karolherbst/645ce5ff67bc118f4b2f
08:01karolherbst: mupuf: and after "nvapoke -c1 0x20200 27722455": power1: 7.99 W
08:09karolherbst: core reclocking seems to work on gen1 maxwell
08:10karolherbst: and the pmu is funny
08:13karolherbst: skeggsb: I get "pmu: \xffffffffNTR 52544eff 00000000 00000001 00000000" on a gm107 gpu any idea?
08:14karolherbst: so memory reclokcing won't work because the pmu doesn't do its job...
08:15karolherbst: something is odd
08:15karolherbst: really odd
08:17karolherbst: "AC: core 1240 MHz memory 810 MHz" :)
08:18pmoreau: What was the value before?
08:19karolherbst: AC: core 405 MHz memory 810 MHz
08:20pmoreau: Small little bump for core. :-D
08:20karolherbst: hm "ram->func->calc" isn't set
08:21karolherbst: well the pmu is also messed up for some reasons I don't understand
08:21karolherbst: the pmu counter regs are also not working
08:23karolherbst: actually quite odd
08:24pmoreau: I'll never understand the fans on my laptop: CPU temp is 95~100, crit temp is set at 105, but the fans are only 2/3 of their capacity… --"
08:24karolherbst: well this gives a 25% perf icnrease in glxspheres64
08:25karolherbst: pmoreau: only 2/3 at which temperature?
08:25karolherbst: EC controlled=
08:25pmoreau: Dunno. How to check?
08:26karolherbst: no idea :D
08:27karolherbst: maybe you have the magic Fn+1 key?
08:32vita_cell: "AC: core 1240 MHz with maxwell?
08:32vita_cell: wow, congratulations!!!
08:34karolherbst: yeah, but that doesn't mean anything
08:34karolherbst: without proper memory speed it is worthless
08:35vita_cell: Yes I know this, when I tested gtx650 before memory reclock
08:35vita_cell: full memory reclock does more that core reclock
08:52gndgnd: karolherbst: was afk. I have a asus ux303ub - i7 6500u cpu + 2gb nvidia geforce 940m
08:53karolherbst: gndgnd: k, then intel hd 520
08:53karolherbst: gndgnd: but where is the nvidia gpu not fast enough to beat the intel one?
08:54gndgnd: hw do i check vbios for you ? sry :)
09:07karolherbst: gndgnd: well I think it may be okay, but in envytools there is a tool called nvagetbios
09:12gndgnd: karolherbst: im already compiling vbtracetool, as per nouveau website, is that ok
09:13karolherbst: never used it
09:14karolherbst: and I think its too old actually
09:14gndgnd: lal it output just "eh ?" :D
09:14gndgnd: gonna try envytools
09:14karolherbst: mupuf: with my voltage fixes: 84% => 90% for your maxwell :/
09:18gndgnd: karolherbst: i tried running unigine on various nvidia-xxx drivers + glmark2. unigine doesnt work properly on i915. glmark gave me ~204 / ~214fps via optirun. when i tried to run it on Intel i got ~2000 with Mesa DRI
09:18karolherbst: everything above 100 fps on full hd will get bad perf
09:18karolherbst: it's just the way it is
09:19gndgnd: what would be the best way how to test different drivers on my hw then ?
09:19karolherbst: to use some real benchmark
09:19karolherbst: or actually games
09:20gndgnd: like PTS ?
09:20karolherbst: it's a mess
09:20karolherbst: it won't work on dual gpu setups
09:20karolherbst: and I said _real_ benchmark
09:20karolherbst: like unigine :D
09:21gndgnd: i noticed some fluffy donut benchmark, is it real ? ;)
09:22karolherbst: ohh furmark
09:22karolherbst: furmark doesn't have high fps at least
09:22karolherbst: and it does draw a lot of power from the nvidia gpu
09:22karolherbst: so the gpu will heat up real fast
09:23karolherbst: and intel sucks with it
09:23karolherbst: gputest pixmark_piano is an excellent benchmark to check core performance
09:23karolherbst: there you should get a decent speedup
09:23karolherbst: because intel sucks there even more
09:24karolherbst: you should be happy if you get more than 10 fps with intel :D
09:24karolherbst: mupuf: odd, nvidia sets the vltage higher than the entries max values :/
09:27gndgnd: karolherbst: thx. here is the vbios, but both extraction methods were complaining: https://gnd.multiplace.sk/vbios.tar
09:27gndgnd: if you use wget u might want to --no-trust-certificate
09:27gndgnd: its from Let's Encrypt tho ..
09:29karolherbst: odd, both vbios files aren't good
09:33gndgnd: "Attempt to extract the vbios from card 0 (nv118) using PRAMIN.
09:33gndgnd: Invalid signature(0x55aa). "
09:34gndgnd: also with PROM
09:34karolherbst: mhh no idea what's wrong :/
09:34karolherbst: is the nvidia module loaded and X running?
09:34karolherbst: and with X I mean bumblebee X
09:35karolherbst: I never got a vbios from a 2gen maxwell card, so maybe this is required
09:36gndgnd: no it is not ..
09:37gndgnd: one sec ill reconfigure
09:43imirkin: hakzsam: in hindsight, i think SELP should have stayed a non-cmp instruction. the whole setCond thing is unnecessary, just the not modifier should be enough. getting rid of that i->cc stuff would have sufficed =/
09:43imirkin: hakzsam: what do you think?
09:44gndgnd: karolherbst: get the same.
09:44gndgnd: installed bumblebee and everything, with nvidia-361 from graphics-driver-team ppa
09:45karolherbst: gndgnd: optirun nvagetbios
09:45karolherbst: imirkin: is there anything special for getting 2gen maxwell vbios?
09:45gndgnd: karolherbst: nope, still the invalid signature
09:46karolherbst: gndgnd: using prom?
09:46gndgnd: both pramin/prom
09:47gndgnd: also tried to rum glmark2 via optirun and extract in a new shell
09:47karolherbst: no idea then
09:47karolherbst: it is posible somehow, but I don't know how
09:47imirkin: gndgnd: laptop?
09:48imirkin: if so, your vbios is in acpi, not anywhere that nvagetbios can get to
09:48karolherbst: ohh right, I forgot about that acpi stuff
09:48gndgnd: imirkin: yes, asus ux303ub
09:49gndgnd: i can try to extract it in windows with nvflash
09:50hakzsam: imirkin, I'll have a look
09:50imirkin: gndgnd: you have a GM108?
09:50hakzsam: imirkin, you are probable right :)
09:51imirkin: gndgnd: if so you might benefit from a patch in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=89558
09:51imirkin: gndgnd: however i skimmed the history, and if you want computational perf, nouveau's not the place to get it
09:51gndgnd: imirkin: nvagetbios says its nv118
09:52imirkin: nv118 = GM108. you would find out similar info from lspci -nn -d 10de:
09:52gndgnd: imirkin: yes thats the bug i also encountered today (among many others)
09:53imirkin: gndgnd: well, it's not a bug... it's a plain lack of support. no one has taken the time to go over the golden settings to see if they're any different from GM107
09:53gndgnd: imirkin: i wanted to try nouveau with PRIME like here: https://wiki.archlinux.org/index.php/PRIME
09:56hakzsam: imirkin, http://docs.nvidia.com/cuda/parallel-thread-execution/#comparison-and-selection-instructions-selp
09:56hakzsam: imirkin, well SELP is very close to SLCT...
09:57hakzsam: imirkin, make SELP a cmp insn is not so crazy in my opinion
09:57hakzsam: imirkin, and SLCT is already a cmp insn
09:59imirkin: SLCT has funny ops though
09:59imirkin: like "lt"
09:59imirkin: it actually looks at the value
09:59imirkin: whereas SELP is not or not-not :)
09:59imirkin: oh interesting. SLCT is >= 0
09:59imirkin: but in the nouveau isa it can also be other things afaik
10:00imirkin: and there's logic for flipping it around
10:00imirkin: but it's still borderline
10:00imirkin: gndgnd: apply the last patch in that bug, should get your GPU going. expect perf to suck horribly though.
10:00imirkin: gndgnd: but on the bright side, power consumption will be low :)
10:01hakzsam: imirkin, if you really want, I can definitely revert that change :)
10:01imirkin: it's just that there are now two ways of doing the same thing
10:01imirkin: the modifier, and the cnd
10:01imirkin: which is redundant
10:07gndgnd: karolherbst: tried to extract the bios in win, both nvflash and gpuz fail
10:07gndgnd: weird weird weird
10:26hakzsam: imirkin, what about this http://hastebin.com/citupoziro ?
10:27hakzsam: I need to do the same changes for gk110 though
10:27imirkin: hakzsam: i->cc == CC_NOT_P
10:28imirkin: nuke that
10:28imirkin: that was wrong in the first place
10:28hakzsam: except that, does this look good to you?
10:29imirkin: + fixing gk110, yes.
10:30imirkin: probably should double-check that it works :)
10:30hakzsam: imirkin, http://hastebin.com/mejogacuqi
10:30hakzsam: it works :à
10:33pmoreau: imirkin: How do you setup a phi instruction in NV50 IR? I found `phi = new_Instruction(this, OP_PHI, typeOfSize(lval->reg.size));` in the code, and it later sets the def and srcs. So far so good, but do you also specify in which BB the srcs are defined?
10:33imirkin: hakzsam: errr... this was always wrong, but
10:33imirkin: bld.getSSA(4, FILE_ADDRESS)
10:34imirkin: pmoreau: that part of nv50 ir sucks =/
10:34imirkin: pmoreau: the phi node source order is the order of the incoming edges in the cfg to that bb
10:35imirkin: yeah, esp when you want to futz with the cfg :)
10:35hakzsam: imirkin, it's the dst reg what's the problem?
10:35pmoreau: I do get the various BBs from the SPIR-V OpPhi node (https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#OpPhi), but maybe not in the correct order
10:36imirkin: hakzsam: sure... why FILE_ADDRESS??
10:36hakzsam: imirkin, oops, should be FILE_GPR I guess
10:36imirkin: pmoreau: that approach won't work - a bunch of the lowering is pre-ssa
10:37imirkin: hakzsam: right, you can just do bld.getSSA()
10:38pmoreau: imirkin: My current approach is: insert phi nodes, and then add a out-of-SSA pass before giving the program back to the passes
10:39imirkin: pmoreau: ah ok. heh.
10:40hakzsam: imirkin, patch sent
10:43imirkin: hakzsam: cool thanks
10:54imirkin: hakzsam: errr... where? i don't see it...
10:54hakzsam: imirkin, as usual?
10:55imirkin: perhaps mesa-dev needs kicking?
10:55hakzsam: oh right
10:55hakzsam: I sent a bunch of patches to mesa-dev today
10:55hakzsam: but I can't see any of them
10:56imirkin: explains why the ML was so quiet :)
10:57hakzsam: yes, it's probably buggy :)
10:59karolherbst: can anybody who has my power sensor stuff running check if setting 20200 to 0x......55 (mask 0xff) help with lowering power consumption?
11:00pmoreau: I was continuously thinking that offlineimap had crashed, explaining why I wasn't getting any mail in my dev mailbox
11:00karolherbst: I think this only works since fermi, but so does my power stuff
11:05pmoreau: imirkin: Oh, I don't really care about the order in which the BBs are given by SPIR-V OpPhi: I'll be doing my own pass anyway before the "regular" passes take control, so I can hack whatever I need. :-)
11:10karolherbst: imirkin: do you want to merge the PostRADCE pass for 11.2 or would it be too late for that?
11:10karolherbst: or do you rather want to analyze why that pass changes stuff?
11:11karolherbst: well I could also check that actually
11:24AndrewR: Hello. I tried to mmiotrace old fglrx (constantly fogot how to write its name properly) for rs600/Intel CPU integrated GPU . I was surprized by two things - small trace file sizes - like just 7-8 mb uncompressed for fluxbox + gears, and also by big amount of UNKNOWN entries, like for 1/3 of file. (tracing was done using old mmiotrace from kernel 188.8.131.52). Is this UNKNOWN part means big problems in decoding later?
11:54blaaa2: is it (theoretically) possible to use 30-bits color output with non-quadro hardware?
13:00mupuf: karolherbst: nice!
13:01mupuf: Yeah, reclocking works quite well on gm1xx, I tried that after xdc this year
13:03imirkin: blaaa2: not sure that anyone's tried 30-bit color output at all with nouveau...
13:18pmoreau: karolherbst: Sorry, I won't have time to test tonight. However, the patched kernel is ready to install, so I could have a try tomorrow early morning, or in the afternoon.
13:32karolherbst: pmoreau: good
13:32karolherbst: mupuf: yeah, except memory :/
13:32karolherbst: mupuf: thanks for looking over the code
13:36karolherbst: mupuf: nvkm_iccsense_read_all()? :D
13:37karolherbst: mupuf: actually the therm patch is required for gm20x, because there is some therm stuff missing
13:43mupuf: karolherbst: nvkm_iccsense_read_all sounds good
13:43mupuf: what is missing?
13:50karolherbst: mupuf: no idea, but what I put in the gist is all what I get
13:50karolherbst: maybe some of the attribute stuff or maybe something stupid
13:51mupuf: i;ll check later :)
13:54karolherbst: you have no idea which gpus might have an ina209, right?
13:57mupuf: no idea if there are none in the vbios repo
13:58karolherbst: yeah I know
13:58karolherbst: there is none
14:02karolherbst: mupuf: any idea how we can check if the extdev is really there?
14:45karolherbst: mhh "gr: GPC0/TPC0/MP trap: global 00000000  warp 14000a"
14:51hakzsam: karolherbst, kepler?
14:52hakzsam: what did you do?
14:52karolherbst: I played a game
14:52karolherbst: then it just happened
14:53hakzsam: are you able to reproduce the issue?
14:53karolherbst: no clue
14:54karolherbst: it ran fine for over an hour though once
14:54karolherbst: it would be nice to track down these unstabilities though :/
14:54karolherbst: it just occurs randomly and then meh :/
14:55hakzsam: yeah, we should
14:57karolherbst: mhh another hang
14:57karolherbst: "gr: TRAP ch 2"
14:58karolherbst: any idea how to debug this?
14:58karolherbst: running mmt and hope for the best?
15:00hakzsam: try to reproduce the issue and use apitrace
15:02hakzsam: imirkin_, I need to RE ld lock/st unlock on gk110... not the same as gk104
15:02hakzsam: 00000198: 001ffc06 77600000 C $r1 0x0 $r0 $r0 ??? [unknown: 00000000 77600000] [unknown instruction]
15:02hakzsam: and to update envydis :-)
15:06karolherbst: it happens pretty often now
15:06karolherbst: gr: GPC1/TPC1/MP trap: global 00000000  warp c000a 
15:06karolherbst: gr: GPC2/TPC1/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 160009 [INVALID_OPCODE]
15:07hakzsam: invalid opcode?
15:07hakzsam: should be easy to track down this one
15:07hakzsam: if you extract the shader
15:07karolherbst: so I do an apitrace until it hangs
15:07karolherbst: and then I check what happened
15:26hakzsam: imirkin_, btw, bar is totally bogus from envydis on gk110, I'll fix it
15:31karolherbst: k, got a hit while apitracing :)
15:33karolherbst: odd, the replay looks differently :D
15:33karolherbst: "157298: warning: error: fragment shader input `oT3' has no matching output in the previous stage" :/
15:48karolherbst: hakzsam: mhhh, glretrace just deadlocked :/
16:33diegoviola: can you guys help me to fix a network driver on linux :(
16:33diegoviola: it breaks my suspend/resume
16:33diegoviola: I think it's something to do with the registers or something