00:23sooda_: yo, does anybody else than skeggsb know how the post-refactor nvif should be used? or has that been even decided yet? :P in particular, i'd like to write to a specific memory location in a gr context (per channel) but i'm not sure if this would be more suitable in gf100_fermi_mthd() (where i can't find how to get the associated chid) or in the fifo side that creates the ctx via engine_ctor...
00:30hakzsam: imirkin, those drv-queries need a debug build
00:31hakzsam: imirkin, for metric-issued_ipc, I bet you issued less than 1 isnt / cycles and as the hud doesn't still display floats, you see 0 ;)
00:31hakzsam: try with heave, valley or something
01:00pmoreau: gnurou, imirkin: +1 for renaming to NVIDIA conventions. I did it to some extent for LINEAR, TILED to PITCH, BLOCKLINEAR when integrating the EVO stuff
01:37skeggsb: sooda_: https://github.com/skeggsb/nouveau/commit/8abd3f9a2c52c34e5268c58ee11a06496b363524
01:37skeggsb: like that
02:25sooda_: skeggsb: well that's nice, thanks :D
02:28sooda_: still trying to wrap my head around this whole thing, it's nice but complex
03:54pmoreau: karolherbst: Could you please tell me again which regs you were after on my laptop?
03:55karolherbst: 0x02010c and 0x020074
03:56pmoreau: K, I'll run that right now
03:56karolherbst: maybe 20480 too
03:56pmoreau: Hum three of them… I might lack time for that then. :-
03:56karolherbst: or just all listed here: https://gist.github.com/karolherbst/1854da8068b510d4cc14 :D
03:57karolherbst: I am not interested in all of them directly though
03:57karolherbst: if 20480 is set, then the value
03:57karolherbst: the thresholds I only want to know if they are set
03:57karolherbst: status doesn't matter
03:58karolherbst: I want to understand what the blob does when these regs aren't set through the vbios script
03:58pmoreau: Would you like me to add the results as a comment to your gist or paste them here?
03:59karolherbst: it actually depends
03:59karolherbst: I am pretty sure the blob won't set most of the regs anyway
04:00karolherbst: and 20074 seems to be set to something stupif through the vbios
04:01karolherbst: pmoreau: well even your trace seems to indicate the values may be all empty on your nva0 card :/
04:01pmoreau: On Nouveau, G96: ..., ..., 6e, 67, ...,..., 7d, ...
04:02pmoreau: Nouveau still, MCP79: ..., ..., 87, 5d, ..., ..., ..., ...
04:02karolherbst: 87 :O
04:03karolherbst: that's 135°C
04:03karolherbst: I bet nouveau sets this value though
04:03pmoreau: That's the value reported by sensors as well (for emerg)
04:04karolherbst: yeah I know
04:04karolherbst: but usually nouveau doesn't touch the value when it's set I guess
04:04pmoreau: I can reboot on the blob to compare
04:04karolherbst: yep, would be nice
04:07pmoreau: NVIDIA, G96: 40000104, 6e, 60, ..., ..., 7d, ...
04:08pmoreau: NVIDIA, MCP79: 40000304, ..., 7d, 5e, ..., ..., ..., ...
04:08karolherbst: so the blob does set some values
04:08pmoreau: Oh BTW, I did run Nouveau with config=NvForcePost=1
04:08karolherbst: and it doesn't use the THRESHOLD_2 anymore, but 4
04:08karolherbst: doesn't matter actually
04:09karolherbst: I think ptherm just executes the script itself from the vbios
04:09pmoreau: Some more testing needed?
04:09karolherbst: don't think so
04:09karolherbst: mhh well maybe to activate the fsrm
04:10karolherbst: but not now anyway
04:10pmoreau: I don't want to burn my laptop! :-D
04:10karolherbst: forcetemp :p
04:10karolherbst: you could do one thing
04:10karolherbst: nvaforcetemp below the CRIT value, but above the THRESHOLDS
04:10karolherbst: check the status
04:10karolherbst: and check freq used in nvidia-settings
04:11karolherbst: with normal temp and forcedtemp
04:11pmoreau: Of all those regs? Or whcih which status do you mean?
04:11karolherbst: status is 201e0
04:11karolherbst: well first check the freq with nvidia-settings
04:11karolherbst: I only need this for one gpu anyway
04:12pmoreau: How does nvaforcetemp work?
04:12karolherbst: just specify the temperature you want to use in decimal
04:12karolherbst: 0 to restore
04:12karolherbst: you don't want to go above the CRIT value :D
04:13pmoreau: So something below 7d
04:13karolherbst: but above 5e
04:14karolherbst: this should cut the freq a bit :D
04:15pmoreau: graphics and processor were halved, memory stayed the same
04:15pmoreau: 201e0: ...
04:15karolherbst: okay, I figured
04:15karolherbst: tesla seems to use a different status reg
04:16karolherbst: but only halfed?
04:16karolherbst: which temp did you set?
04:16pmoreau: Ouch, on the MCP79: 125 -> 15, 250 -> 31!!!
04:16karolherbst: that's more like it
04:16pmoreau: still 201e0: ...
04:16karolherbst: yeah, I check the reg
04:16karolherbst: 0x20048 maybe
04:17pmoreau: Weird that it only halved on the G96
04:17karolherbst: mhh no
04:17karolherbst: it isn't
04:17karolherbst: the fsrm works with teo thresholds
04:17karolherbst: the first one halfs (also on my kepler
04:17karolherbst: the second one does more
04:17karolherbst: the formular on my kepler is: real_freq = set_freq / ((fsrm_div / 2) + 1)
04:18karolherbst: the first thresholds sets div to something between 0 and 7
04:18karolherbst: 2 currently
04:18karolherbst: the seond one sets it to something 8-f
04:18karolherbst: e currently
04:18pmoreau: On the MCP79, 20048: before ff, after 13800 (talking about the temp rise)
04:18karolherbst: e/2 + 1= 8
04:18karolherbst: so clock cut by 8
04:19karolherbst: cur_div = 8
04:19pmoreau: ff -> 11800 on my G96
04:19karolherbst: 250/8 = 31.25 so this seems to be right
04:20karolherbst: 11800: div=2
04:20karolherbst: so clock is halfed
04:20pmoreau: Nice! :-)
04:20karolherbst: so this seems to be right
04:20karolherbst: see the 1 and 3 from the CFG reg?
04:21karolherbst: this is the thing the fsrm is set to when the thresholds hit
04:21karolherbst: seems like on your cards there is only one threshold though then
04:21pmoreau: Oh ok
04:21karolherbst: so on tesla the formular is more like real_freq = set_freq/ fsrm_div
04:22karolherbst: 2 ^ fsrm_div actually
04:23pmoreau: Well, it still does the job pretty well
04:23karolherbst: one could argue about that
04:23karolherbst: half clock means 16% less power consumption on my gpu
04:23karolherbst: that's not _that_ much
04:23karolherbst: if you think about the situation the gpu is in
04:24pmoreau: So it only halfs the current frequency? Doesn't it also downclock to the lowest perlvl as well?
04:25pmoreau: Hum, maybe it doesn't make sense to half the frequency then if you downclock.
04:25karolherbst: setting the perlvl is the task of the driver
04:26karolherbst: there is a lower threshold which tells the driver to downclock (I bet ptherm sends an interrupt)
04:26karolherbst: but the driver does that
04:26karolherbst: the fsrm is a stupid thing, which just lowers the clock
04:26karolherbst: you can also have the fsrm active on highet clocks
04:27pmoreau: I guess NVIDIA computed that halving the clocks was enough to keep it under a certain temp no matter what (well, maybe not if mupuf is around with a hairdryer)
04:28RSpliet: fsrm is a safety mechanism to instantly protect cards that run hot, without relying on the driver to intervene
04:29RSpliet: so under high CPU load or more nasty cases, the hardware is still protected
04:29karolherbst: RSpliet: yeah, but then you don't just half the clock
04:29karolherbst: another thing is, the gpu will be kept at the threshold
04:29karolherbst: so the fsrm just prevents the gpu from getting hotter actually
04:30RSpliet: with the old cards (pstate, no cstate) it makes sense to have this as your throttling mechanism
04:30karolherbst: RSpliet: yeah, but a higher divider means less heat, a divider of 8 "just" means half power consumption on my gpu
04:30RSpliet: karolherbst: it's a last resort, the card shouldn't run this hot in the first place, and it might help prevent shutdown
04:30karolherbst: yeah I know
04:31karolherbst: but I wouldn't trust a divider of 2
04:31karolherbst: but there is the CRIT thresholds too
04:31RSpliet: I'd trust whatever NVIDIA is doing, they likely had some engineers doing the measurements
04:31karolherbst: and then the gpu just disables some stuff
04:32karolherbst: yeah as long as the crit thing is set to some reasonable value
04:32karolherbst: at least I know now that 125°C is the default value when we don't know anything else
04:32karolherbst: which is a good thing to know
04:33karolherbst: nouveau currently uses 135°C
05:01karolherbst: RSpliet: what fermi cards do you have?
05:17RSpliet: karolherbst: hahahahahahahahahahaha
05:17RSpliet: I have an NVC4, full stop
05:17RSpliet: and I 'll probably have to hand it in when I get home today
05:19karolherbst: I think I have a nvc1 here
05:23pmoreau: RSpliet: Come to think of it: I could plug my NVC0 on my work computer and get some stuff out of it if you need.
05:24pmoreau: imirkin: Same goes for you, I think there should be enough place in my work computer to plug the 960.
05:36RSpliet: pmoreau: thanks for the offer, we'll look into your NVC0 later
11:06hakzsam: imirkin, I should wait for the first coffee before answering :). Actually, metric-issued_ipc is a ratio (ie. inst_issued / active_cycles), so if inst_issued < active_cycles, you get 0...
11:06hakzsam: I should definitely send a patch to allow the HUD to display floats
11:06imirkin_: hakzsam: either way, it seemed less-than-interesting :)
11:07imirkin_: i would have expected a float
11:07imirkin_: but you can scale it up by 100 or something and make it a percent
11:08hakzsam: yeah, that's possible :)
11:08hakzsam: imirkin_, why did you test that metric btw?
11:08hakzsam: out of curiosity
11:08imirkin_: i forget... glxgears maybe?
11:09hakzsam: did you try the other ones?
11:09hakzsam: feel free to report me any weird results like that ;)
11:09imirkin_: it just said 0, i assumed it was broken and moved on
11:09imirkin_: i didn't *actually* care, i was just a bit curious
11:10hakzsam: okay, cool
11:10imirkin_: i know nouveau's not perfect, but 0 seemed a bit low :)
11:10hakzsam: I'll fix it then
11:13tflink: I apologize if this is a repeated question but I couldn't find anything after much searching - is basic 2d expected to work w/ 4.4rc5 and GM107 chips?
11:13tflink:isn't sure whether to file a bug or not
11:14imirkin_: tflink: can you define what "basic 2d" is?
11:15tflink: imirkin_: allows computer to boot and have native resolution
11:15imirkin_: tflink: yes, that is expected to work starting... 3.18 or so? i forget exactly
11:15imirkin_: tflink: but take a look at this bug, on the off chance you're misdiagnosing your issue: https://bugs.freedesktop.org/show_bug.cgi?id=93373
11:16tflink: that's easily possible - I haven't spent much time triaging nouveau stuff
11:17imirkin_: tflink: pastebin dmesg + xorg log
11:17tflink: that's going to be difficult, if I don't disable nouveau this machine doesn't boot
11:18imirkin_: perhaps we have different definitions of 'boot'
11:18imirkin_: a machine with non-working display still boots, you just can't see it on the monitor :)
11:18imirkin_: and logs still get generated
11:18tflink: it pivots from dracut to systemd but the cpu stalls with error messages and the machine is unresponsive
11:19tflink: can't switch VTs etc. but I'll look through the logs to see what all was recorded
11:19imirkin_: i want to see everything up to and including those error messages
11:19imirkin_: i believe systemd has a logging system which allows you to retrieve logs
11:19imirkin_: but i haven't the faintest idea how to operate it
11:20imirkin_: i just do 'less /var/log/messages' and everything i care about is right there
11:50RSpliet: karolherbst: I now have zero fermi cards
11:51RSpliet: that's nothing to smile about
11:51RSpliet: although it does force me to take a break, which is good
11:51karolherbst: how far are you by the way with the fermi stuff?
11:52imirkin_: RSpliet: wait, are you out of nv50 cards too?
11:52RSpliet: I think about 80%, but it looks like a tornado went past
11:52RSpliet: imirkin_: oh I have a mountain of those
11:52karolherbst: more core or more memory?
11:52RSpliet: just none that I can't reclock
11:52imirkin_: right, that's what i meant by "out of"
11:52RSpliet: I only focussed on mem
11:53karolherbst: RSpliet: well if you want you could take a look at the FSRM stuff on tesla cards
11:53tflink: imirkin_: syslog: http://paste.fedoraproject.org/301289/02088711/ xorg: http://paste.fedoraproject.org/301293/20916314
11:53RSpliet: karolherbst: no
11:53RSpliet: sorry, I'm going to take that break quite serious
11:53RSpliet: I'll probably get bored next week, when I have my NVA8 and NVAC
11:54RSpliet: (you've got trace + VBIOS, so don't know what else you need tbh)
11:54tflink: it looks like this'll be an interesting issue to track down - I was able to reboot without nomodeset 3 times before it failed again
11:54karolherbst: ohh I thought you meant a break like a month or more
11:54imirkin_: tflink: ok, so this is an optimus system?
11:55karolherbst: RSpliet: yeah well, finding the right temperature threshold is the bigger issue
11:55mupuf: karolherbst: what other issues are there?
11:55karolherbst: mupuf: well, I don't know actually :D
11:56mupuf:doesn't get why you are stuck on this :s
11:56karolherbst: mupuf: here is my first version for gf119 cards anyway: http://paste.fedoraproject.org/301289/02088711/
11:56tflink: imirkin_: I didn't think it was
11:56mupuf: but I don't want to hear until thursday, when I am in France
11:56karolherbst: too late
11:56karolherbst: no, on fermi and later I got it already
11:57karolherbst: ohh I have to check against too low temperatures too, meh
11:57imirkin_: tflink: try booting with nouveau.modeset=0
11:57tflink: imirkin_: but it is a laptop. i assumed not optimus because it's skylake and the graphics worked with 4.2
11:57imirkin_: that should disable just nouveau
11:57mupuf: what is this crash?
11:58imirkin_: looks like "nouveau 0000:01:00.0: Refused to change power state, currently in D3"
11:58imirkin_: which is then in turn not handled particularly well
11:58imirkin_: also, when tflink says "reboot" he really means "suspend/resume"
11:58karolherbst: imirkin_: I think the card is accessed while it is off anyway
11:59tflink: imirkin_: I do?
11:59karolherbst: there are quite a few issues in the trace :O
11:59imirkin_: tflink: those logs have suspend/resume cycles in them
11:59karolherbst: " x86/mm: Found insecure W+X mapping at address ffff880001c00000/0xffff880001c00000"
11:59karolherbst: "Info: mapping multiple BARs. Your kernel is fine."
11:59karolherbst: but I have no idea what they do anyway
12:00tflink: i was doing a reboot - it went from UEFI to grub to boot
12:00mupuf: karolherbst: right, so it is not related to your code
12:00mupuf: anyway, one more evening of studying!
12:00karolherbst: no :O
12:00imirkin_: tflink: are you doing hibernate perhaps?
12:00mupuf: but, before I forget, what cards would you need for 10 days?
12:00tflink: imirkin_: 'reboot' as root from the terminal
12:00mupuf: I want to solve the nvafakebios issue
12:01karolherbst: mupuf: mhh I have to remeber, ohh that was because of the unk50 and unk5c tables... so keplers
12:01imirkin_: tflink: well, your system logs indicate multiple suspend/resume cycles
12:01karolherbst: no sure anymore though
12:01mupuf: and have a look at the tk1 one again
12:01mupuf: hakzsam: what do you need?
12:02tflink: setting nouveau.modeset=0 gets me to the lightdm
12:02karolherbst: imirkin_: ohhh I think I know what is going on :/
12:03karolherbst: tflink: does this happen like after login?
12:03tflink: after login? i can't get to the point where i can login, the boot process hangs before the dm is started
12:03karolherbst: did you try nouveau.runpm=0 ?
12:03tflink: nope, will try
12:04karolherbst: imirkin_: libpcieaccess has an issue, where the nvidia card is woken up, when you init the library in your application
12:04karolherbst: like when you call glxinfo
12:04karolherbst: and there are some application which just call glxinfo and with bad timing, stuff just goes a bit crazy
12:06tflink: setting nouveau.runpm=0 also got me to the dm
12:06karolherbst: in fact in his log the card goes off and then later it is woken up
12:06karolherbst: and I am sure this is because of pcieaccess
12:07karolherbst: or Xorg enumarates over all gpus or whatever
12:08karolherbst: tflink: yeah well, now your nvidia gpu is always on, which is a problem :D
12:09tflink: it's better than not booting to the dm or 800x600 graphics :)
12:09tflink: karolherbst: do you know if there's a bug filed for the issue?
12:09karolherbst: not quite sure
12:09karolherbst: tflink: do you have a xorg.conf?
12:10karolherbst: if not create one under /etc/xorg.conf with this content: http://pastebin.com/RPm8FUmk
12:10karolherbst: and remove the runpm thing
12:10karolherbst: and see if that helps
12:10karolherbst: if that helps, you want to enable DRI3 for the intel ddx and tehn you can use prime offloading through dri3
12:13tflink: it's back to stalling before starting the dm
12:13karolherbst: it shouldn't really :/
12:14karolherbst: wrong path
12:14karolherbst: tflink: /etx/X11/xorg.conf
12:14karolherbst: wrong again
12:14karolherbst: now it is good
12:15karolherbst: yeah I know, it was wrong
12:15karolherbst: you can move the xorg.conf file into /etx/X11 though
12:15karolherbst: check if there is one already
12:18tflink: no dice, looks to be the same hang
12:19karolherbst: then your xlog please
12:19karolherbst: ohh wait
12:19karolherbst: it won't help
12:19karolherbst: I think this is some automatic behaviour of X then
12:21karolherbst: something while waking up the gpu just fails then :/
12:21tflink: in case it's useful: http://paste.fedoraproject.org/301312/14502108/
12:22karolherbst: ohh wait
12:22karolherbst: this is another issue
12:22karolherbst: huh wait
12:22karolherbst: tflink: what gpus do you have?
12:23RSpliet: tflink: why the <insert profanity here> do you have nomodeset in your kernel args?
12:24karolherbst: RSpliet: imirkin_ told him I think :p
12:24karolherbst: but yeah
12:24karolherbst: that should be go too :D
12:24karolherbst: tflink: remove nomodeset :D
12:24karolherbst: the intel ddx is very unhappy otherwise
12:25RSpliet: if you just want to disable the NVIDIA GPU, go for nouveau.modeset=0 instead
12:25karolherbst: tflink: and install the dummy Xorg module please :)
12:25tflink: RSpliet: because that was the only way I found could get booted to the point where i could login
12:25karolherbst: RSpliet: we are debugging some nouveau wakes up gpu => hang issue
12:26karolherbst: RSpliet: his kernel is stuck herE: https://github.com/karolherbst/nouveau/blob/master/drm/nouveau/nvkm/subdev/pmu/base.c#L202
12:27karolherbst: like when the card doesn't wake up the right way or something is messed up, nvkm_timer_read returns the same value
12:27karolherbst: and you can guess what that means ;)
12:27tflink: is there a better way to force basic video than nomodeset?
12:27karolherbst: tflink: remove nomodeset and reboot
12:27karolherbst: it should work
12:27tflink: I did
12:27karolherbst: then x log
12:27Dezponia: And I'm also here, for no reason right now, just saying hai
12:27RSpliet: tflink: if it's an optimus set-up, nouveau.modeset=0 is the way to go
12:27Dezponia: Soooo... hai
12:28Dezponia: RSpliet: Where were you from anyway?
12:28hakzsam: mupuf, a fermi please
12:29karolherbst: we _have_ to fix all those runpm issue at some point, they seem to pile up quite nice now :/
12:30tflink: RSpliet: in general, i use 'nomodeset' as a semi-generic way to force the most basic graphics when something's not working - is there a better general way?
12:31tflink: ^ xorg.log from last hung boot
12:31karolherbst: skeggsb: is there a reason why nvkm_msec is using the timer on the gpu? because this causes a lot of issues when the gpu is in a faulty state
12:31karolherbst: tflink: did you remove the xorg.conf?
12:31karolherbst: meh :/
12:31karolherbst: stupid xorg server
12:32karolherbst: tflink: you could try to add this to the xorg.conf file: http://pastebin.com/SZUvLNBA
12:32RSpliet: tflink: no there's no better general way, nouveau.modeset=0 is more specific rather, keeps the intel GPU running at full steam while still disabling nouveau. nomodeset effectively just disables the entire driver. Don't ask me about it's mechanics
12:33karolherbst: I don't understand why somebiody would want to use nvkm_timer_read when he just wants to wait 4 seconds for something
12:33karolherbst: why bother doing iommu request all over again just for a wait?
12:34tflink: karolherbst: that worked, i got to the dm
12:34karolherbst: tflink: can you also login?
12:35tflink: yes but the fans seem to be at 100% now
12:35karolherbst: yeah well :/
12:35tflink: there are worse things, just figured I would add it in case it was relevant
12:35karolherbst: maybe because the gpu is off and the EC doesn't like it
12:35karolherbst: who knows
12:36pmoreau: hakzsam: The offset for kernel inputs on Fermi+ is 0x20, right? And you put them in c0?
12:36karolherbst: tflink: does sensors show any high temperatures?
12:38hakzsam: pmoreau, yeah, c0 but I don't remember what is the offset
12:38pmoreau: Ok, then the offset is probably correct as well
12:39pmoreau: Need to figure out first why RA is crashing on Tesla, while it used to work and still works on Fermi.
12:40hakzsam: offset seems to be 0 actually
12:42pmoreau: Really? Hum… Where are the gridDim, offset & co supposed to go then? Other CB maybe?
12:42pmoreau: Not there yet, but I'll hopefully soon need those. :-)
12:47tflink: karolherbst: i ended up needing to reboot again and for some reason, that xorg.conf is no longer working - it always hangs before getting to the dm unless I turn off nouveau
12:48tflink: xorg log : http://paste.fedoraproject.org/301334/50212493
12:48karolherbst: yeah okay, I somehow now what the issue is, but not what is causing this
12:48hakzsam: pmoreau, those are accessible with $nctaidX, $gridid, $tidX special registers
12:49karolherbst: tflink: well then do like RSpliet said and add nouveau.nomodeset=1 and remove this xorg.conf file
12:50pmoreau: hakzsam: Oh true! Maybe not the workground offset thingy, but otherwise most of them should.
12:50hakzsam: pmoreau, yeah and we don't need to upload them with input parameters
12:50pmoreau: tflink: Yes, nouveau.modeset=0
12:50karolherbst: ohh right, my mistake :D
12:51hakzsam: pmoreau, on tesla some of those bits are uploaded to s
12:51hakzsam: 0x00:0x10 IIRC
12:51pmoreau: hakzsam: That I know ;-) I did got to run get_local_id() & co. on my laptop
12:52hakzsam: for tesla only right?
12:52hakzsam: that's a good start anyways :-)
12:52tflink: karolherbst: that gets me booted to the dm, is there a bug i can file/add to or more triage info needed?
12:52karolherbst: no idea to be honest
12:53pmoreau: hakzsam: The hello_world should work, I think, on Fermi+ now
12:53hakzsam: pmoreau, nice
12:53hakzsam: unfortunately I can't test since mesa/llvm seems to be a bit borken :)
12:53pmoreau: hakzsam: Just waiting for someone test O:-)
12:54pmoreau: Well, I might know how to solve it
12:54pmoreau: I have mine back up and running
12:54pmoreau: Thanks to karolherbst! :-)
12:56karolherbst: now it is broken for me, because I have to rebuild my entire system
12:56karolherbst: stupid gcc upgrade
12:56karolherbst: but 1000 package of 1400 already done
12:56pmoreau: It's not like you didn't know about it before upgrading! ;-)
12:56karolherbst: I wasn't aware of the consequences
12:56karolherbst: like chromium also doesn't work anmymore
12:57karolherbst: and I had to reboot
12:57pmoreau: Seems like fun!
12:57karolherbst: well "had"
12:57karolherbst: was trying to get by subwoofer working on my laptop
13:00pmoreau: imirkin_: I might need your help: RA now bails out on Tesla, on the hello_world example while the same code used to work a week or two ago. https://phabricator.pmoreau.org/P69
13:00pmoreau: (I did fix the constant thing by the way :-) )
13:01pmoreau: The generated code seems reasonnable to me
13:01imirkin_: don't you think a backtrace of when the segfault happens could be useful?
13:01pmoreau: Maybe O:-)
13:02pmoreau: Added as a comment to the paste
13:03imirkin_: ooh, code i just added
13:03imirkin_: something it hates in isShortRegOp()
13:04pmoreau: Well, insn is a null pointer…
13:06imirkin_: can you figure out what lval this is?
13:06imirkin_: and how it's getting an instruction-less use
13:06pmoreau: seems to be r0, of size 4, but TYPE_NONE
13:07imirkin_: what's it's defining op?
13:07pmoreau: No value set, so it doesn't look like it's the constant
13:08pmoreau: lval->getInsn() is null pointer
13:08imirkin_: that's unfortunate.
13:08imirkin_: but lval->defs.size() != 0?
13:08imirkin_: p lval->defs
13:09pmoreau: Yep, == 1
13:09imirkin_: i bet it's that stupid nop?
13:09imirkin_: you can add lval->getInsn() == null to the if (lval->defs.size() == 0)
13:10imirkin_: i don't even know why these values are still around
13:10imirkin_: but... wtvr
13:13pmoreau: imirkin_: Got a new exception further down (bt added to the paste), insn is NULL once again, same lval
13:14imirkin_: more code i added ;)
13:14imirkin_: add lval->getInsn() != null to the if above it
13:14pmoreau: Yep, did that, and it works now :-)
13:15pmoreau: And the produce code looks correct to envydis
13:15pmoreau: I don't know where that nop came from
13:16pmoreau: But it's probably not the cause for this troublesome reg, could it?
13:18pmoreau: imirkin_: The INFO_DBG macro is for feeding the glDebugCallback?
13:19imirkin_: there's no way to feed it from within the compiler, i never hooked it up
13:19imirkin_: in the rest of nouveau, you can use pipe_debug_message
21:22chillfan: what is the fsrm_kepler branch?
21:29chillfan: ah nvm will wait for karol to come back heh