02:32RSpliet: karolherbst: does that mean there's uninitialised memory, or that there's a use-after-free bug?
07:35mupuf: samsung contributing to nouveau?
09:33karolherbst: mupuf: where?
09:34RSpliet: in what universe?
09:46karolherbst: okay, anyway, I think I got some more insight with this PWM thingy
09:49karolherbst: 1. the blob doesn't lower voltage if the driver stays within the same pstate, even if the clock decreaes by like 270MHz
09:49karolherbst: 2. when starting to increase clock, voltage is set to the right value for the starting clock (even if it was much higher before than it has to be)
09:50karolherbst: 3. while increasing clock, pwm increases linear with it
09:54karolherbst: mhhh
09:55RSpliet: note that CoolBits might have a different effect on the blob than C-states
09:58karolherbst: mhh
09:58karolherbst: I can't set the clock directly though
09:58karolherbst: also I stay within the boost ranges
09:59karolherbst: strange though
09:59karolherbst: blbo sets clock to 135MHz while in idle
09:59karolherbst: allthough the lowest cstate is 405MHz
09:59karolherbst: even without coolbits enabled it does it
10:00karolherbst: ohh actually I get a bit higher then boost allows :/
10:01karolherbst: RSpliet: check that out: http://www.plotshare.com/sessions/209198379/Plot1.png
10:01karolherbst: its clear that the blob follows a specific pattern
10:02karolherbst: which isn't what somebody would implement though
10:02karolherbst: the reclock around 60000 shows it clearly whats odd
10:03karolherbst: it doesn't matter what I set as "max", but max always gets the same PWM value
10:03karolherbst: then it gets the difference between current clock and max clock and sets the PWM accordingly to that
10:04karolherbst: the pwm also gets the lowest value, if that difference is very big
10:04karolherbst: like near 40 000, where it clocks from 710 to 1000
10:05karolherbst: and nearly no pwm change in the last clocking, where I only increase the max clock in like 25MHz steps
10:21karolherbst: this shows nicely what I mean: http://www.plotshare.com/sessions/594497271/Plot1.png
12:14kb9vqf: I have an interesting bug that's happened twice now on my GTX 680: when switching to a new X session, the session locks up almost immediately and the console shows "PGRAPH engine fault on channel 5"
12:14kb9vqf: killing the new Xorg session with -9 allows the older, backgrounded Xorg session to be restored without issue
12:15kb9vqf: any ideas?
14:33Hoolootwo: there are a bunch of errors in dmesg that read [67428.594428] nouveau E[ PDISP][0000:01:00.0] 0x0820: 0x038c0749
14:34imirkin_: Hoolootwo: there was a patch to fix some of that
14:34imirkin_: someone's going around futzing with the cursor on disabled crtc's
14:34Hoolootwo: ah okay
14:35imirkin_: http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=linux-4.2&id=697bb728d9e2367020aa0c5af7363809d7658e43
14:35Hoolootwo: I'm not on the absolute newest version right now
14:35imirkin_: even if you were, i don't think it has that patch :)
14:36Hoolootwo: oh okay
14:37glennk: seems like a silly thing for userspace to be doing...
14:38Hoolootwo: yeah
14:39imirkin_: glennk: that's never stopped userspace before
14:39glennk: or any other component for that matter
15:02Umeaboy: Hi!
15:03Umeaboy: Here's the dmesg file with the nouveau error: http://pastebin.com/K7PRavMZ
15:03kb9vqf: so, anyone know why starting Xorg would cause "PGRAPH engine fault on channel 5"?
15:03imirkin_: Umeaboy: why is it trying to load external firmware?
15:04imirkin_: Umeaboy: are you booting with nouveau.config=NvGrUseFW=1 or something?
15:04Umeaboy: imirkin: Dunno.
15:04Umeaboy: I get the same issue in Ubuntu as well.
15:04imirkin_: what gpu is it?
15:04Umeaboy: With almost the same kernel.
15:05imirkin_: kb9vqf: you've asked a few times... i think it's safe to say "no, no one knows"
15:05Umeaboy: imirkin_: I'm no expert on how to find that information........
15:05kb9vqf: imirkin_: ah, you saw that :-) just was making sure
15:05Umeaboy: Do I use glxinfo for that?
15:05imirkin_: Umeaboy: lspci -nn -d 10de:
15:05BlueProtoman: I'm trying to update my graphics drivers (on a laptop running Ubuntu 15.04, and two GPUs via Optimus), but whenever I try my graphics break. And I've been able to use Optimus before! http://askubuntu.com/q/666615/61195 Any thoughts?
15:06kb9vqf: imirkin_: is there an official bugtracker I should report the issue to?
15:06Umeaboy: kristoffer@Ubuntu-laptop:~$ lspci -nn -d 10de:
15:06Umeaboy: 01:00.0 3D controller [0302]: NVIDIA Corporation GM107M [GeForce GTX 850M] [10de:1391] (rev a2)
15:06imirkin_: BlueProtoman: are you asking about blob drivers?
15:06imirkin_: Umeaboy: what kernel are you on? that won't get accel until kernel 4.1
15:06BlueProtoman: imirkin_: What does that mean, exactly? Proprietary ones?
15:06imirkin_: yes, proprietary blob
15:06Umeaboy: 3.19.0-26-generic
15:07imirkin_: Umeaboy: ok, well that kernel provides very minimal support for your gpu (effectively none since yours is a 3d accelerator which means it has no outputs)
15:07BlueProtoman: imirkin_: Yes, but I haven't found anyone else who's been able to help me, so I'm running out of channels to ask
15:07imirkin_: Umeaboy: if you upgrade to kernel 4.1 you'll be able to use it for accel a bit
15:07imirkin_: BlueProtoman: i believe their channel is #nvidia
15:07Umeaboy: imirkin_: Easiest way to do so in Ubuntu is?
15:07BlueProtoman: imirkin_: Silent.
15:08Umeaboy: To enable Backports?
15:08imirkin_: BlueProtoman: yes, that's my experience as well.
15:08imirkin_: Umeaboy: sorry, i know nothing about ubuntu. good luck!
15:08BlueProtoman: imirkin_: That's why I came here, because I'm starting to get desperate.
15:09imirkin_: BlueProtoman: afaik optimus + blob drivers = lots of insanity. perhaps ask the optirun people?
15:09BlueProtoman: imirkin_: Also silent
15:10imirkin_: don't they have forums on their site somewhere?
15:10imirkin_: devtalk or whatever?
15:10Umeaboy: imirkin: Found http://ubuntuhandbook.org/index.php/2015/06/upgrade-kernel-4-1-ubuntu-linux-mint/
15:11imirkin_: anyways, all i can say is that this is _not_ the proper channel for proprietary driver support
15:11imirkin_: despite not being silent
15:12BlueProtoman: imirkin_: Well, no harm in trying my luck. That said, do you have any ideas?
15:13imirkin_: i've never personally run such a setup
15:13imirkin_: i just use a separate X server whenever i need to do that
15:13BlueProtoman: Thank you anyway, then
15:13imirkin_: which works great since i never care about the output displayed, just use it for tracing some stuff
15:19karolherbst: imirkin_: I think this spilling issue is somehow nvc0 related
15:19karolherbst: because it works with af and before
15:19imirkin_: karolherbst: try it on f0
15:19karolherbst: works too
15:19imirkin_: ;)
15:20imirkin_: coz f0+ has 256 registers
15:20imirkin_: and nv50 has 128
15:20imirkin_: while nvc0/nve0 have 64
15:20karolherbst: even this 4000+ instruction program compiles fine
15:20karolherbst: mhhh
15:21imirkin_: did you do the ting i mentioned?
15:21imirkin_: i.e. keep those mov's at the end?
15:21karolherbst: it also works on NV50
15:21imirkin_: nv50 = nvaf
15:21imirkin_: at least in terms of register quantities
15:21karolherbst: k
15:21karolherbst: which one has also 64?
15:21imirkin_: nvaf has the DX10.1 features
15:21karolherbst: imirkin_: yeah, this helped with the one issue
15:22karolherbst: but there were always two
15:22imirkin_: hehe
15:22karolherbst: 1. spilling not possible => crash 2. phi coalesence failed
15:22karolherbst: second one is fixed by that
15:22imirkin_: hmmmmm
15:22karolherbst: I think there might be some invalid writes inside nvc0+ code
15:23imirkin_: well spilling issues are the worst
15:23karolherbst: any chip pre nvc0+ with less than 128 regs?
15:23imirkin_: not one that's supported by codegen
15:23imirkin_: but you could just change the target if you wanted
15:23imirkin_: i.e. change nv50_ir_target_nv50.cpp to report 64 regs (although it'll say 128 there since it counts in half-regs)
15:24karolherbst: k
15:24karolherbst: I just want to check if spilling fails without crashing or something
15:25karolherbst: how is the amount of regs read?
15:25imirkin_: getFileSize()
15:26imirkin_: for FILE_GPR
15:26imirkin_: gpr = general purpose register
15:26karolherbst: ohh okay
15:26karolherbst: I saw that, but it only made sense a minute later
15:26karolherbst: and in between I asked
15:26karolherbst: :D
15:26imirkin_: and i answered :p
15:27karolherbst: okay, still working
15:27karolherbst: setting to 64 now
15:27imirkin_: could be getting lucky
15:27imirkin_: some stuff is a bit different
15:27karolherbst: okay
15:27karolherbst: with 16 its getting random
15:28karolherbst: but it doesn't crash
15:28imirkin_: so some nvc0 thign is doing soemthing funky
15:28karolherbst: crashes with 8
15:28imirkin_: haha, that's 4 regs
15:28imirkin_: it probably has more outputs than that
15:28karolherbst: but it crashed after the third run
15:29karolherbst: but this was with my small test shader
15:29karolherbst: found one with around 150 instructions, which gets spilling issues on e6
15:30karolherbst: okay, works with 127 regs on e6
15:31karolherbst: I think there is somewhere an invalid write, but couldn't located it exactly
15:36karolherbst: mhhh
15:37karolherbst: just set GPR count to 255 and it kind of runs, but I think you can imagine how it looks like
15:37imirkin_: you're messing up the isntructions while you're at it
15:37imirkin_: the fields are only meant for up to a value of 63
15:37imirkin_: so you're just setting random bits on opcodes
15:37karolherbst: mhh
15:38karolherbst: really?
15:38karolherbst: because its 255 for nv20a
15:39imirkin_: gk20a
15:40imirkin_: and that uses the gk110+ isa
15:40imirkin_: which has 256 regs
15:40imirkin_: SM35
15:40imirkin_: vs SM20/SM30
15:40karolherbst: ohh okay
15:41karolherbst: I think tesselation is the problem somehow
15:41karolherbst: or the tess shaders
15:42karolherbst: mhh
15:44karolherbst: at lowest settings heaven runs fine without issues at least
15:45karolherbst: imirkin_: this sounds bad, doesn't it? "Access not within mapped region at address 0x1053E8140"
15:45imirkin_: yes.
15:46karolherbst: at 0x497C62: nv50_ir::SchedDataCalculator::recordWr(nv50_ir::Value const*, int) (nv50_ir_emit_nvc0.cpp:3055)
15:46imirkin_: didn't i send a patch for that
15:46imirkin_: i thought i even pushed it
15:46karolherbst: ohhhhh
15:46imirkin_: to support 256 regs
15:46karolherbst: I think my mesa is just old
15:46imirkin_: that will only happen on nvf0 though
15:46karolherbst: Aug 19
15:47imirkin_: commit 2f5ee9bf27b9
15:47imirkin_: the date on the commit is Aug 17, but i probably pushed it after that
15:51karolherbst: okay, still get the valgrind error, but now at 0x48A25D: nv50_ir::SchedDataCalculator::recordWr(nv50_ir::Value const*, int) (nv50_ir_emit_nvc0.cpp:3059)
15:51karolherbst: current master
15:52imirkin_: karolherbst: can you get the specifics?
15:52imirkin_: karolherbst: also did you increase the number of regs?
15:52imirkin_: coz if you did, that's semi-expected
15:53karolherbst: with increases regs it compiles fine
15:53karolherbst: that's with plain old 63
15:53imirkin_: that shouldn't happen
15:53imirkin_: can you stick some asserts in there to make sure that things aren't crazy?
15:54karolherbst: mhh things are crazy, I checked already
15:54karolherbst: like instructions with size over a billion
15:54imirkin_: ok, well that's bad
15:54imirkin_: see if valgrind has some options to super-mega-check some stuff
15:54karolherbst: didn't figure out where it came from though
15:54karolherbst: tried stuff I know, but didn't find anything
15:55karolherbst: mhh
15:55karolherbst: invalid read 2 at 0x49C66B: nv50_ir::NVC0LoweringPass::handleTEX(nv50_ir::TexInstruction*) (nv50_ir_lowering_nvc0.cpp:695)
15:55karolherbst: ohh wait
15:55karolherbst: there is some stuf
15:56karolherbst: https://gist.github.com/karolherbst/729cf79c5488519e10eb
15:56imirkin_: ok that's bad
15:57karolherbst: working code also has some invalids, though
15:57karolherbst: still shouldn't happend (tm)
15:58imirkin_: yeah, i think something ridiculously bad is happening
15:58karolherbst: though some do it intentionally....
15:58imirkin_: might be nouveau_compiler-specific
15:58karolherbst: like in crypto libs *cough*
15:58imirkin_: if you could figure it out, that'd be really awesome
15:58karolherbst: yeah, maybe I get lucky
15:59karolherbst: :D
15:59karolherbst: "char text[6553600] = {0};"
15:59karolherbst: do you know what valgrind says about that?
15:59karolherbst: "Address 0xffe9967c8 is on thread 1's stack"
16:00imirkin_: hehe
16:00karolherbst: inside nouveau_compiler.c
16:00imirkin_: try removing one 0 from that
16:00karolherbst: yeah, its my fault anyway
16:00karolherbst: but this shouldn't effect heaven
16:01karolherbst: but the output is more sane now
16:02karolherbst: https://gist.github.com/karolherbst/c96cf6432f0e3d3d9f04
16:03karolherbst: yo
16:03imirkin_: can you figure out what it's doing?
16:03karolherbst: only 2 issues left
16:03karolherbst: invalid write of size 4 at 0x48A1ED: nv50_ir::SchedDataCalculator::recordWr(nv50_ir::Value const*, int) (nv50_ir_emit_nvc0.cpp:3059)
16:04karolherbst: mhh
16:04karolherbst: array access + write
16:05imirkin_: add some prints :)
16:05karolherbst: I bet r is just too high
16:06karolherbst: yo, r = 1073741823
16:06karolherbst: 0 before
16:06imirkin_: 0x3fffffff
16:07imirkin_: figure out where it's coming from?
16:07karolherbst: mhhhh
16:07karolherbst: this sounds interessting
16:08karolherbst: r, a and b are messed up
16:08karolherbst: r:1073741823 a:1073741823 b:1073741824
16:08karolherbst: a = v->reg.data.id
16:09karolherbst: ohh shit :/
16:09karolherbst: run inside gdb is different
16:09karolherbst: and I don't hit this anymore
16:09imirkin_: try gdb + valgrind
16:10karolherbst: but GCRA::hi is messed up for sure
16:10karolherbst: some items in that list have invalid vptrs
16:10karolherbst: into some 0 mem region
16:13karolherbst: ohh yeah nice :/ how this just don't work
16:15karolherbst: ohh well, that's messy
16:29karolherbst: ohhh man, entire GCRA::hi is messed up, the head already got a reg value of over a million
16:30imirkin_: happy debugging :)
16:32karolherbst: when does the nodeCount increases?
16:44karolherbst: mhh
16:44karolherbst: okay
16:44karolherbst: somehow there is a invalid NODE inside GCRA::hi
16:44karolherbst: with score 0
16:44karolherbst: and DataFile 32766
16:46imirkin_: that seems high
16:46karolherbst: yeah
16:46imirkin_: 32766 = 0x7ffe
16:46karolherbst: reg is 1918876672
16:46karolherbst: :)
16:46imirkin_: aka (u16)-2
16:46imirkin_: errrr
16:46imirkin_: no it's not
16:47karolherbst: it happens after the first RA run fails
16:48karolherbst: second GCRA::simplify pass
16:48karolherbst: then
16:48karolherbst: inside the find best loop, it just junds a list entry with next == NULL
16:48karolherbst: and that's the invalid one
16:48karolherbst: funny though
16:49karolherbst: GCRA::hi also points to something funny
16:49karolherbst: f also 32766
16:49karolherbst: but next seems fine
16:49karolherbst: so "for (RIG_Node *it = best->next; it != &hi; it = it->next)" the it != &hi will never be true
16:49karolherbst: because the head is just invalid
16:51karolherbst: GCRA::hi looks like this somehow: head (invalid) -> next (valid) -> next ... -> next (invalid) -> next (NULL)
16:51karolherbst: where both invalids have different locations though
16:53karolherbst: mhh
16:53karolherbst: strange
16:54karolherbst: GCRA::hi->f seems to be always something strange
16:55karolherbst: ohhhhh
17:02marcosps1: Hi guys :)
17:26karolherbst: imirkin_: is it okay for the first entry to have a strange DataFile value?
17:27imirkin_: karolherbst: i've thus far avoided figuring out how the RA stuff works.
17:27karolherbst: seems to be the same with unpatched mesa, too
17:27imirkin_: and i plan to carry that on for as long as humanly possible
17:27karolherbst: I see
18:13marcosps1: imirkin_: around?
18:13imirkin_: always
18:13marcosps1: :)
18:14marcosps1: imirkin_: so, do you have any documentation about immediates...?
18:14imirkin_: what'd you have in mind?
18:14imirkin_: you can find the instruction encodings in envydis
18:14imirkin_: iirc i sent you an email with various infos
18:16marcosps1: imirkin_: You send a shader to test with, and you said to change a value in IMM, but I don't know in whats IMM you say...
18:16marcosps1:is going to lok in envytools again
18:16imirkin_: the line that defines the value of the IMM
18:16imirkin_: you can feed that shader to nouveau_compiler
18:16imirkin_: i thought i sent you an email like a month ago with some stuff
18:17marcosps1: imirkin_: I'll verify it again... As I said, I lost all data in my HD since last week...
18:18imirkin_: i assumed you'd have kept your email...
18:18marcosps1: imirkin_: yes, but I have a lot of emails... I'll create a new rule to move your emails to another dir :)
18:19imirkin_: gmail is good at searching. i highly recommend :)
18:20marcosps1: imirkin_: I already found it :)
18:28marcosps1: imirkin_: Also, do you like all that methods: run(prog), doRun(prog), run(func), doRun(func) ...?
18:28marcosps1: It's quite confusing :P
18:30marcosps1:is thinking about to send a patch to change those confusing names...
18:54imirkin_: marcosps1: it was like that when i got there
18:55marcosps1: imirkin_: IMM[0] FLT64 {0.00000000, 0.00000000} -> IMM[0] FLT64 {1.00000000, 1.00000000}
18:55imirkin_: yep
18:56marcosps1: :) Finally figuring out heheh
19:00imirkin_: just a quick break in the clouds before the uncoming hurricane
19:03marcosps1: imirkin_: Also, I tried to run Team Fortress 2 here with DRI_PRIME=1, and it runs a little slowly than Haswell...
19:03marcosps1: imirkin_: do you have the same behavior in your box?
19:04imirkin_: no reclocking = super slow
19:04imirkin_: depends what your card boots to
19:04imirkin_: most fermi's boot to a middle-ish clock, so they're not TOO bad
19:04imirkin_: but very far from max speed
19:06marcosps1: imirkin_: Hum... got it.
19:06imirkin_: look on the bright side -- it worked! :)
19:07marcosps1: imirkin_: Yes, team fortress worked at a playable state. But Dead Island isn't running until now =/
19:07marcosps1: imirkin_: As DI is a 32bit game, maybe recompiling mesa to 32bit using a cross compiler could help it?
19:08imirkin_: well, it won't run at all without 32-bit mesa
19:08marcosps1: :)
19:09marcosps1: imirkin_: Fedora have a 32bit mesa lib I beleive, but they are from version 10.6.3.
19:10imirkin_: that should be fine
19:11marcosps1: imirkin_: But the mesa libs from repository are not OpenGL 4 compliance... DI runs with OpenGL 3.3 ...? :|
19:11imirkin_: i assume so
19:11imirkin_: sorry, i dunno what dead island is
19:11imirkin_: [beyond making the assumption that it's a game of some sort]
19:11imirkin_: i know very little about games
19:14marcosps1: imirkin_: Hum...
20:58marcosps1: imirkin_: this time you received my patch in the ML?
20:59imirkin_: ya
21:06marcosps1: imirkin_: :)
21:06marcosps1: imirkin_: After some research, I gave up cross compiling... lets wait for fedora maintainers to upload new mesa packages :P
21:06imirkin_: k
22:45imirkin: x86_64-pc-linux-gnu-gcc -o conftest -O2 -pipe -mcpu=G5 -mtune=G5
22:45imirkin: heh
22:45imirkin: sometimes i hate build systems
23:01airlied: imirkin: you are cross compiling for a g5?
23:04imirkin: airlied: indeed i am
23:04imirkin: llvm does not seem amused
23:04imirkin: but... i just disabled llvm and it's all better now
23:04imirkin: mesa is finally building
23:23imirkin: airlied: will nvidiafb conflict with nouveau? or is there some form of handover between them?
23:28airlied: imirkin: don't use nvidiafb
23:28airlied: offb and nouveau
23:28imirkin: is there a way to kill it if i idiotically built it into the kernel?
23:28imirkin: [and don't want to rebuild]
23:29airlied: there is some video=nvidiafb option I disremember
23:29airlied: you know a G5 should be possible to build native on :)
23:30imirkin: airlied: yeah, except it's nfsroot and it's just easier to do it locally on my desktop which hosts it
23:30imirkin: and is much faster
23:30imirkin: if i end up needing llvm i'll build locally, but... meh
23:30airlied: you might need it to make sure you don't regress llvmpipe
23:32imirkin: airlied: dunno... llvmpipe didn't make sure it didn't regress the hw drivers :po
23:33airlied: well the hw drivers worked by happy accident rather than design :-P
23:37airlied: but since someone is testing llvmpipe regressions should be caught now
23:39imirkin: airlied: i don't think users cared *why* it worked
23:42airlied: I don't think users :-)
23:43imirkin: well people do complain every so often