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