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