00:44koz_: karolherbst: Seems the issue came from my libdrm not being right.
00:44koz_: Reinstalling that seemed to fix it.
01:01karolherbst: koz_: ahh nice
01:39karolherbst: mupuf: maybe we should just drop those cstates the gpu can't reach at all
01:40karolherbst: if they already require a voltage higher than the max state in the vbios, there is no way this cstate can be supported at all
01:46karolherbst: who had a gpu which got a lot hotter with nouveau than with nvidia?
01:47karolherbst: Tom^: are you there?
01:52karolherbst: pmoreau: I need you tesla cards :D
01:57pmoreau: karolherbst: They are mine! My precious Tesla cards! :-D
01:57RSpliet: karolherbst: order your own! http://www.amazon.co.uk/NVIDIA-Tesla-K80-computing-processor/dp/B00S1K54DY/ref=sr_1_1?ie=UTF8&qid=1448272660&sr=8-1&keywords=nvidia+tesla
01:57karolherbst: pmoreau: would you mind testing a brach of mine and see if reclocking still works?
01:58karolherbst: RSpliet: meh tesla, :p
01:58pmoreau: karolherbst: If you broke reclocking, I'm going to be really angry! :-p
01:58karolherbst: pmoreau: that's why I want to let them be tested _before_ let them be added to the main tree :p
01:59karolherbst: pmoreau: kepler_voltage branch on my tree
01:59pmoreau: karolherbst: Do you need that right now or can it wait this afternoon/evening?
01:59karolherbst: 4.3 compatible, based on latest main tree
01:59karolherbst: pmoreau: it can wait. I will still send out to the ML so that other can test as well
02:00pmoreau: Ok, great! I have to work on some urgent tasks right now, so… bbl :-)
02:00karolherbst: yesterday was a good day
02:01karolherbst: I finally understood how boosting works on keplers :D
02:02pmoreau: And BTW, just saw the messages about mkinitcpio in the logs: I never rebuilt the initramfs before using by newly built nouveau module, and it still get used. Or maybe it's because I modprobe it manually?
02:02karolherbst: pmoreau: yes, because of manual modprobe
02:03karolherbst: pmoreau: if you boot with a initramfs, the initramfs is your "/"
02:03pmoreau: Ok, so then I don't know how to do it.
02:03karolherbst: you don't have disc access yet
02:03karolherbst: so all you see is only the initramfs
02:03karolherbst: and because you want to have fancy graphics really early, the modules have to be on the initramfs ;)
02:04pmoreau: Have to go now though, see you! :-)
02:08karolherbst: RSpliet: ohh if you want, can you also look over the patches?
02:08karolherbst: these are the types where you want to have three okays from different people before you merge them :D
03:44pmoreau: karolherbst, Tom^: What are your needs exactly? This ISO was meant to quickly test the latest version of Nouveau without having to build your own kernel, so that people reporting bugs could try on the latest version easily.
03:45pmoreau: It is not meant to be a Nouveau developer ISO!
03:45pmoreau: (It does have piglit installed if you want to run tests on the latest version, as well, but that's it)
03:52karolherbst: pmoreau: testing out a branch of mine
03:53karolherbst: pmoreau: maybe it would make sense to also include stuff like that, kernel headers would be enough, because all the other stuff can be fetched easily
03:54RSpliet: pmoreau: do you have a computer set up that boots that ISO over the network daily and runs the piglit tests to spot regressions? :-D
04:25karolherbst: imirkin_: the game (because it uses mono) doesn't work with the nouveua valgrind, but with my system one :/
06:12pmoreau: RSpliet: Not yet, but I definitely plan to setup a Reator and have it run daily piglit tests on it, when none of you is using it.
06:14pmoreau: karolherbst: I could have a look at adding kernel headers to it. But you might end up running into a "no more space" error if you try to compile / install to much stuff
06:15pmoreau: Another user reported running into that case when installing more than 50MB of packages IIRC.
06:15karolherbst: pmoreau: but that depends on the used RAM
06:17pmoreau: Could be. I don't have much knowledge about how it works, and given that no one was using it, never thought that it should acquire that knowledge.
06:22mupuf: pmoreau: right, I need to set it up at least the tk1
06:22mupuf: I still don't know how to handle this though :s
06:22mupuf: I guess I need to check if there is a user
06:22mupuf: if there isn't, disable ssh and start tests
06:23mupuf: or displaying a big warning to incoming users, along with the command to re-schedule
06:34pmoreau: Could be one solution
06:35hakzsam: mupuf, an other way might to be to allow users/developers to automatically send a piglit report to a remote server for their cards, update the HTML report and make it available somewhere :)
06:38mupuf: I fail to see how it is addressing the same problem
06:39hakzsam: it is for sharing our piglit result files
06:39mupuf: right, we were talking about having a machine that can automatically start doing stuff
06:39hakzsam: not exactly what you talked about, but I have this idea since a long time :)
06:39hakzsam: sure I know
06:40mupuf: Well, I am fine with creating an account for uploading piglit reports to my server and generating the html file there
06:42hakzsam: we could also use a git repository to store previous piglit reports
06:43hakzsam: well, we need to think more about that, but this could be definitely an improvement ;)
06:43mupuf: sounds actually like a good idea
06:48karolherbst: mupuf: do you have any idea how to get the "base" clocks from the vbios? If there are in the PM_Mode table, then some of the clock domains have to be multiplied by 2 to fit with the cstates :/
06:48karolherbst: and even then they only make partly sense
06:48mupuf: nope, no idea :s
06:50karolherbst: for Tom^ the "shader" clock was the one though
06:50karolherbst: and that it is 810MHz for me also makes some sense
06:51karolherbst: Tom^: ohh by the way, what was the idle clock with the nvidia driver with max perf preferred?
07:21karolherbst: mupuf: what do you think about this version of the patch? https://github.com/karolherbst/nouveau/commit/a2d3c9bd8988118acfd2f569c90336651aeb0297
07:21mupuf: can't check now
07:40Tom^: karolherbst: on windows?
07:45Tom^: karolherbst: on windows it is 980mhz
07:45Tom^: core, and memory is 1750
07:47karolherbst: Tom^: so idle, max perf prefered, 980MHz?
07:51Tom^: karolherbst: idle max perf on linux 980mhz core but 7000 mhz mem.
07:52karolherbst: it may be, that the blob idles at base - 105MHz
08:11prg: and another lockup. was watching a video while starting some game, https://paste.debian.net/335381/
08:11prg: anything i can do about that?
08:39karolherbst: prg: maybe you could run a mmt trace until something happens?
08:43imirkin_: dunno if that'd help
08:43imirkin_: this feels like a transient issue
08:43imirkin_: nfc what can cause a ctxsw timeout, except the ctxsw wedging itself
08:50prg: well yeah, sometimes things work fine for hours
08:55karolherbst: imirkin_: this is falcon code, right?
08:56imirkin_: karolherbst: yes.
08:56imirkin_: ctxsw :)
08:57imirkin_: it runs inside graph
08:57karolherbst: ok, found it
08:57karolherbst: imirkin_: I found the time to actually write a syntax file for nano :D
08:57pjz: I've got a GT2166GLM [Auadro FX 880M] running ubuntu (upgraded to kernel 4.3) ; it's crashing running xserver while unattended. Is this known? can I help wtih debugging somehow?
08:58karolherbst: pjz: dmesg
08:58karolherbst: imirkin_: maybe I try to get into that code and figure out the cases where it might not answer
08:58imirkin_: pjz: GT216 should, in general, work fine. so... unknown.
08:58karolherbst: imirkin_: or: we just lost the IRQ :D
08:59imirkin_: karolherbst: yeah no clue. i assume it uses a robust message passing scheme.
08:59imirkin_: karolherbst: that assumption is based on hope though, not actual code reading
08:59karolherbst: the pmu annoyed me too until I found out that there is still a message queued on the pmu
08:59karolherbst: maybe it is the same thing here?
08:59RSpliet: GT216 could hang randomly though... I've seen that happen a lot
09:00RSpliet: no idea what causes it, doesn't show on most GT218s anymore
09:01pjz: karolherbst: lot of Nov 22 16:48:42 trireme kernel: [ 1166.577017] nouveau 0000:01:00.0: Xorg: nv50cal_space: -16
09:02pjz: imirkin_: it might matter that I'm running an external (via DisplayPort) monitor as well as the internal screen?
09:02karolherbst: imirkin_: okay, the erro itself comes from the falcon
09:04imirkin_: pjz: nv50cal_space generally means that either the gpu has hung, or you're submitting commands too fast
09:07pjz: Nov 22 16:45:53 trireme kernel: [ 997.482477] nouveau 0000:01:00.0: fb: trapped read at 00204ba000 on channel 3 [3fb16000 Xorg] engine 00 [PGRAPH] client 03 [DISPATCH] subclient 04 [M2M_IN] reason 00000002 [PAGE_NOT_PRESENT]
09:07pjz: hmm, I should pastebin it
09:08pjz: imirkin_: http://paste.ubuntu.com/13478019/
09:08karolherbst: imirkin_: I already got an headache from that fuc code there :/ I think it would take me too long to investigate this, I think I'll pass then :D
09:09imirkin_: pjz: huh, surprising.
09:10imirkin_: pjz: looks like we have some issues in the xorg m2mf logic?
09:10pjz: imirkin_: I've never delved into X internals.. what's m2mf ?
09:10imirkin_: m2mf is actually nvidia-specific not X-specific
09:11imirkin_: it's a set of commands which allow memory-to-memory copies
09:11imirkin_: (f = formatted? i forget)
09:11imirkin_: the first error suggests that the thing we're trying to copy is unmapped
09:11imirkin_: and the NULL_DMAOBJ things suggest we're screwing things up bigtime
09:12imirkin_: in a way that i don't think is possible if everything is working correctly
09:12pjz: hmm.. I wonder if it's because I rebooted with the monitor plugged in
09:12imirkin_: all the display stuff is quite separate and unlikely to affect this
09:12imirkin_: is this a new issue with kernel 4.3? if so, a bisect would be great
09:13imirkin_: 4.3 got a pretty huge rewrite of nouveau, and small problems could easily have snuck in
09:13pjz: I don't know if it's new to 4.3, as I'm just noticing it because is witched form using proprietary drives over to nouveau
09:14pjz: ...because an upgrade to the latest proprietary drivers just plain failed to give me video at all
09:14karolherbst: imirkin_: wut
09:14imirkin_: pjz: oh i see
09:14karolherbst: imirkin_: newest benchmark: GTX 680 arund 10% slower than R9 290 with open drivers
09:15imirkin_: pjz: well afaik latest blob drivers don't support your gpu... you need the 340.x series
09:15pjz: so I switched to nouveau, but then I found there was some bug (uhh... https://bugs.freedesktop.org/show_bug.cgi?id=92504 I think) which caught me, so I upgraded to 4.3
09:16pjz: imirkin_: oh, hm, that might be the problem then :)
09:16pjz: imirkin_: anyway, now the symptom is usually like: it boots, I can run and use it all day, but if I walk off, it hangs while running xscreensaver
09:16imirkin_: pjz: fwiw the patch in question has been backported to various kernels
09:17imirkin_: all the way down to 3.2... pretty funny that that code has been around that long
09:17imirkin_: pjz: 4.2.6 should have that fix as well
09:17pjz: imirkin_: hmm. I'm running xubuntu 14.04 (LTS), though running i3wm instead of xfce
09:17pjz: imirkin_: so no 4.2.6
09:18imirkin_: well whatever the ubuntu LTS thing, it'll have that patch too
09:18imirkin_: what kernel series is 14.04 using?
09:18pjz: imirkin_: I think the other kernel here is... 3.13
09:19imirkin_: i dunno how they do stuff, but it looks like it's in 3.13.11-ckt30
09:19imirkin_: no clue if that maps to an actual released kernel by the ubuntu kernel team or not
09:20imirkin_: i've only ever built my own kernels, never used a distro one past installation media
09:20pjz: but anyway I found a latest-kernel PPA that's got 4.3 so I'm running it
09:20imirkin_: ah ok
09:38prg: so about this mmt thing, maybe the issue turns out to be reproducible... if i wanted to do a trace, i'd need to compile https://github.com/envytools/valgrind, right? this seems to be missing the VEX/ dir and it doesn't compile if i just take the one from svn://svn.valgrind.org/valgrind/trunk
09:38prg: guess i need to find the right version of that dir, what would that be?
09:38imirkin_: prg: no. read the guide.
09:38imirkin_: prg: http://nouveau.freedesktop.org/wiki/Valgrind-mmt/
09:39prg: ah. so there's a guide. great
09:42prg: yeah, that's better
09:56prg: okay, next lockup. now X is mentioned in dmesg, but i was tracing mpv... https://paste.debian.net/335398/
09:58prg: so the trace would be useless?
09:58imirkin_: most likely
09:58prg: the last few times mpv was mentioned, i can just try again
10:23prg: now i get lots of https://paste.debian.net/335401/ when running a game while mpv is also running
10:23prg: but no lockup yet!
10:24imirkin_: you're not on a G80 are you?
10:24imirkin_: coz if you are, destroy it with fire and get another board
10:25prg: complete dmesg from an older paste: https://paste.debian.net/335381/
10:25imirkin_: prg: are you using DRI2 or DRI3?
10:25prg: nouveau 0000:01:00.0: NVIDIA GK106 (0e6000a1)
10:25imirkin_: yeah... G80 is an ancient board. i'm sure you don't have one ;)
10:25prg: uh... whatever i get when i didn't do anything special
10:26imirkin_: ok. so DRI2 then.
10:26imirkin_: ugh. i blame the ctxsw code.
10:27imirkin_: perhaps it's missing some nooks & crannies on your board...
10:27imirkin_: which causes the gpu to be in a funky state when switching between channels
10:31prg: anything i can do to help with getting this fixed?
10:34prg: when things work it's quite usable, especially now that i can use pstate 0f
10:34prg: it just keeps locking up all the damn time
10:35imirkin_: prg: shot in the dark... try the patch in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=92761
10:35imirkin_: (the last patch)
10:36imirkin_: i realize the symptoms are totally different
10:36imirkin_: but it _might_ be the same thing
11:10prg: ok, i can't reproduce these issues reliably, will just have to keep using the system for a while
11:18prg: well... https://paste.debian.net/335411/
11:19imirkin_: that's with the patch in question?
11:20prg: if i didn't mess up the patching
11:22prg: after patching, make && make modules_install should be enough, since the fw stuff is all included in the module, right?
11:22imirkin_: yep... unless you also have an initrd that needs updating
11:36karlmag: karolherbst: Hmm... my notes are lacking a bit. The fun patch you have for extra info in debugfs? (If it's still valid and usable, obviously)
12:09karolherbst: karlmag: ohh no need anymore
12:09karolherbst: karlmag: you need that cstate stuff?
12:09karolherbst: karlmag: kepler_voltage branch in my repository
12:09karolherbst: that should fix your volting issues
12:11karlmag: karolherbst: ah, if it's not needed that's better obviously. :-)
12:11karlmag: just put a G80 [GeForce 8800 GTS] in a test rig here
12:12karlmag: imirkin_: me?
12:12karlmag: first of all to see if it worked
12:12imirkin_: nouveau has all kinds of assorted issues on it
12:12imirkin_: the damn thing doesn't support memtype's in sysram, which upsets some things
12:13imirkin_: and its 3d engine has all kinds of fail that we don't work around
12:13karlmag: now that sounds like "fun" :-P
12:13imirkin_: G84+ is much better
12:14karlmag: Well, couldn't beat the price of it anyway.
12:14karlmag: Most other cards I have are older
12:14karlmag: Except my new ones, obviously
12:15karlmag: I think the most usable (with nouveau) one is the 650ti
12:15imirkin_: yeah probably
12:15Tom^: 780ti imo with the Tom branch from karolherbst repo.
12:15imirkin_: anyways... G80 should basically work. just don't run piglit on it.
12:15imirkin_: or prepare to be deeply saddened
12:16karlmag: it was popped in because I hadn't tried it before.
12:16imirkin_: look at all the extra sadness on nv50 (aka G80)
12:18karlmag: doesn't look good for it no
12:18karlmag: lots of red all over I guess, but for that.. yeah
12:19karlmag: I wonder when I can start bothering you with the maxwell cards.. :-P
12:19imirkin_: you can bother me about it anytime you like
12:20imirkin_: however i'm generally avoiding thinking about maxwell until GM20x is supported on nouveau
12:20imirkin_: not worth sweating over the GM107's i think
12:21imirkin_: right, that just doesn't have accel at all
12:21imirkin_: hence not-my-problem :)
12:21karlmag: Nah, I'm not expecting nouveau support for that any time soon.
12:22imirkin_: if ever
12:22karlmag: Sadly, I might add, but it's not like I'm blaming you guys in any way. You do a great job.
12:27imirkin_: hakzsam: just happened to notice this guy: http://people.freedesktop.org/~imirkin/nv50-comparison/nv84-2015-07-09-hakzsam/spec@amd_shader_trinary_minmax@execution@email@example.com
12:27imirkin_: can you double-check if that one's real?
12:27imirkin_: i.e. does it still happen?
12:28hakzsam: imirkin_, it passes
12:28imirkin_: hakzsam: ok. good.
12:28hakzsam: imirkin_, on nva8 using mesa master
12:28imirkin_: yeah it passed on your nva8
12:28imirkin_: when you get a chance, check on a pre-nva0
14:43RSpliet: *grumbles some foul words*
14:47RSpliet: why would a VREF bit move from a ramcfg entry in the VBIOS to the ramcfg header... without changing values
14:47imirkin_: why not?
14:47imirkin_: or you mean without changing versions?
14:48RSpliet: that's what I meant indeed
14:48imirkin_: ah. because they hate you :)
14:48imirkin_: or perhaps it's in both places?
14:48karolherbst: RSpliet: they added a pwm bit without changing the version either and the table is read completly different then
14:49karolherbst: I bet mupuf can tell you tell you at least 5 other things where they did something like that ;)
14:49RSpliet: imirkin_: probably the first :-D in both places is an option, but a silly one... should I or them? :-P
15:01imirkin_: skeggsb: so... looks like trinity is able to lock up nouveau, and since it has no knowledge of the nouveau ioctls, i can only assume it never successfully manages to submit a batch
15:04karolherbst: oh s***, highly OT, but this is soo gold: https://github.com/narkoz/hacker-scripts
15:12karolherbst: karlmag: got my messagE?
15:27karolherbst: skeggsb: anything against this patch? https://github.com/karolherbst/nouveau/commit/162d472d553497aa6ab81eec17a7c197daade8bd I want to start cleaning up my stuff and get my patches upstreamed, because it piles up slowly and I lose my overview :)
15:29Dan39: how can i tell if re-clocking is working with my gfx card? im running archlinux with a 8800 gt (nv50 family - nv92/g92)
15:30imirkin_: Dan39: it's not enabled for your gpu for now.
15:30Dan39: guess i will have to try the proprietary driver to see if my game runs better. :'(
15:30imirkin_: you could hack the kernel and hope for the best
15:30imirkin_: but... likely to not work
15:31Dan39: why is re-clocking support not in the feature matrix?
15:31imirkin_: isn't it?
15:31imirkin_: "power management"
15:33RSpliet: imirkin_: please don't propose that before checking whether it's a GDDR3 card :-P
15:33imirkin_: RSpliet: most G92's are gddr3
15:34imirkin_: ddr2 was mostly the domain of g84/g86
15:34Dan39: o there is actually a nouveau update i dont have yet
15:34Dan39: xf86-video-nouveau-1.0.11+31+g1ff13a9-1 :D
15:34imirkin_: that's the ddx...
15:34imirkin_: reclockign is a kernel thing
15:34karolherbst: yeah well, the ddx don't do anything ;)
15:37imirkin_: Dan39: if you do want to hack it, this is the spot: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/clk/g84.c
15:38Dan39: not int he mood to compile kernel, takes too long <_<
15:38Dan39: but good to know
16:06koz_: Does anyone here run a GTX 680?
16:07koz_: I wanted to see if anyone has any experience with reclocking it before committing to a purchase.
16:22karlmag: "unknown chipset" oh well :-P
16:22karlmag: I guess a gtx 650ti isn't close enough to the 680...
16:32mooch: koz_: why not a gtx 690? it's like two 680s
16:39koz_: mooch: Didn't know that. Would there be a big price difference?
16:39koz_: I'm mostly considering the 680 from the Phoronix shoot-out they published earlier today.
16:39mooch: why don't you search for yourself?
16:40mooch: i found one on ebay tho for $330
16:42koz_: mooch: Do you have a 690 or something?
16:43mooch: dude, just search on ebay
16:43mooch: not that hard
16:44koz_: mooch: I meant my question more as 'do you know for sure a 690 will reclock OK?'
16:44koz_: I've got a 650 at the moment which definitely *doesn't* reclock OK, which is why I seek opinions from the community.
16:49mooch: no i don't
16:56imirkin_: karlmag: unknown chipset?
16:56imirkin_: either way, reclocking is still rather dicey, i wouldn't count on any high-level marketing name to reliably be able to reclock with nouveau
16:57imirkin_: specific boards may or may not, but nothign as generic as "gtx 680"
16:58karlmag: imirkin_: it was the NV126 in the xorg log
16:59karlmag: unsurprising obviously.
16:59imirkin_: karlmag: ah, that should be known for GL 4.0
16:59karlmag: just had to see what happens.
16:59imirkin_: kernel 4.0
16:59imirkin_: or maybe 3.19?
16:59imirkin_: but no accel
17:00imirkin_: hmmmm... then 4.2 :)
17:00karlmag: looked like it reverted though
17:00imirkin_: GM206 should be supported though
17:00imirkin_: for modesetting
17:00karlmag: NV126 (GM206) GeForce GTX (950, 960)
17:00karlmag: (it's a 960)
17:01karlmag: might need to upgrade something though
17:09koz_: imirkin_: Which is why I wanted to hear about any experiences with specific manufacturer's 680s or whatever.
17:15mooch: imirkin_: I tried implementing the EDID reading through the DDC_STATUS register, but nothing.
17:16mooch: the BIOS still polls it like a madman
17:56john_cephalopoda: Hey, I got a problem with nouveau while running flightgear. After a while, the whole computer will freeze and crash (or at least XOrg but I can't check because exiting is not possible).
17:57koz_: john_cephalopoda: What card are you on?
17:57john_cephalopoda: 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 645 OEM] (rev a1)
17:57john_cephalopoda: Here's some Xorg log: https://bpaste.net/show/804b7c0f30a0
18:00koz_: john_cephalopoda: I'm guessing the last few lines are what corresponds to your stuff freezing.
18:01john_cephalopoda: What does that mean for me?
18:01koz_: imirkin_: ^
18:09koz_: john_cephalopoda: Hopefully imirkin_ notices this and can get back to you.
18:12john_cephalopoda: I'll stay online for a bit longer since I haven't to get up early tomorrow and I have to wait for an update of my favourite webcomic. :)
18:17karolherbst_phon: john_cephalopoda: that xlog tells us nothing. dmesg is much more important
18:18karolherbst_phon: EQ overflow means something is not right, but waht? nfc
18:19john_cephalopoda: karolherbst_phon: The problem is, that the system freezes and crashes when this happens.
18:19john_cephalopoda: Doesn't exist.
18:19karolherbst_phon: mount it theb
18:23karolherbst_phon: maybe something is in your system log, but well. this is a bit hard on system crash
18:23karolherbst_phon: pstore is the best way to preserve crashes and the kernel does it automagically
18:25john_cephalopoda: It also tells me that pstore is not a supported filesystem.
18:28karolherbst_phon: do you compile your kernel yourself?
18:29karolherbst_phon: mhh it doesn't help us now, but you may want to enable it
18:30john_cephalopoda: Yep, enabled it.
18:31john_cephalopoda: I'll crash my computer yet another time and then post the pstore here.
18:31john_cephalopoda: Well - reboot, crash, restart, post.
18:31karolherbst_phon: mhh i hope you also enabled a backend for it :)
18:31karolherbst_phon: and enabled this save on crash option
18:32karolherbst_phon: i can't check currently cause i am in my phone :)
18:33john_cephalopoda: I enabled it in the kernel.
18:33john_cephalopoda: okay, brb
18:45john_cephalopoda: Hey. Didn't work for some reason.
18:47karolherbst_phon: what didn't work?
18:47karolherbst_phon: it may also be, that the kernel/gpu just hangs somewhere
18:47karolherbst_phon: without crashing
18:48karolherbst_phon: you could try to ssh into the machine
18:51john_cephalopoda: I'd have to set up some ssh stuff. IT's 3:50 am.
18:51john_cephalopoda: Well, bye.
23:14gnurou: hey everyone, what is the preferred way to dump/disassemble shaders generated by Nouveau? NOUVEAU_LIBDRM_DEBUG allows to dump pushbuffers, and envydis can disassemble shader binary, but is there a way to obtain said shader binary without butchering Mesa?
23:20andyskol: Hi, I am unable to get nouveau to drive a particular monitor. The console reports that the EDID checksum is invalid on boot, and indeed the raw EDID is almost all ffs, looks bogus. Using the nvidia-settings tool, I can pull the real EDID from the monitor, and that driver works fine. Can anyone point me in the right direction on how to get past this with nouveau? I can't get xrandr to do anything with this panel.
23:28hakzsam: gnurou, export NV50_PROG_DEBUG=1 is probably what you need :)
23:30gnurou: hakzsam: thanks - in the meantime I also figured out about glsl_compiler, both will certainly be useful! :)