00:23 Weaselweb: RSpliet: you suggestion with another DVI cable seems to be absolutely correct. I tried a new one this morning. started my box and up to now not a single unplugged event
00:23 karolherbst: mupuf: is it required to rebuild the nvidia blob after mmiotrace support was added into the kernel?
00:28 mupuf: it should not be
00:28 mupuf: karolherbst: ^^
00:30 karolherbst: okay, anyway not much I can do about that except I always want to disable it before updating blob
00:30 karolherbst: there is a new blob version btw
00:31 karolherbst: "Added experimental full OpenGL support to EGL."
00:31 karolherbst: interessting
00:56 karolherbst: updating your system after you was a week away really is annoying :/
01:00 karolherbst: mupuf: the nvidia blob seems to work here if mmiotraces are built into the kernel but disabled
01:02 mupuf: and by disabled, you mean, not using the mmiotrace tracer?
01:03 karolherbst: yeah
01:03 karolherbst: just boot and then do something like glxinfo
01:04 mupuf: try tracing now/
01:04 karolherbst: yeah
01:06 karolherbst: mupuf: is this okay? "mmiotrace: ioremap_*(0xf0000000, 0x1000000) = ffffc90014000000"
01:06 mupuf: probably :D
01:06 karolherbst: also, is this okay, that I have only one cpu core left?
01:07 mupuf: yes
01:07 mupuf: that's the only way it can work
01:07 karolherbst: okay
01:07 mupuf: brb
01:10 karolherbst: okay, seems to have worked. got a 101MB trace just by starting X
01:28 karolherbst: mupuf: so I now make a trace with toying aroung with the reclocking things inside nvidia-settings a lot, could be nice
01:40 pmoreau: Whoah, G94 is so old it can't run Cuda samples, which requires SM>=2.0...
01:40 pmoreau: Never thought that only Fermi+ supports SM>=2.0
01:40 karolherbst: :O
01:41 karolherbst: but d3d9 is SM 2.0?
01:41 karolherbst: 9.0c indicates even SM 3.0
01:41 pmoreau: No idea :/
01:41 karolherbst: this is strange
01:42 karolherbst: every d3d 9.0c card should be SM 3.0 compliant
01:45 pmoreau: Oh wait, maybe I'm mixing a few things...
01:45 RSpliet: Weaselweb: oh I'm glad to hear :-)
01:45 RSpliet: for a second I feared I made you waste a few quid :-P
01:47 Weaselweb: RSpliet: no, nevertheless I had a spare cable
01:48 RSpliet: pmoreau: G94 should be able to run some Cuda stuff...
01:49 pmoreau: RSpliet: Yeah, if I manage to find a version of nvcc which supports >=sm_11
01:50 pmoreau: Which is not the case of nvcc from the cuda package on Arch
01:50 RSpliet: oh right, I'd just get the Cuda toolkit from NVIDIA's website
01:50 RSpliet: also: you pronbably should explicitly mention the sm level
01:51 RSpliet: karolherbst: don't take my word on it, but I think that Microsoft DirectX SM x.y is not the same as NVIDIA PTX SMxy
01:51 pmoreau: I did, and it refuses everything below sm_20. Gonna try with the toolkit from Nvidia website, though I guess it might end up the same way
01:56 karolherbst: I see
01:59 karolherbst: was there a way how to remove the timestamps in demmio?#
02:00 RSpliet: pmoreau: https://en.wikipedia.org/wiki/CUDA
02:01 RSpliet: under "supported GPUs" you see a nice overview of the compute capabilities mapped onto GPUs
02:01 RSpliet: this could mean that your compiler support sm_11, but your GPU doesn't :-P
02:04 pmoreau: RSpliet: Saw that page, but I understand it the other way: the G94 supports sm_11, but the compiler doesn't
02:04 pmoreau: sm_1x support has been removed in Cuda 6.5
02:04 pmoreau: And I was using Cuda 7.0...
02:04 pmoreau: So, gonna download 6.0
02:08 RSpliet: ...
02:08 RSpliet: ah
02:09 pmoreau: (Trying to get some compute traces on the G94 before sending it ;))
05:16 karolherbst: mupuf: now that it seems to work for me, is there somethig I should try out especially?
06:14 hansg: imirkin, hi, thanks for your long email. In the mean time I've been debugging this myself and I've more or less found the root cause, see my email.
06:14 imirkin: reading now
06:15 imirkin: hansg: you're probably right that scanout buffers have to be untiled
06:15 imirkin: hansg: however pixmaps/etc aren't scanout buffers
06:16 hansg: My fix currently assumes that the ddx has always setup the scanout engine in tiled mode. I'm tempted to make sure this is the case by patching the ddx to always use a tiled scanout setup when dri3 is in use
06:16 karolherbst: okay nice, have a 185K mmiotrace where the gpu clocks down to 135MHz and up to 705MHz :) imirkin what do you think how likely it is, that there also happen some voltage changes?
06:17 hansg: imirkin, right, but those are normally created by the client rather then by the ddx, even with dri2, or am I completely wrong here ?
06:17 imirkin: hansg: if you make PIPE_BIND_SCANOUT behave the same way as whatever the ddx does for scanout buffers, then that sounds perfectly fine
06:17 imirkin: hansg: i'm not entirely sure about dri2. i think there are some situations where it can scanout a client buffer directly, with the composite extension? not 100% sure.
06:17 imirkin: nor am i 100% sure that this worked with nv30 ;)
06:18 karolherbst: nice, found memory stuff
06:18 imirkin: karolherbst: very.
06:18 hansg: imirkin, " if you make PIPE_BIND_SCANOUT behave the same way as whatever the ddx does" right that is what my patch is doing, the problem is that the ddx has different behavior for it depending on whether or not the ddx is using accel, and AFAICT there is no way to get to this info from within the gallium driver
06:19 hansg: imirkin, my suggested fix for this is to always use the accelerated layout for the scanout buffers, as those work fine in unaccel mode too
06:19 imirkin: hansg: if the ddx isn't using accel, there's no dri3 either then. i think.
06:19 karolherbst: okay, mhh
06:19 karolherbst: there are many scripts written into PDAEMON
06:20 hansg: imirkin, correct, at least in my experience so far, which makes this a non problem atm, but weren't there plans to allow dri3 without exa, and thus without accel ?
06:20 hansg: Seems like a ddx patch to force tiled layout of the scanout when dri3 is used is a good idea to future proof things
06:21 imirkin: hansg: it would have been with glamor, and via xf86-video-modesetting
06:21 imirkin: which is most likely a total fail on nv30
06:21 hansg: Ah, I see
06:21 imirkin: hansg: or perhaps you're privvy to plans that i'm not ;)
06:21 hansg: Nope
06:22 hansg: Ok, then I'll go and submit my patch upstream.
06:22 imirkin: so the bit about aligning the pitch differently is quite odd
06:23 imirkin: do you know why it does that?
06:23 imirkin: also, should be noted that while nv40 can render to untiled surfaces, i don't think that nv30 can
06:23 hansg: Nope, just copy and pasted it from the ddx, in the ddx it is in src/nv_accel_common.c
06:24 imirkin: hansg: oh, that's just in the tiled case
06:24 imirkin: you put your logic in the untiled case, no?
06:24 imirkin: (tiled == swizzled btw)
06:24 hansg: nouveau_allocate_surface()
06:25 hansg: has :
06:25 hansg: if (scanout && pNv->tiled_scanout)
06:25 hansg: tiled = TRUE;
06:25 imirkin: right.
06:25 RSpliet: karolherbst: sorry, remind me again what the card is you're tracing?
06:25 imirkin: hansg: so... it wants a tiled surface.
06:25 imirkin: aka swizzled, i think
06:25 RSpliet: "in my days" ( ;-) ) voltage changes showed up as GPIO writes
06:26 imirkin: hansg: and nv30_miptree was giving it an unswizzled one, since 1920 isn't POT
06:26 imirkin: hansg: and i guess it never uses that surface for texturing
06:27 imirkin: hansg: coz it's a scanout surface
06:27 RSpliet: imirkin: nor is 768, a common number of pixels on the Y-axis back in 1920 :-P
06:27 hansg: imirkin, yes that sounds right
06:27 imirkin: hansg: so you need to make nv30_miptree upscale the width/height and make it swizzled for PIPE_BIND_SCANOUT
06:27 imirkin: hansg: since it's the ddx that does the rendering, it doesn't really end up mattering, since all that info is lost
06:27 imirkin: but logically that's what's going on
06:28 imirkin: hansg: and there are a few ways to get PIPE_BIND_SCANOUT in mesa
06:29 imirkin: e.g. with dri2 you can still do __DRI_IMAGE_USE_SCANOUT
06:29 imirkin: which i guess didn't work before
06:30 hansg: Ok, I get what you're saying. I'll try to rework the patch to do as you suggest
06:31 hansg: Note that it seems to be unnecessary to round up to a pot for scanout surfaces though, the pitch is rounded up to a multiple of 1024 instead, e.g. in my case it is 8192, which is not a pot
06:32 hansg: And the height is completely untouched
06:33 imirkin: hansg: might want to check your calculator again...
06:33 hansg: ?
06:33 imirkin: 8192 is a pot
06:34 hansg: Ah you're right
06:34 imirkin: i'm surprised that just aligning to 1024 worked....
06:35 hansg: But the actual code from the ddx is not rounding up to a pot
06:35 hansg: 4 * 1920 = 7680
06:35 imirkin: if (usage_hint & NOUVEAU_CREATE_PIXMAP_SCANOUT)
06:35 imirkin: flags |= NOUVEAU_BO_CONTIG;
06:35 imirkin: interesting.
06:35 imirkin: dunno what that does, might want to maintain that too
06:35 RSpliet: marks that the memory should be contiguous in physical mem?
06:36 imirkin: RSpliet: perhaps. but i haven't traced the code.
06:36 glennk: crtc on nv30 requires physically contiguous ram to scanout if i remember correctly
06:37 imirkin: you mean vram, right?
06:37 imirkin: but how could it not be physically contiguous? there's no vm...
06:38 glennk: hmm, indeed
06:38 glennk: is that flag also set for newer chips?
06:38 hansg: Yeah, that code is shared with nv50 and nvc0
06:39 karolherbst: RSpliet: nve6 770M
06:39 karolherbst: RSpliet: wanna see the trace?
06:40 RSpliet: karolherbst: ah! well I haven't seen NVEx reclocking much, so I can't say whether voltage changes are still done using GPIO, although I'd expect them to be
06:40 RSpliet: not now thanks, I'm quite occupied as it is :-)
06:40 glennk: imirkin, flag is for the chips with vm then
06:40 karolherbst: RSpliet: no, they are not done using gpio
06:42 karolherbst: I mean, they are kind of, but different somehow
06:42 karolherbst: there is a pwm somewhere
06:42 imirkin: RSpliet: karolherbst has a funny one with vid set via pwm
06:43 imirkin: RSpliet: most of them are set the old-fashioned way though
06:43 RSpliet: ahh right... okay
06:43 karolherbst: imirkin: any idea how I can be sure I found the right reg?
06:44 karolherbst: and by sure I mean like I have like 10 regs and one of them is it
06:44 glennk: voltmeter?
06:44 karolherbst: glennk: yes
06:44 karolherbst: nouveau can't change voltage for my kepler card currently
06:44 karolherbst: so I have to skip that to get clocking
06:44 imirkin: karolherbst: you can't
06:45 imirkin: karolherbst: but you have a way of reading the voltage that is set no?
06:45 karolherbst: okay, so it has to be any and can also be a known one
06:45 karolherbst: mhhh
06:45 karolherbst: no
06:45 karolherbst: it always says 0.6V for me
06:45 karolherbst: I mean there has to be a way, but who knows which one
06:46 karolherbst: I created the trace to be able to find all that out
06:48 karolherbst: ohh mesa hit GL 4.2 now?
06:48 imirkin: not really
06:49 RSpliet: oh... is that non-gallium only?
06:49 imirkin: mesa's GL 4.2 support hasn't changed in any way whatsoever
06:49 imirkin: in the past month
06:49 imirkin: longer, if you don't count the lower GL versions
06:49 karolherbst: GL_ARB_shader_image_load_store done for intel today?
06:49 imirkin: yeah
06:49 imirkin: but the core support has been in for like a year
06:49 karolherbst: tesseleation stimm missing I guess
06:50 karolherbst: ahh I see
06:50 karolherbst: *still
06:50 imirkin: for i965, tess and fp64 are required for it to hit GL 4.2
06:50 imirkin: for gallium, shader buffer/image support is required
06:50 karolherbst: at least the GL3.txt says that core supports all the 4.2 bits now :/
06:50 imirkin: haha
06:51 imirkin: ok :)
06:51 karolherbst: GL_ARB_shader_image_load_store and GL_ARB_shader_atomic_counters missing and nouveau hits 4.2?
06:51 imirkin: sure
06:51 imirkin: s/missing/implemented/
06:51 karolherbst: yeah
06:52 RSpliet: atomic counters doesn't sound like the most complex job, am I overlooking devils?
06:52 imirkin: RSpliet: a few smaller ones
06:52 karolherbst: wait
06:52 imirkin: RSpliet: and one really big one
06:52 imirkin: the really big one is that i tried to do it and i couldn't for the life of me get the shader to write to gmem
06:53 karolherbst: 31 issues on the spec :D
06:54 imirkin: RSpliet: the smaller ones are around API issues... but marek and i have agreed on something that makes sense and pushed it out
06:54 imirkin: RSpliet: there's a bunch of plumbing now, new register files are always fun, etc
06:54 RSpliet: hmm... and gmem is the term used for...? "local memory" in OpenCL terms?
06:55 imirkin: global memory
06:55 imirkin: aka memory
06:55 RSpliet: yes
06:55 RSpliet: right
06:55 RSpliet: okay
06:55 imirkin: lmem = shader invocation-local, smem = shader-local invocation-shared (i guess)
06:56 RSpliet: hmm interesting, because I bet this is a blocker for compute support too...
06:56 imirkin: lmem is where you spill, smem is what you use for crazy locks that aren't directly supported, and gmem = actual memory
06:56 imirkin: well, i'm sure i was doing something horribly wrong
06:57 imirkin: and i'm moderately sure that calim had it working on compute
06:57 imirkin: the ~exact same shader worked for the blob
06:57 imirkin: so...
06:57 imirkin: heh
06:57 RSpliet: right... but that could imply a VM mapping issue
06:57 imirkin: yeah, lots of possibilities
06:57 imirkin: i said "screw it" and moved on to the next task
06:58 RSpliet: :-D
06:58 imirkin: tess seemed more pressing at the time
06:59 imirkin: and fp64
06:59 karolherbst: PCLOCK is all the funny thing around clocks I guess
06:59 karolherbst: whats PNVIO ?
06:59 imirkin: RSpliet: in case you're interested: https://github.com/imirkin/mesa/commits/atomic
06:59 imirkin: although it has largely been superseded by stuff.
07:00 imirkin: karolherbst: http://envytools.readthedocs.org/en/latest/hw/io/pnvio.html
07:00 imirkin: happy reading! :)
07:00 karolherbst: :D
07:01 karolherbst: I am just asking, because I see a lot of PNVIO stuff in my trace
07:01 karolherbst: ohh only reads
07:01 karolherbst: seems unimportant I guess
07:02 karolherbst: imirkin: by the way, did you need some mmts ?
07:03 imirkin: karolherbst: hmmm.... no, i think i'm good
07:03 karolherbst: k
07:03 imirkin: karolherbst: i have blob loaded at work too, so i can do stuff myself now
07:04 karolherbst: okay
07:04 RSpliet: imirkin: stuff :-D
07:05 karolherbst: okay, I have like 7 suspicious regs now :/
07:05 karolherbst: mhh
07:06 karolherbst: I should really check first if the lines are read or writes first
07:06 RSpliet: karolherbst: can you give me a TL;DR on what your current goal is?
07:06 karolherbst: find the voltage thingy
07:06 RSpliet: ah yes, the PWM
07:06 karolherbst: other than that: wait for ben landing a cleanup branch :D
07:06 RSpliet: heh, you'll know when that happens
07:07 RSpliet: if you hear a thud in the middle of the night
07:07 karolherbst: yeah well, waiting for 2 or 3 weeks, so I am good
07:08 RSpliet: preceeded by the sound of Australian swearing about thirty minutes before
07:08 RSpliet: you know it's landed
07:08 karolherbst: mhhh
07:08 karolherbst: PFUSE
07:08 karolherbst: should there be any writes?
07:09 RSpliet: yep, but only to pull a switch that enables you to read other values
07:09 RSpliet: iirc
07:09 karolherbst: ahh
07:09 karolherbst: makes sense
07:10 RSpliet: imirkin: tnx for the pointers btw
07:10 RSpliet: might be useful in between fixing up voltage setting for GDDR3 NVAx, work and receiving pmoreaus G9x GPU
07:14 pmoreau: RSpliet: Just went to the post office, it should arrive around Friday-Saturday. :-)
07:17 karolherbst: what's like the usual use case for PDAEMON.DATA?
07:18 karolherbst: I get the feeling it is kind of important while reclocking here
07:27 RSpliet: pmoreau: you're amazing
07:27 RSpliet: remind me to buy you a beer next FOSDEM if I can make it
07:28 pmoreau: You're welcome! I'll have to buy you at least one for getting reclocking to work on the NVAC. :-)
07:28 pmoreau: So, not coming to XDC?
07:29 RSpliet: haha, well NVAC was easy, no RAM :-P
07:29 pmoreau: :D
07:29 RSpliet: XDC is in Toronto this year, isn't it? I have no idea how I am going to pay for that...
07:29 pmoreau: Sssshhh, you don't need to tell about it.
07:29 pmoreau: Give a talk?
07:29 RSpliet: hahaha, for that I need something to talk about :-D
07:30 pmoreau: Reclocking on first gen Tesla? :)
07:30 RSpliet: meh, well... that means re-using the 2nd gen tesla slides quite literally
07:30 RSpliet: stuff is 90% similar
07:32 pmoreau: Moving to Fermi or Kepler (I don't remember which one is not there), or solving GDDR5 problems?
07:32 RSpliet: heheh, but I didn't... and I don't have the hardware for it :-D
08:06 karolherbst: I think this should contain a complete performance state change with the blob: https://gist.github.com/karolherbst/321a8f69ffe2a19f1a88
08:06 karolherbst: don't see the memory parts though
08:10 imirkin_: mupuf: is the maxwell/g80 still in reator, or has it already been changed?
08:11 mupuf: I have not changed anything in reator for about 4 days
08:11 karolherbst: mupuf: hi :)
08:12 karolherbst: wanna solve the voltage stuff today?
08:17 mupuf: today? you are optimistic! But at least parents and friends are gone
08:17 karolherbst: mhh
08:17 karolherbst: I am not 100% but I think I have a complete recocking cycle with everything in 2000 lines
08:18 karolherbst: at least there is a SLEEP 196.082000ms in front and SLEEP 52.329000ms at the end
08:18 karolherbst: I could also try to solve the gddr5 stuff from this, but then I would have to know which are the interessting bits for this
08:22 RSpliet: karolherbst: the memory parts are the SEQ script
08:22 karolherbst: okay
08:22 karolherbst: mupuf: if you want to take a look: https://gist.github.com/karolherbst/321a8f69ffe2a19f1a88 I will eat something now
08:23 mupuf: ok!
08:23 mupuf:is finishing support for image-size for i965 first :)
08:31 imirkin_: mupuf: should take you all of 2 minutes :p
08:31 RSpliet: but let's be generous, you'll get three
08:31 mupuf: imirkin_: almost, I am down to one stupidit :D
08:31 imirkin_: i'll race you! :)
08:32 imirkin_: [not really, i have actual work to do]
08:32 mupuf: hehe
08:32 mupuf: the way image load store exposes the size is a tiny bit different from how image-size exposes it
08:33 mupuf: for cube maps (counting number of cubes instead of faces) and 1D arrays (the index is in the Y component instead of Z)
08:41 imirkin_: mupuf: yeah, those differences are super-annoying
08:41 imirkin_: and lead to tons of bugs
08:41 mupuf: right
08:51 karolherbst: RSpliet: is there any nice way to verify what nouveau does wrong regarding the SEQ script?
08:53 mupuf: two minutes later: PIGLIT: {"result": "pass" }
08:53 imirkin_: two minutes and lots of piglit-test-editing later...
08:53 imirkin_: heh
08:53 mupuf: ah ah
08:53 mupuf: no changes to piglit :p
08:53 RSpliet: karolherbst: nope, compare values one by one is all there is to it
08:53 mupuf: I wrote and merged the tests a while ago
08:54 mupuf: I also wrote the code for it a while ago
08:54 mupuf: but image load store just landed
08:54 mupuf: and nir also happened
08:54 mupuf: so I had to change my patches a little :p
08:54 mupuf: as in, rewrite the backend entirely
08:55 imirkin_: hehe
08:56 imirkin_: changing compiler backends is fun
08:56 imirkin_: let's do it more often!
08:58 mupuf: yeah baby, yeah!
09:02 pmoreau: imirkin_: Speaking of which, would you have some time to help me generate a load in NV50 IR? O:-) And think I have some troubles with the variables and using mkSym/mkLoad
09:02 pmoreau: s/And //
09:02 imirkin_: pmoreau: i'm not sure what you're trying to do, but i can def attempt to help
09:02 imirkin_: pmoreau: what is the thing that you want to end up with?
09:02 imirkin_: and on what gpu
09:03 karolherbst: RSpliet: I could also execute the SEQ stuff through nvpoke or is it too slow?
09:03 RSpliet: karolherbst: it shouldn't be too slow no, but make sure the script is complete... if the card falls off the bus it just hangs :-P
09:03 pmoreau: imirkin_: On a G86 currently, trying to translate a basic shader from SPIR-V to NV50 IR (simple as "out vec4 color; void main(void) { color[0] = 0.0; }")
09:04 karolherbst: :D
09:04 karolherbst: okay, so when I execute the SEQ stuff and 0f works stable, then the issue is somehwere there I assume
09:04 pmoreau: imirkin_: So, just beginning by translating the load op, before moving to the other ones, and understanding BuilUtil & co.
09:04 karolherbst: at least I know the timings are right
09:04 RSpliet: mmm... beware, there might be a couple of important writes outside the script
09:05 imirkin_: pmoreau: what what are you trying to load?
09:05 karolherbst: mhh
09:06 pmoreau: imirkin_: Apparently "color" into a temp var
09:06 imirkin_: pmoreau: but color is an output, so there's nowhere to load it from
09:07 imirkin_: pmoreau: normally this is handled with nop values
09:08 imirkin_: i.e. you say like r0q = nop, nop, nop, nop; r0 = 0.0; store color, r0q
09:08 imirkin_: these stupid nop values are stupid though... i'd start with something that's not that.
09:10 pmoreau: Hum... It does make sense dunno why I have this load in the generated SPIR-V (SPIR-V output: https://phabricator.pmoreau.org/P15, GLSL shader: https://phabricator.pmoreau.org/P14)
09:11 karolherbst: RSpliet: did you see the values for 0x137390 inside the trace? This reg doesn't change for nouveau and it seems to be changed inside the SEQ stuff
09:12 RSpliet: karolherbst: I haven't looked at your trace in depth sorry
09:12 karolherbst: nvm, will just do the stuff
09:12 RSpliet: I'm busy on different stuff right now ;-)
09:12 RSpliet: and the registers all changed from tesla to fermi
09:12 pmoreau: imirkin_: I'm not sure I followed what r0q is
09:12 pmoreau: (in your example)
09:13 imirkin_: pmoreau: it's a quad-wide register
09:13 pmoreau: Ok
09:13 pmoreau: But can't you store only one reg at a time?
09:15 imirkin_: pmoreau: in nv50 ir, you have the concept of register width
09:15 imirkin_: pmoreau: the isa also allows you to do 2- and 4-wide stores
09:15 imirkin_: and sometimes even 3-wide
09:16 pmoreau: Ok
09:26 karolherbst: :)
09:26 karolherbst: bioshock infinite ultra above 15fps @ fullhd :)
09:27 imirkin_: karolherbst: you got voltage to change?
09:27 karolherbst: no, 0f pstate
09:28 imirkin_: karolherbst: oh neat. i thought that died pretty quickly
09:28 imirkin_: karolherbst: i assume you also moved it up to 8GT/s?
09:28 karolherbst: just executed the PDAEMON SEQ from the blob
09:28 karolherbst: yeah
09:28 karolherbst: could be random that it works now
09:28 RSpliet: 137390 isn't written; it probably contains an indicator stating either RAM training went write or the PLL locked or something
09:28 imirkin_: oh, so the nvidia SEQ worked while the nouveau SEQ didn't?
09:28 karolherbst: but usually it shouldn't work
09:29 karolherbst: RSpliet: okay
09:29 imirkin_: iirc ben claimed that they were the same
09:29 imirkin_: perhaps it was only on certain chipsets (which still indicated troubles)
09:29 karolherbst: yeah
09:30 karolherbst: maybe
09:30 karolherbst: will try other games
09:30 RSpliet: karolherbst: you executed the PDAEMON seq from the blob inside nouveau? that's not supposed to work...
09:30 pmoreau: imirkin_: In the case of the shader I linked, I should first generate a symbol with (FILE_SHADER_OUTPUT, file_index??, TYPE_F32, 0) or maybe a DataArray instead? And then use (loadImm in tmp) + (store tmp in color[0])?
09:30 karolherbst: don't know, 0f seems to be stable for now
09:30 imirkin_: pmoreau: when in doubt, just look at what from_tgsi does
09:31 imirkin_: pmoreau: specifically fetchSrc and storeDst
09:31 RSpliet: karolherbst: have you verified your memory clock speed?
09:31 karolherbst: borderlands with above 40fps
09:31 karolherbst: yes
09:31 pmoreau: imirkin_: I'm trying to, but the handleLOAD looks complicated :D
09:31 karolherbst: usually I got only half the speed
09:31 imirkin_: pmoreau: whoa, handleLOAD? ignore that junx
09:31 karolherbst: game performance is much higher
09:31 imirkin_: pmoreau: LOAD is not at all what you care about here
09:31 imirkin_: pmoreau: nv50_ir_from_tgsi.cpp:fetchSrc and storeDst. those are the only two functions of import to you
09:31 RSpliet: nouveaus PDAEMON formware implements only a fraction of the operations, with different encodings
09:32 RSpliet: *firmware
09:32 pmoreau: imirkin_: Ok, thanks!
09:32 RSpliet: so unless you're running with blob firmware, or Ben rewrote the PDAEMON engine, that couldn't have done anything useful
09:32 imirkin_: pmoreau: the TGSI LOAD opcode is, iirc, to load data from a resource
09:32 imirkin_: pmoreau: which is some mostly-unimplemented thing
09:33 imirkin_: pmoreau: and there's lots of shenanigans wrt resources... just don't worry about that stuff :)
09:33 RSpliet: karolherbst: or... did you instead of uploading a PDAEMON script literally turn this script into a series of nvpoke writes to the registers given?
09:33 pmoreau: imirkin_: Where resource might be what?
09:33 imirkin_: pmoreau: bo
09:33 imirkin_: memory reads/writes
09:33 imirkin_: and/or images
09:33 pmoreau: I'll ignore it then :)
09:33 imirkin_: which isn't something you can even do on nv50 outside of compute shaders
09:34 karolherbst: RSpliet: well, yes, nvapokes
09:34 RSpliet: yes, but did you nvapoke to 0x10a1c4 and then fiddle with the execute bits, or poke directly to the regs?
09:34 karolherbst: I just poked the PDAEMON.DATA writes
09:34 imirkin_: karolherbst: if you can make a script for extracting the SEQ script and converting it into a nvapoke sequence, many people will be rather thankful
09:35 karolherbst: it could be random luck, that it works now
09:35 imirkin_: oh, that's a bit coincidental that that worked
09:35 imirkin_: the data that nvidia pdaemon expects is diff than the nouveua one
09:36 karolherbst: mhh
09:36 karolherbst: changing to 0a literally killed the driver now
09:36 karolherbst: not just nouveau, but intel got also troubles
09:36 karolherbst: "nouveau E[ PMSPPP][0000:01:00.0] unhandled intr 0x00000027"
09:36 karolherbst: I guess this is the script I poke?
09:37 RSpliet: could you paste the sequence of pokes on hastebin-ish website please?
09:37 imirkin_: maybe. PPP is also a falcon engine
09:38 karolherbst: RSpliet: https://gist.github.com/karolherbst/8c02d9c263ebb1188495
09:38 imirkin_: oh haha
09:38 RSpliet: hmm, if that's what you poke, it doesn't execute anything
09:38 imirkin_: yeah there's no way that works
09:39 karolherbst: mhhh
09:39 karolherbst: then just a lot of luck, that two games in a row ran without issues
09:41 karolherbst: it is too bad, that the cat process won't be killed now :/
09:43 karolherbst: ahh I forgot, I also did the 0x10a4a0 0x00005668 thing
09:44 karolherbst: but thats just for the small thingy
09:44 karolherbst: line 253 and later
09:44 karolherbst: have to reboot now anyway
09:44 karolherbst: ohhh no
09:45 karolherbst: the module unloaded
09:53 karolherbst: strange
09:55 karolherbst: it shouldn't work, should it? even after I realod the module and turned the card off 0f still seems to work
09:56 karolherbst: imirkin_: with talso: 2.5GT/s 13fps 8.0GT/s 19fps at 0f
09:56 karolherbst: *talos
10:02 mupuf: hakzsam will be happy to see that perfkit probably landed on linux!
10:02 mupuf: no need to use windows anymore!
10:03 karolherbst: antichamber 72 => 81 fps
10:03 Yoshimo: where are you guys with reclocking on fermi cards`?
10:03 karolherbst: allthought, more like 85
10:04 imirkin_: Yoshimo: nowhere
10:06 karolherbst: well the triangly gputest benchmark is more than doubled now
10:10 karolherbst: ahh right, I wanted to check the metro trace on reator
10:10 karolherbst: anybody on that?
10:10 karolherbst: imirkin_: ?
10:10 imirkin_: not now
10:10 imirkin_: i'll probably try to use it in 6-8 hours
10:12 karolherbst: but I guess I have to tell mupuf first anyway
10:12 mupuf: karolherbst: no no
10:12 mupuf: go for it!
10:12 karolherbst: yeah I would if I could
10:12 karolherbst: seems like the connection is down?
10:12 karolherbst: can't open the website or connect through ssh
10:15 karolherbst: mupuf: can you confirm this?
10:17 imirkin_: hm, i also can't connect to the rpi
10:17 mupuf: yep
10:17 mupuf: I must have changed ip
10:17 mupuf: funny thing, it also looks like I got ipv6!
10:17 mupuf: Yeepee
10:17 imirkin_: hopefully you *also* got ipv4...
10:21 karolherbst: mhh, nice, I use a dns cache here
10:22 karolherbst: when do you know the new one?
10:23 mupuf: I pm-ed you the new IP
10:23 mupuf: imirkin_: yes, I also have a v4 :)
10:26 karolherbst: okay
10:26 karolherbst: website works
10:26 karolherbst: ssh not so much
10:26 imirkin_: mupuf: btw, i'm surprised you didn't get major issues with your imageSize() patch -- perhaps it was auto-casting
10:26 mupuf: yes
10:27 mupuf: probably....
10:27 imirkin_: and also the cube thing is odd, since cube = ivec2 return, cube array = ivec3 return. but coord_components for those is 3/4 i think
10:29 mupuf: is it? I already checked that IIRC
10:29 imirkin_: i would assume so, yes
10:30 imirkin_: mupuf: glsl_type::coordinate_components
10:31 imirkin_: case GLSL_SAMPLER_DIM_CUBE:
10:31 imirkin_: size = 3;
10:31 imirkin_: although amusingly, cube array images also get size = 3
10:31 imirkin_: for maximal confusion ;)
10:32 imirkin_: from the image spec: "gimageCube image, ivec3 coord", "gimageCubeArray image, ivec3 coord"
10:32 imirkin_: which is crazy, but i won't argue :)
10:33 imirkin_: mupuf: so i guess you need more piglit tests
10:37 pmoreau: How can I transform a GLSL shader into TGSI so I can feed it to nouveau_compiler? (I'd like to have a look at a shader in NV50 IR format.)
10:38 imirkin_: pmoreau: stick it into a shader test, use shader_runner
10:38 imirkin_: note that the text parser has sadly not been updated for tessellation, so those won't quite work yet
10:41 pmoreau: Too bad... :/ I wanted to start by them! :p
10:41 pmoreau: Nah, I'll start with something really simple, so some simple frag or vert shader should do it.
10:42 imirkin_: yeah, just giving you a heads-up so you don't get too confused ;)
10:42 pmoreau: ;)
10:43 pmoreau: Where can I find this magic command (shader_runner)? I can't seem to grep/find it in the mesa repo
10:43 imirkin_: esp since tess introduces crazy things like reading outputs
10:43 imirkin_: pmoreau: piglit
10:43 pmoreau: O:-)
10:44 pmoreau: It's true that piglit may run shaders, sometimes...
10:44 imirkin_: pmoreau: there's a shader_runner binary
10:45 imirkin_: pmoreau: which accepts shader_test files... of which there should be tons of examples throughout piglit
10:45 pmoreau: Yep, found it
10:45 pmoreau: Cool
10:50 mupuf: imirkin_: yes, I will check again everything tomorrow
10:53 imirkin_: pmoreau: however that shader that you had originally is a really bad one to start with
10:53 imirkin_: pmoreau: i'd instead do color = vec4(0)
11:41 karolherbst: okay
11:42 karolherbst: imirkin_: the oom issue is also there on a NV50 card on reator
11:42 imirkin_: karolherbst: of course
11:42 imirkin_: i don't see why it wouldn't be
11:44 karolherbst: yeah, I just wanted to verify it
11:45 pmoreau: imirkin_: Yeah, right. Is using local variables even easier than input/output or global ones?
11:46 imirkin_: pmoreau: sure, but then you can't observe the shader. and nouveau will eliminate the code as dead.
11:48 pmoreau: Too much optimisation! :D
11:48 karolherbst: imirkin_: ! on reator the maxwell card is at 4x width
11:49 imirkin_: ooh neat
11:49 karolherbst: x16 cap
11:49 karolherbst: 80585800 reg value
11:49 imirkin_: might be x4 slot
11:50 karolherbst: I have 80089000
11:50 imirkin_: for which reg?
11:50 karolherbst: link_speed_reg
11:50 karolherbst: 0x08c040
11:50 imirkin_: and which one is that? :)
11:50 imirkin_: k
11:51 imirkin_: and i have 40489000 for that one (x8, 2.5GT/s)
11:51 imirkin_: didn't we decide there was a diff link width reg?
11:51 karolherbst: yeah 0x02241c
11:51 imirkin_: 8c080 or whatever?
11:52 karolherbst: ahh
11:52 karolherbst: diff link width
11:52 karolherbst: mhh
11:52 karolherbst: on pre kepler
11:52 imirkin_: right. maxwell is post though :)
11:53 karolherbst: mhh
11:53 karolherbst: the card wasn't happy about relink to higher speed
11:56 karolherbst: imirkin_: kepler or maxwell=
12:00 karolherbst: nice though: LnkCap: Port #0, Speed 8GT/s, Width x16 and LnkSta: Speed 2.5GT/s, Width x4
12:00 karolherbst: the NV50: nkCap: Port #0, Speed 2.5GT/s, Width x16 and Speed 2.5GT/s, Width x16
12:02 mlankhorst: should be better with filling up memory then :)
12:02 karolherbst: mhh
12:02 karolherbst: nv50 uses different regs
12:02 karolherbst: so other stuff on pre tesla
12:03 imirkin_: karolherbst: and doesn't do pcie v2
12:03 karolherbst: it says it does
12:03 imirkin_: karolherbst: nv50 == G80
12:03 karolherbst: okay, lspci reports v1 right
12:03 karolherbst: but it should do v2
12:03 imirkin_: no, it shouldn't
12:03 imirkin_: ;)
12:03 karolherbst: ohhh
12:03 karolherbst: wrong card
12:03 karolherbst: I looked the GS up
12:03 karolherbst: which is G92
12:04 imirkin_: right, G92+ does pcie v2
12:04 imirkin_: G80-G86 don't
12:04 karolherbst: 0x02241c contains 0x81
12:05 karolherbst: which seems to be what I would expect
12:06 karolherbst: "LnkSta: Speed 5GT/s, Width x4" nice
12:06 imirkin_: for the maxwell right?
12:06 imirkin_: now you need maor width
12:06 karolherbst: mhhh
12:06 karolherbst: setting 8.0 upsets the machine
12:07 imirkin_: probably doesn't have pcie 3.0
12:07 karolherbst: like totoally
12:07 karolherbst: yeah
12:07 karolherbst: I guess so
12:07 karolherbst: maybe the reg value changes too
12:08 chrishas: hi, I'm using a quad ppc with nvidia and it can't find a vbios image, this is described I believe in bug #91319, is there any documentation about the relevant source code?
12:08 imirkin_: chrishas: yeah, OF is busted right now :(
12:08 imirkin_: chrishas: or rather, the vbios image loading is busted
12:09 imirkin_: for the images that tend to come in via OF
12:09 imirkin_: chrishas: are you comfortable writing patches for the linux kernel?
12:11 chrishas: imirkin_: not for the kernel but I've patched before, and have been going through the nouveau code,I'm quite happy to test or even try to fix
12:11 imirkin_: chrishas: so basically take a look at nvkm/subdev/bios/pcir.c
12:12 karolherbst: okay, after change the card is indeed at 16x
12:12 imirkin_: what's happening is that something is calling the nvbios_pcirTp function to fill things in
12:12 imirkin_: but it doesn't have that data
12:12 imirkin_: sadly other bits of things rely on things like image_size and so on being filled in
12:12 karolherbst: imirkin_: 80085800 in the reg now
12:13 imirkin_: chrishas: or at least that's my recollection of the issue when i tried to debug it a bit
12:13 karolherbst: 0: max
12:13 karolherbst: 5: 4x
12:13 karolherbst: 4: 8x ?
12:14 karolherbst: how strange
12:14 imirkin_: chrishas: mainly nvbios_imagen in image.c
12:15 karolherbst: this bits are really read only
12:18 imirkin_: karolherbst: how did you manage to get the link width up?
12:18 karolherbst: change slots?
12:19 karolherbst: ohh, didn't tell it here
12:19 karolherbst: yeah, the cards were exchanged
12:19 imirkin_: chrishas: i guess if there's no pcir, you could just return one with image type = 0x70, last = true, and size = the size
12:19 imirkin_: that's assuming there's a reasonable way to get the size out somehow
12:21 karolherbst: okay
12:21 karolherbst: I can't set it to 8.0GT/s though
12:21 karolherbst: I think the board only accepts up to 5.0 or something
12:22 mupuf: well, I have one
12:22 mupuf: and this is my main desktop pc
12:22 mupuf: so ... I won't give root access to you :p
12:23 karolherbst: imirkin_: can you do 8.0 GT/s?
12:23 karolherbst: :(
12:23 karolherbst: what kind of card is there?
12:23 karolherbst: nvapoke is all what I need
12:23 imirkin_: karolherbst: yeah, with a GK208
12:24 karolherbst: nvapoke 0x08c040
12:24 imirkin_: you mean peek?
12:24 karolherbst: ohhh
12:24 karolherbst: right
12:24 karolherbst: peek
12:24 imirkin_: 40489000
12:24 imirkin_: it's x8 2.5GT/s though
12:24 karolherbst: I meant mupuf
12:25 karolherbst: does he has a kepler/maxwell card running?
12:25 mupuf: karolherbst: I have ... no discrete GPU in my new machine
12:25 karolherbst: imirkin_: https://gist.github.com/karolherbst/2dff865f565ebfdf0d0d
12:25 karolherbst: :/
12:25 karolherbst: okay
12:26 karolherbst: the third byte from the left actually shows the width
12:26 karolherbst: pretty sure about that
12:26 karolherbst: but not about the values
12:26 karolherbst: because they are strange
12:26 karolherbst: 4th is clear, we know that already
12:26 karolherbst: 1st ? no idea
12:27 karolherbst: maybe what the card actually supports?
12:27 imirkin_: and of course when you say "byte" you really mean "nibble" right?
12:27 karolherbst: ohh right yes
12:27 karolherbst: number :)
12:27 imirkin_: note that values need not be nibble-aligned
12:27 imirkin_: and in fact often are not
12:27 imirkin_: this stuff is not optimized for hex-readability
12:28 karolherbst: yeah, its okay
12:31 karolherbst: mupuf: is there a trace of the maxwell card somewhere?
12:32 karolherbst: okay found it
12:33 karolherbst: okay, the blob doesn't try to get it up to 8.0 either
12:34 karolherbst: and the information isn't in this reg
12:36 imirkin_: karolherbst: it's probably in the pcie link info
12:36 imirkin_: karolherbst: look at what radeon does... it knows what the highest speed is from ... somewhere
12:48 chrishas: imirkin_: thx, I'll check that out
12:48 karolherbst: okay I think I found it
13:00 karolherbst: imirkin_: do you think its even possible to get this information?
13:01 imirkin_: yes... look at radeon
13:01 karolherbst: someone would expect a source file name pci or something there :/
13:01 imirkin_: sec
13:04 imirkin_: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/r600.c#n4442
13:04 imirkin_: pdev->bus->max_bus_speed
13:09 karolherbst: okay, pdev is like deep kernel stuff
13:10 imirkin_: ;)
13:12 karolherbst: I hope there is some kind of debugfs entry for that
13:18 karolherbst: mupuf: if I want to compile my own nouveau module on reator, how should I do that?
13:18 karolherbst: don't want to tough the existing repositories there if there is somebody working on them
13:25 karolherbst: okay, will give up for today with the relink stuff :/
13:30 pmoreau: Grrr... Is it possible to blacklist xorg modules?
13:31 imirkin_: pmoreau: emerge -C stupid-xorg-module
13:31 pmoreau: Some Gentoo stuff? :)
13:31 imirkin_: yep
13:32 imirkin_: uninstalls the package
13:32 pmoreau: :D
13:32 pmoreau: I'd like to keep the blob installed, just don't want its glx module to load
13:32 imirkin_: eselect set opengl xorg-x11
13:32 imirkin_: oh wait. you're using a retard distro :p
13:33 pmoreau: :p
13:34 pmoreau: Well, I can switch using LD_CONFIG_PATH or whatever it is called, so no libGL.so conflict
13:34 Karlton: all distros suck :)
13:34 pmoreau: Just the glx which is wrong
17:04 Hoolootwo: http://www.rafb.me/results/JBlyu176.html here is a dmesg log of when something in nouveau causes Xorg to restart
17:05 imirkin_: Hoolootwo: seen those before... never figured out what caused them
17:05 Hoolootwo: Xorg log: http://www.rafb.me/results/QztOsK38.html
17:05 Hoolootwo: it's definitely happening much much more often now
17:05 Hoolootwo: in the past two weeks it's happened over 8 times, but before I have got >1 month uptime
17:06 imirkin_: probably some sort of change in workload
17:06 imirkin_: like fancy new ui or something
17:06 Hoolootwo: that's possible, I couldn't really pinpoint it though
17:07 Hoolootwo: hmm well it is running various screensavers, none of which have changed to my knowledge, but I guess I'll pull out a variable there
19:27 marcosps1: imirkin: I'm here :)
19:27 imirkin_: marcosps1: so if you're interested in working on that item
19:28 imirkin_: the first thing to do is get nouveau going on your setup
19:28 imirkin_: it probably already is... try DRI_PRIME=1 glxinfo
19:29 imirkin_: if not, take a look at http://nouveau.freedesktop.org/wiki/Optimus/ for how to get it going
19:30 marcosps1: imirkin_: I beleive its working: https://paste.fedoraproject.org/254152/14393465/
19:30 imirkin_: marcosps1: awesome. so grab the latest git, that should actually expose GL 4.1
19:31 imirkin_: marcosps1: and the thing is that tessellation shaders added some syntax to the way that TGSI is printed (TGSI = intermediate opcodes used to communicate the shader info)
19:31 imirkin_: marcosps1: that the text parsers no longer know how to parse
19:31 imirkin_: marcosps1: specifically look for tgsi_text.c
19:31 marcosps1: imirkin_: I already have compiled/installed the latest mesa...
19:32 imirkin_: marcosps1: well, that glxinfo is from 10.6.3
19:32 imirkin_: marcosps1: it should say 11.0-devel or so
19:32 marcosps1: How, sorry
19:32 imirkin_: by retrieving mesa from git
19:33 imirkin_: also here are some dev notes: http://mesa3d.org/devinfo.html
19:33 marcosps1: This is my head: 02a4fe22b137d4bc8378bedd8319109fd23a50e3
19:33 marcosps1: I'm recompiling right now...
19:33 imirkin_: ok, that's a fine head to have :)
19:34 marcosps1: imirkin_: I just need to so make install, or do I need another step to use the latest driver?
19:34 imirkin_: marcosps1: well, normally i build with --prefix=/home/user/install
19:34 imirkin_: and then i don't overwrite my system isntall
19:34 imirkin_: that way i don't mess things up by accident
19:35 marcosps1: imirkin_: nice tip :)
19:35 imirkin_: i.e. ./configure --prefix=... --etc
19:36 marcosps1: reconfiguring now with --prefix... and --enable-ebug
19:36 marcosps1: *debug
19:36 imirkin_: marcosps1: and make sure you have --with-gallium-drivers=nouveau
19:36 imirkin_: this is what i use: ./configure --prefix=/home/user/install --with-dri-drivers=i965,nouveau --with-gallium-drivers=nouveau,swrast --enable-gallium-llvm --enable-gles1 --enable-gles2 --with-egl-platforms=drm,x11 --enable-texture-float --enable-debug
19:37 imirkin_: note that there's no need for you to include nouveau under dri drivers... i do that for completeness
19:38 marcosps1: imirkin_: Hum... I had a problem with libdrm: Requested 'libdrm_nouveau >= 2.4.62' but version of libdrm_nouveau is 2.4.61
19:38 imirkin_: ah yeah... you need a new libdrm
19:39 marcosps1:is looking to get the code from libdrm from repository...
19:40 marcosps1: imirkin_: You also create a prefix for libdrm too?
19:40 imirkin_: marcosps1: well, i make sure that the system one is the right one ;)
19:40 imirkin_: but the times i've had to install a custom one, yeah, everything goes into the prefix
19:40 imirkin_: i don't want to mess with system stuff unnecessarily
19:40 imirkin_: it just leads to problems
19:41 marcosps1: imirkin_: What distro do you use? Some a nice one like Arch? Fedora still doesnt have the latest libdrm :)
19:42 imirkin_: marcosps1: i use gentoo
19:42 marcosps1:is installing xorg-x11-util-macros
19:43 imirkin_: marcosps1: it's normally easy enough to make your own ebuild against a bumped upstream release
19:43 imirkin_: but sometimse i need my own patches/etc and while i could apply all that as part of the system build, i opt to have that separate
19:43 imirkin_: as it's more likely to just destroy the universe :)
19:44 marcosps1:installing pciaccess-devel....
19:44 marcosps1: imirkin_: you seems to be in touch in graphic drivers all day along :)
19:45 imirkin_: yeah probably shouldn't leave irc open
19:45 marcosps1: imirkin_: https://paste.fedoraproject.org/254155/43934750/
19:45 imirkin_: marcosps1: that seems reasoanble
19:46 marcosps1: imirkin_: Nice :) You're paid to improve Linux graphics?
19:46 imirkin_: no
19:46 imirkin_: which is probably why is houldn't leave irc open :)
19:46 marcosps1: imirkin_: But you seems to be good at it :)
19:47 imirkin_: marcosps1: you should look at some of the bugs i haven't fixed before you say that
19:48 marcosps1: imirkin_: open bugs and dont resolve them doesnt make us bad people :)
19:48 imirkin_: no, but it does make us not good at fixing them
19:49 marcosps1: imirkin_: BTW, I'm not finding an option in mesa to point to my prefix of libdrm...
19:49 imirkin_: marcosps1: yeah, it uses the idiotic pkg config thing
19:49 imirkin_: marcosps1: PKG_CONFIG_PATH=/path/to/thing/lib/pkgconfig:/usr/lib/pkgconfig
19:49 imirkin_: or something along those lines
19:49 imirkin_: god what a horrid idea
19:51 marcosps1: imirkin_: thank you! Now, make -j8 :)
19:54 imirkin_: marcosps1: btw, i updated that trello card with some info
19:54 imirkin_: let me know if it's insufficient or unclear
19:58 marcosps1: imirkin_: Nice, it seems to be very clear. As I said, I'm new to graphics, so I'll need to learn about shader files and things like this :)
19:59 imirkin_: marcosps1: yeah... let me know if you have specific questions
19:59 imirkin_: (including things like "i'm totally confused and have no idea what you're talking about")
20:00 marcosps1: imirkin_: here's the first one: https://paste.fedoraproject.org/254158/34841014/
20:00 imirkin_: marcosps1: LD_LIBRARY_PATH=/path/to/thing/lib
20:00 marcosps1: how, damn...
20:01 imirkin_: otherwise it doesn't load your shiny new mesa lib
20:02 marcosps1: And here it si a new shiny warnings: Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
20:02 imirkin_: don't worry abuot that
20:02 imirkin_: although ideally, install libtxc_dxtn
20:04 marcosps1: imirkin_: Hum... even when I put LD_LIBRARY_PATH, this still complains about tesselation... I'll try to verify what I'm missing here...
20:05 imirkin_: did you make install?
20:05 marcosps1: imirkin_: Yes...
20:05 marcosps1: A minute, I'll run glxinfo with my prefix...
20:05 imirkin_: yeah, was about to suggest that
20:06 imirkin_: oh, haha
20:06 imirkin_: DRI_PRIME=1
20:06 imirkin_: don't forget that one ;) otherwise you get i965
20:06 marcosps1: What is this thing...?
20:06 imirkin_: [which dosen't have tess support yet]
20:06 imirkin_: that's to get the secondary gpu
20:07 marcosps1: imirkin_: This makes sense hehe
20:07 marcosps1: Now it worked...
20:07 imirkin_: (optimus prime = transformers reference)
20:08 marcosps1: imirkin_: damn nerds :)
20:08 marcosps1: imirkin_: https://paste.fedoraproject.org/254160/14393488/
20:09 imirkin_: so this is the tess control shader: http://hastebin.com/raw/kuqosewapa
20:09 imirkin_: ideally you should be able to paste that as input to nouveau_compiler, but... you can't. it'll complain about various idiocy
20:10 imirkin_: initially it doesn't recognize TGSI_CTRL/EVAL as valid headers, which is easily fixed, but the issues go further than that
20:10 imirkin_: (i think!)
20:10 imirkin_: er, i meant TESS_CTRL/TESS_EVAL of course
20:11 marcosps1: imirkin_: Now I got the main idea: we need to get that output and insert into nouveau_compiler, and it should not complain about anything? :)
20:11 imirkin_: yeah, it should spit out the compiled code
20:11 imirkin_: which will, for silly reasons, differ from the compiled code you have there, but will be similar enough
20:11 imirkin_: (the exact input/output mapping is messed up)
20:12 imirkin_: e.g. try pasting the VERT shader
20:12 imirkin_: and note how it works
20:12 imirkin_: http://hastebin.com/nicuxeregi.avrasm
20:13 imirkin_: gr, that pasted wrong
20:13 imirkin_: there's supposed to be a newline after -
20:13 imirkin_: you get the point though
20:14 marcosps1: imirkin_: Yes, I think I got it :)
20:14 marcosps1: So the problem is in the nouveau code inside mesa, that manages these code in a wrong way...?
20:14 imirkin_: actually the shared tgsi parsing code
20:15 imirkin_: although there's a bit to fix up in nouveau_compiler.c as well
20:20 marcosps1: imirkin_: Ok, I got the point!
20:21 marcosps1: imirkin_: Nice, when I create a file, the nouveau_compiler works as expected!
20:27 marcosps1: imirkin_: I'm starting now! Thank you so much for all the help today...
20:36 gnurou: mmm the crash in gk104_fifo_intr_runlist() reported a few days ago kind of makes me nervous... maybe we should just revert that patch
20:36 gnurou: it was for GM20B anyway so reverting it will not hurt anybody
20:36 gnurou: I can carry it in my tree until I figure out what is wrong with it
20:36 imirkin_: gnurou: well, both ben and dave are away
20:37 imirkin_: gnurou: dunno what the deal is
20:37 gnurou: great
20:37 gnurou: we are at -rc6 already, who else can send a push request to Linus?
20:37 imirkin_: gnurou: ask in #dri-devel maybe?
20:37 gnurou: s/push/pull
20:37 gnurou: good idea
20:37 imirkin_: gnurou: probably danvet
20:45 marcosps1: imirkin_: I already found some problem and two of them are solved (recognize TESS_EVAL and TESS_CTRL). I also verified that shader_runner created an empty bracket pair, and it broke the nouveau_compiler..
20:58 imirkin: well, it's really all just tgsi_text that's inconsistent with itself
20:59 imirkin: the way it prints things is kinda what we want, so just have to fix up the parsing bits
22:41 Karlton: strange, my power went out and after my pc rebooted the screen width was too small
22:41 Karlton: even the bios page was screwed up
22:41 Karlton: but after 3 reboots its fine now :S