00:47 pmoreau: RSpliet: Eh eh, ok. I'll just give it pfb directly then. ;)
06:34 bauerbob: hi, i’m using ubuntu 15.04 and removed all the nvidia drivers, installed nouveau, but X.org says “no screens found(EE)”
06:34 bauerbob: some lines above this error i see some infos about nouveau
06:34 bauerbob: [ 15.796] (II) NOUVEAU driver for NVIDIA chipset families :
06:34 mwk: hakzsam: umm, not PM_SETTINGS?
06:34 bauerbob: and the NV50 is NOT in this list
06:35 bauerbob: so is NV50 not supported? the feature matrix says it is supported
06:35 mwk: hmm
06:35 mwk: weird
06:36 bauerbob: i even tried upgrading the nouveau driver by activating the xorg-edgers repo, but vivid seems to ship the latest package already
06:37 hakzsam: mwk, I just named it like NVIDIA does, and I'm not sure if this reg is only related to PM
06:38 hakzsam: btw, NVIDIA uses SM for local counters (MPs) and PM for global counters (PCOUNTER), it would be good for us to use the same convention, what do you think?
06:40 mwk: hakzsam: uses where?
06:40 mwk: SM is just nv's name for MP
06:40 mwk: AFAIK they just always use PM
06:40 hakzsam: in the cupti API/documentation for example
06:41 prg_: bauerbob, nv50 is certainly supported, just might be called G80 or something
06:41 prg_: bauerbob, is nouveau blacklisted maybe? the nvidia driver likes to do that i think
06:42 bauerbob: i grepped for nouveau in /etc/modules.d (or was it /etc/modprobe.d?) and found nothing
06:42 prg_: so is the module loaded? pastebin dmesg
06:46 bauerbob: http://pastebin.com/kiL89KvY
06:53 prg_: and what exactly does the xorg log say?
06:54 Karlton: bauerbob: did you remove the /etc/x11/xorg.conf that nvidia makes?
06:55 bauerbob: yes …actually nvidia had none, either
06:55 bauerbob: i tried nouveau without xorg.conf first
06:55 bauerbob: but since it didn’t work i created the minimal xorg.conf given in the FAQ
06:55 bauerbob: but still no luck
06:56 bauerbob: here’s the Xorg.0.log: http://pastebin.com/cbZVD38r
06:57 prg_: that's... short
06:58 bauerbob: uhm… yes… just a sec
06:59 bauerbob: should’t “Initialized nouveau 1.2.1 20120801” be more recent?
06:59 bauerbob: 2012 seems to be pretty old
07:00 bauerbob: so here’s the full Xorg.0.log: http://pastebin.com/vgdqxYaH
07:00 prg_: i think that's when some api last changed or something, should be fine
07:05 prg_: hmm, not sure what's wrong there. some systemd thing where x runs as user and you need to be in a special group so it can talk to the hardware?
07:05 prg_: but no idea
07:07 bauerbob: ok. i guess i’ll open a bug report for ubuntu
07:09 prg_: not sure it's a bug, probably some misconfiguration
07:09 prg_: isn't there some wiki or something?
07:09 prg_: oh well, no idea about ubuntu
07:12 bauerbob: well, there’s http://wiki.ubuntuusers.de/Grafikkarten/Nvidia/nouveau - but it doesn’t contain a troubleshooting section
07:12 Karlton: there is the video group, but I don't think nvidia would work either if you are not in the group
07:27 imirkin: bauerbob: ls -l /dev/dri
07:34 bauerbob: @imirkin: $ ls -l dri
07:34 bauerbob: crw-rw----+ 1 root video 226, 0 Apr 28 16:21 card0
07:34 bauerbob: crw-rw---- 1 root video 226, 64 Apr 28 16:21 controlD64
07:34 bauerbob: crw-rw----+ 1 root video 226, 128 Apr 28 16:21 renderD128
07:35 imirkin: bauerbob: your X log is very weird. it sees the device, but nouveau never actually picks it up...
07:36 imirkin: is there something like selinux in the mix messing things up?
07:37 bauerbob: uhm… i never really changed anything related to selinux, so it should be configured with ubuntu’s default settings
07:39 bauerbob: i think Xorg initializing goes wrong as of this line “Falling back to old probe method for modesetting”
07:39 imirkin: yeah
07:39 imirkin: but that just means that nouveau doesn't see any devices
07:39 imirkin: even though it should :)
07:40 imirkin: are you perhaps running X as yourself and aren't in the video group?
07:41 bauerbob: no, it’s being started from gdm
07:42 imirkin: do you have an xorg.conf? if so, remove it
07:42 imirkin: and pastebin the xorg log that happens when you do that
07:43 bauerbob: i already removed xorg.conf
07:45 imirkin: can you pastebin the xorg log that results from that?
07:45 bauerbob: yes, but it really looks like the one that is already in pastebin
07:46 imirkin: i'm sure, but mind pasting it anyways?
07:49 bauerbob: just a sec
08:14 bauerbob: @imirkin: http://pastebin.com/uh5A75QJ
08:32 imirkin: bauerbob: that's incredibly weird... i've never seen this issue
08:32 bauerbob: yay, i’m special :-/
08:32 imirkin: (and adding to the oddness is the fact that i've seen a _ton_ of issues)
08:37 bauerbob: oh my… i guess i’m screwed
08:38 bauerbob: what i tried meanwhile: shutting down gdm and calling startx as user (who is in the video group) - same error
08:39 bauerbob: and i installed this kernel: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/current
08:39 bauerbob: it says: [ 653.345] (II) [drm] nouveau interface version: 1.2.2
08:39 imirkin: you're getting a KMS terminal and everything right?
08:39 bauerbob: but still the same error
08:40 imirkin: i.e. high-resolution term, not the VGA 80x25 one
08:40 bauerbob: let me check…
08:40 bauerbob: yes, it’s definetly > 80x25
08:41 imirkin: something in your X setup then, but ... no idea what
08:42 imirkin: if this were happening to me, i'd trace through the nouveau ddx's init code and see why it's bailing out
08:45 bauerbob: thank you so far, maybe i come back later this evening
08:45 bauerbob: cu
11:06 imirkin_: anyone around with a pre-gk110 kepler? (i.e. gk10x) and can do a mesa build + test a piglit for me?
11:07 imirkin_: i'm looking for someone to build https://github.com/imirkin/mesa/commits/gl4-integration and then run 'bin/shader_runner tests/spec/arb_tessellation_shader/execution/quads.shader_test -fbo -auto' and tell me if you get a memory out of bounds error in dmesg as a result
11:12 mupuf: imirkin_: I could certainly do that
11:12 imirkin_: i get that error on a gk208 but not a gf108
11:14 imirkin_: curiously i don't get it with nop.shader_test, so i think it must be something relating to the fact that quads.shader_test takes in 4 control points but outputs 9
11:15 imirkin_: and i should stop being so lazy and just trace the damn thing
11:25 mupuf: imirkin_: nve6 is fine?
11:27 imirkin_: mupuf: to test with? yeah
11:27 mupuf: ack
11:27 mupuf: will try it then :)
11:27 imirkin_: if you've brought your nuclear power plant along to power it on :p
11:28 mupuf: the nve6 consumes no more than 120W
11:28 imirkin_: peanuts
11:28 mupuf: only when running heaven though
11:28 mupuf: xonotic peaks at 90W
11:29 mupuf: even on the blob
11:29 imirkin_: hehe
11:30 imirkin_: oh, while you're at it, could you also apply http://patchwork.freedesktop.org/patch/48063/ (to that tree) and run heaven?
11:48 tobijk: do we rally have a fully GL4.1 set now? :O
11:49 imirkin_: with that branch it'll report GL 4.1
11:49 imirkin_: i wouldn't say it's fully conformant... the tess stuff has *tons* of issues
11:50 imirkin_: but at a high level, all the GL 4.1 features are supported in that branch
11:51 tobijk: that branch? it looks like master to me :-)
11:51 imirkin_: the branch i mentioned above
11:51 imirkin_: master still reports gl 3.3
11:51 imirkin_: i just upped the feature level reported for my personal convenience
11:51 tobijk: i have joined recentyl
11:51 imirkin_: o
11:51 tobijk: :D
11:51 imirkin_: https://github.com/imirkin/mesa/commits/gl4-integration
11:52 tobijk: ah
11:54 tobijk: dont know if intended but that commit is in master as well: http://cgit.freedesktop.org/mesa/mesa/commit/?id=e312a6995850e78b3b9e2cbe4713928bc9cc386d
11:55 imirkin_: yep, intended
11:55 imirkin_: like i said, it's to make my life easier
11:56 tobijk: are there thnigs to test with the gl4-integration branch? i can do that next to my work :)
11:58 imirkin_: tobijk: do you have any games that require GL4?
11:58 imirkin_: iirc metro redux and bioshock infinity
11:59 tobijk: not that i'm aware of, nor do i have the a full valve account
11:59 imirkin_: well, i was able to get the valve thing, but that's just valve games
11:59 imirkin_: i.e. not any of those :)
11:59 tobijk: yeah dont they have some GL4 ones?
11:59 tobijk: :o
12:00 imirkin_: didn't think so, but maybe some games they have will take advantage of GL4 features?
12:00 imirkin_: anyways... tess has known serious issues
12:00 imirkin_: so that branch is more of a joke than anything else
12:00 tobijk: everything has to start somewhere...
12:01 imirkin_: i.e. "ha ha, nouveau has GL 4.1 and your driver which is backed by full time staff doesn't". even while knowing full-well that the support is nowhere releasable due to tess fail.
12:01 tobijk: ^^
12:02 imirkin_: and the fail is at all levels, which is nice... mesa core, st/mesa, *and* nouveau. neat, huh?
12:02 tobijk: y a y
12:04 tobijk: imirkin_: btw you happen to know if there is something going on concerning the libdrm .60 failure?
12:04 imirkin_: yeah, downgrade to .59 :)
12:04 tobijk: meh :/
12:04 imirkin_: i'm really hoping skeggsb_ will take a look
12:08 imirkin_: but he's been quiet for a while
12:08 tobijk: coding the all solving patch :)
12:19 mupuf: imirkin_: do I need a git version of llvm?
12:20 mupuf: gallivm/lp_bld_init.c:437:4: error: implicit declaration of function ‘LLVMLinkInJIT’ [-Werror=implicit-function-declaration]
12:20 imirkin_: you don't need llvm at all
12:20 imirkin_: just don't build swrast...
13:03 mupuf: imirkin_: back!
13:03 mupuf: heaven looks quite hilarious
13:03 mupuf: especially without the patch you linked me to in patchwork
13:03 mupuf: will try the piglit test
13:08 jay3d: Hi!
13:10 jay3d: I have a question: What it takes to port nouveau driver set to OS X?
13:11 RSpliet: time
13:13 jay3d: :)
13:14 mupuf: imirkin_: yes, I get a memory out of bounds
13:14 imirkin_: mupuf: ok thanks
13:14 mupuf: and the test fails
13:15 imirkin_: and you get the funny blue triangles with tess in heaven?
13:15 imirkin_: i get those on both gk208 and gf108
13:16 imirkin_: mupuf: could i trouble you to leave the GK106 in reator tonight? i want to do some tracing
13:16 pmoreau: RSpliet: Let's get this thing compiling and running. :-)
13:16 mupuf: imirkin_: sure
13:16 pmoreau: RSpliet: Do you have some new patches I could test?
13:16 mupuf: imirkin_: I do not get any weird triangles no
13:16 mupuf: just ... nothing at all on the surfaces that are supposed to be tesselated
13:17 mupuf: [ 5229.650623] nouveau E[ PGR][0000:01:00.0] GPC0/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
13:17 mupuf: I get a ton of those too, for heaven
13:17 mupuf: and GL errors too
13:17 imirkin_: mupuf: yeah, that's what i see on GK208 as well
13:17 imirkin_: oh
13:17 imirkin_: force_glsl_version=0
13:18 mupuf: you mean in drirc?
13:18 imirkin_: or in the environment
13:18 mupuf:still needs to finish his patches to fix the older unigine benchmarks
13:18 imirkin_: to override the stupid thing in drirc
13:19 mupuf: nice!
13:19 mupuf: I indeed get the weird triangles
13:20 mupuf: blue-ish
13:20 mupuf: there are some z-ordering issues too
13:21 RSpliet: jay3d: if you were hoping for a more explicit answer: the whole nvkm half of the nouveau kernel-module can be re-used, but it needs to be glued to a different interface (namely, whatever the Mac OS X kernel implements). Then you need to write a new "libdrm" that communicates not with drm but with whatever Mac interface there is
13:21 mupuf: wow, nouveau makes the GPU consume 29W :D
13:21 mupuf: we are so damn power efficient!
13:22 mupuf: hmm hmm
13:22 RSpliet: after that I suspect you could re-use Mesa, but not the xf86 component (since it's solely for X.org), so you'd still have to port that to whatever compositor Mac uses
13:23 RSpliet: pmoreau: nope, nothing new
13:23 RSpliet: didn't have the time/energy for it
13:23 pmoreau: I understand :-)
13:24 imirkin_: mupuf: oh? i didn't see any z-ordering issues...
13:25 mupuf: only for one scene
13:25 imirkin_: mupuf: just the unfilled tris that tess produces...
13:25 mupuf: and one particular item
13:25 imirkin_: oh hm. maybe i just didn't notice it.
13:25 mupuf: possibly
13:25 imirkin_: btw, F3 to enable/disable tess
13:25 imirkin_: (don't try to enable wireframe, that won't work)
13:25 mupuf: ahah
13:26 imirkin_: as for power consumption... try clocking that board up, you might see it increase :p
13:26 mupuf: seriously? Can't believe you :D
13:27 mupuf: speaking about that though
13:27 mupuf: since we are not going to use our own pdaemon, I guess that I should just implement a kernel-space driver that would not be based on hwmon (since they still don't have an in-kernel API)
13:28 mupuf: unless ...
13:28 imirkin_: hm? why wouldn't we have a pdaemon?
13:28 imirkin_: [other than laziness]
13:28 mupuf: not on all GPUs
13:28 imirkin_: well, not all gpu's _have_ a pdaemon :p
13:28 mupuf: because of maxwell's signature thing
13:28 imirkin_: yeah, maxwell is a bit of a fly in the ointment
13:28 mupuf: older GPUs do not have a power sensor anyway
13:29 mupuf: yep...
13:29 mupuf: I keep using my user-space programs for power monitoring
13:29 mupuf: would be good to have them in nouveau
13:29 mupuf: the driver is trivial anyway
13:54 pmoreau: RSpliet: Youhou! It did crashed, and pstate reports that the clock changed. :-)
13:55 pmoreau: Waiting for Mesa to compile to test in-game and see if FPS change
13:55 RSpliet: it didn't crash?
13:55 pmoreau: Nop
13:56 pmoreau: Oh right
13:56 pmoreau: Didn't thought I was that tired... --"
13:58 imirkin_: in case anyone's curious about tess, here's a pair of screenshots from heaven with/without tess for the same scene: http://imgur.com/Ffyf3xa,qaeXYmY#1
13:59 RSpliet: imirkin_: Interesting... you can certainly see it adds depth!
13:59 RSpliet: if you look through the obvious misrenders :-P
13:59 imirkin_: hehe
14:00 imirkin_: yeah, i geuss it just gives fairly rough control surfaces
14:00 imirkin_: which it then expects get tessellated
14:00 imirkin_: (and transformed via hull shader)
14:00 RSpliet: the bit on the wall of the house on the left is interesting
14:00 imirkin_: yeah
14:01 RSpliet: you can see the texture following the wooden bar rather than the wall surface
14:01 imirkin_: could well be a bug somewhere
14:02 RSpliet: pmoreau: I'm still in anticipation of any performance data... but I guess it's so awesome you got sucked into the game and forgot all about IRC? :-P
14:02 RSpliet: imirkin_: btw, a 14% decrease in framerate? :-D
14:02 pmoreau: RSpliet: Recompiling Mesa takes some time ;)
14:02 imirkin_: RSpliet: probably more
14:02 imirkin_: feels a lot snappier without tess
14:02 pmoreau: It's an old core 2du I have
14:02 pmoreau: *duo
14:03 RSpliet: pmoreau: why recompiling Mesa? or did you have some debug symbols in? :-P
14:03 imirkin_: although... it's funny... in earlier tess attempts, i don't remember those blue things
14:04 imirkin_: i'm actually guessing someone broke something in one of the higher layers
14:04 pmoreau: RSpliet: I don't have stock Mesa installed as I installed the blob, and I erase my custom install by trying to build a 32-bit version of Mesa. But ready to test now
14:04 RSpliet: haha, take your time
14:04 imirkin_: no! now!
14:05 RSpliet: oh... you heard the man^
14:05 imirkin_: :)
14:05 pmoreau: Grrr... "Error: couldn't find RGB GLX visual or fbconfig"
14:07 imirkin_: calim: any opinion on http://patchwork.freedesktop.org/patch/48063/ ? (there's an additional if (dnz) bail case i had to add)
14:12 pmoreau: Meh... What's wrong with my installation... It used to work...
14:13 calim: imirkin: yes - unigine is an idiot
14:13 imirkin_: calim: duly noted ;) any harm in sticking ftz all over the place though?
14:14 calim: hm, I think compute shaders shouldn't use ftz
14:14 imirkin_: yeah, i had that thought as well
14:14 imirkin_: however that's not very well expressed right now, and as compute isn't actually supported...
14:14 imirkin_: i can condition it on a stage != compute thing though
14:15 calim: hm, why don't you need ftz if the source instruction already had one ?
14:15 imirkin_: then the value can't be a denorm?
14:15 calim: hm, does it flush the result, too ?
14:15 imirkin_: well non-denorm op non-denorm -> non-denorm
14:15 imirkin_: at least for those ops...
14:16 imirkin_: add, mul, cov...
14:16 calim: wasn't denorm something like very small ?
14:16 imirkin_: i actually have no real idea what it is ;)
14:16 calim: so, mul small * small can be very small
14:16 imirkin_: there's also a "dnz"
14:16 imirkin_: i thought denorm was "non-normalized floating point value"
14:16 calim: dnz treats inf and nan as 0 I think
14:17 calim: I think it's floats where the implicit bit is not 1
14:17 imirkin_: right... and can that ever happen as a result of an op?
14:18 calim: usually, a float is 1.m * 2^e
14:18 calim: and then denormal floats are those with leading zeroes, 0.m * 2^e
14:18 calim: which is used for e = small
14:18 imirkin_: which is illegal, no?
14:19 imirkin_: hmmm
14:19 calim: err, e = the smallest
14:19 calim: i.e. 0 - bias
14:19 imirkin_: right
14:20 imirkin_: but can an operation actually produce such a thing?
14:20 calim: which actually means 1 - bias, but the value is 0 to indicate leading zeros
14:20 imirkin_: without bit manipulation
14:20 imirkin_: or other shenanigans
14:20 calim: 1*2^-127 * 1*2^-2 ?
14:20 imirkin_: that won't just return 0?
14:20 calim: no, 0.01*2^-127
14:21 imirkin_: huh, ok. and so then... why would you want to flush that to 0?
14:21 calim: 0.01 being 1/4
14:21 calim: to match behaviour of old GPUs that didn't do denormals
14:22 calim: as to why this leads to bugs is, however, the dumb thing
14:22 imirkin_: well, the issue here seemed to be much more of one where these things polluted the whole image
14:22 imirkin_: it'd be solid white or solid black
14:22 calim: perhaps someone compares something with 0
14:22 imirkin_: so i thought it was some sort of illegality
14:22 imirkin_: maybe
14:22 calim: and relies on very-small numbers bein g 0
14:22 calim: hence, unigine being stupid
14:23 imirkin_: so... is this safe to do in all non-compute shaders?
14:23 imirkin_: i guess i'll drop the op check
14:23 calim: my preferred reaction is "fuck unigine, I shall pretend my card doesn't have ftz"
14:23 imirkin_: :)
14:24 imirkin_: fwiw nvidia sticks ftz all over the place
14:24 calim: I know, they can't afford being assholes
14:24 imirkin_: hehe
14:25 calim: hm, wait ... hehe
14:25 imirkin_: well, i don't like having random bugs in games either
14:25 imirkin_: despite those games being the ones who are assholes
14:25 imirkin_: like michael bolton :)
14:26 calim: debug_get_bool_option("ENABLE_BEHAVIOUR_FOR_DUMB_APPS")
14:26 imirkin_: why should i change? he's the asshole!
14:26 calim: yes, yes ... we want to make users happy
14:26 calim: so we should add all sorts of hacks to make stuff work
14:27 mupuf: calim: speaking of this, the option parsing in drirc really needs to be re-worked
14:28 mupuf: I should get back to it, hopefully before the summer :)
14:28 imirkin_: calim: anyways, thanks for the insight
14:28 calim: :)
14:28 imirkin_: i'll simplify it to always drop the ftz in and forget about it
14:30 pmoreau: RSpliet: Finally got the userspace to work again, gonna test Portal now :)
14:31 RSpliet: oh good!
14:35 pmoreau: Now it's Steam that doesn't find my installed games... :(
14:43 pmoreau: RSpliet: Up from 10fps at level 03, to 20fps at level 05. :-)
14:43 RSpliet: that's a start
14:43 pmoreau: But trying level 0e just caused a hard lockup and a strange pattern on screen
14:44 imirkin_: that's a finish
14:44 pmoreau: :D
14:44 RSpliet: apparently Mupuf is (a) Fin(n)ish now too
14:44 imirkin_: "strange pattern on screen" == "link training fail"
14:44 pmoreau: Ok
14:44 RSpliet: imirkin_: to the best of my knowledge there is no link training
14:44 imirkin_: er
14:44 imirkin_: did i say "link training"?
14:44 imirkin_: i geuss so
14:44 imirkin_: what i really meant was
14:45 imirkin_: "memory timing/etc configuration fail"
14:45 RSpliet: "some random parameter fail" yes :-P
14:45 RSpliet: pmoreau: not entirely unexpected though... but too bad :-)
14:45 imirkin_: well... specifically memory
14:45 pmoreau: I have the debug messages you're outputing if you want
14:45 imirkin_: as opposed to, say, engine
14:47 pmoreau: Ah, no, it's from the previous level change :/
14:49 RSpliet: don't worry about it
14:51 pmoreau: Interesting, moving from level 05 to 03 only yields a 6min bonus in battery life Oo
14:54 pmoreau: And with level 0f I get a black screen, but no lockup, and switching back to level 03 the screen is back
14:55 pmoreau: (I had Portal running while I changed the values previously, now I'm just running in console mode)
14:57 mupuf: pmoreau: the power consumption is cubic with the voltage and cubic with frequency on nvidia cards
14:58 mupuf: so, at some point, the difference is only worth it when truly idle
14:58 mupuf: power gating would help a lot in this scenario
14:58 mupuf: and it is overly complicated :s
14:58 imirkin_: we don't enable clock gating by default iirc...
14:59 mupuf: well, it is whatever state the bios left it
14:59 mupuf: there is still something I am missing for clock gating
14:59 mupuf: as for power gating, I would need to have a look at what pdaemon does
15:00 mupuf: anyway, time to sleep
15:00 mupuf: see you!
15:01 imirkin_: no pdaemon on G96
15:01 mupuf: imirkin_: right, this one may be easy to RE
15:01 mupuf: looking at traces
15:02 pmoreau: There should be a trace in mmio.dumps if you have time to look at it
15:03 hakzsam: mupuf, don't forget to plug the c8 before going to sleep, please :)
15:03 mupuf: hakzsam: done
15:03 hakzsam: nice, thanks!
15:04 mupuf: imirkin_: sorry, can't plug the e6 and c8 at the same time
15:05 mupuf: hakzsam: tell me when you are done. If i am still awake, I will plug back the e6
15:06 hakzsam: ok
15:08 imirkin_: hehe ok
15:13 hakzsam: mupuf, done
15:28 mupuf: hakzsam: ok, changing it
15:28 mupuf: thx
15:29 imirkin_: mupuf: awesome. will do some tracing tonight to see what buffer i'm forgetting to set/allocate/whatever
15:29 mupuf: imirkin_: great, plugged
15:29 mupuf: I will set the boot to the normal distro
15:30 imirkin_: kk
15:30 imirkin_: i just need nvidia to load
15:30 imirkin_: i guess you reinstalled the box btw? my user was gone
15:30 imirkin_: (but you kept my dir -- thanks)
15:30 mupuf: nope, it was just the blob distro
15:30 imirkin_: ah
15:30 mupuf: the other is in /dev/sda2
15:31 mupuf: I made it boot to this distro for hakzsam
15:39 mupuf: imirkin_: and the home is shared, hence why your data was still there
15:40 imirkin_: ah :)
15:43 hakzsam: imirkin_, mupuf could you show me the output of nvascan 120074 and 408850 on the e6?
15:43 imirkin_: hakzsam: i can do GK208 if you want
15:44 hakzsam: yes, please
15:44 imirkin_: doesn't scan take 2 args?
15:44 hakzsam: not sure
15:44 hakzsam: the second arg is the size I guess
15:44 imirkin_: GK208: 120074: 00000001 00000001 00000001
15:45 imirkin_: GK208: 408850: 00000004 0000000f 00000000 *
15:45 hakzsam: thks
15:46 imirkin_: (this is with nouveau btw, in case it matters)
15:47 hakzsam: it doesn't matter :)
15:48 hakzsam: well, time to sleep for me too, see you
15:49 imirkin_: see ya
16:33 a1fa: imirkin_: yellow
16:34 imirkin_: ?
16:34 a1fa: just saying hi
16:34 a1fa: saw your comment on phoronix this afternoon...
16:34 imirkin_: ah. hi.
16:34 a1fa: in re to gtx750
16:34 imirkin_: ok
16:38 a1fa: im yet to pstate=1 on that old acer aspire revo
16:38 imirkin_: your call :)
16:39 a1fa: its cold out there :)
16:39 a1fa: 60F at the moment
16:39 a1fa: if not less
16:41 imirkin_: i won't bother asking why a computer you want to play videos on is in the garage
16:41 a1fa: youtube has got a bunch of good wrenching turtorial video
16:42 imirkin_: ah :)
16:42 a1fa: and its got a good selection of music
16:43 imirkin_: mupuf: hmmm.... actually that mem_out_of_bounds thing appears to happen in the exact same way as some of the non-tess-related things... when you try to read an input you're not supposed to
16:44 imirkin_: mupuf: probably some linkage fail between tcs and tess... might explain the blue things. and we don't get that error on fermi for the other shaders either
23:18 pmoreau: RSpliet: Btw, here is the patch I applied to get it compiling: https://phabricator.pmoreau.org/F5736
23:20 imirkin: why did you need pfb so badly?
23:21 imirkin: oh, for nvkm_gpio?
23:24 pmoreau: Yes
23:25 pmoreau: I couldn't find a way to access gpio solely from hwseq
23:26 imirkin: it didn't work with just passing it in? maybe it's not an object...
23:27 imirkin: i.e. nvkm_gpio(hwsq)
23:28 mupuf: imirkin: good to know :)
23:29 imirkin: mupuf: i didn't end up tracing on the e6
23:29 mupuf: well, I'm not going to touch reator in the next few days
23:29 mupuf: Finland is going to be partying waaaaayyyy too much
23:31 pmoreau: :D
23:31 pmoreau: What for? 1 May?
23:33 mupuf: pmoreau: yep, the day before and the day after too
23:34 pmoreau: Ok. Are the universities doing some cortèges on Thursay?
23:38 hakzsam: pmoreau, it's the national day :)
23:39 pmoreau: hakzsam: Oh really, I didn't know!
23:40 pmoreau: s/Thursay/Thursday
23:46 mupuf: pmoreau: actually, it is not
23:46 mupuf: hakzsam: sorry for misleading you
23:48 pmoreau: Oh well, the important thing to remember is that they're partying ;)