00:00 imirkin: what's "cal" btw?
00:02 skeggsb: "call" as in "indirect push buffer", from way way back when i thought it was a fantastic idea to use CAL (like the NV_vp opcode) instead of call..
00:03 imirkin: hehe
00:03 imirkin: i see you've reconsidered your position? :)
00:03 skeggsb: it's not exactly the most obvious choice in the world
00:04 imirkin: no, not exactly
00:08 draven: imirkin: i've read confirmations from multiple people that on nvidia-blob, this: "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }" in xorg.conf solves the tearing on kepler. is this of any enlightement?
00:23 draven: Thank you for the support yet again people! Me and my sadness are going to sleep :C Have a great day/night!
00:23 gnurou: mlankhorst: so should we understand that you got X running on Jetson?
00:55 airlied: skeggsb: http://paste.fedoraproject.org/198415/49250414/
00:56 airlied: though I suspect running piglit would have the same result
01:16 mlankhorst: gnurou: yeah, just having some issues with glxgears, doesn't sync to vblank yet :p
01:19 mlankhorst: needs some careful xorg-server hackery
01:20 mlankhorst: I had an issue when zero'ing out scanout, but it seems that I was using an older libdrm that didn't have the coherent flag
01:26 gnurou: mlankhorst: wow, that's great!
01:26 gnurou: so is it using the tegradrm driver with the Nouveau DDX?
01:27 mlankhorst: yeah
01:27 gnurou: awesome! will need to carve some time out to give it a try
01:27 mlankhorst: I had xeyes running :p
01:27 gnurou: what more do you need ;)
01:27 mlankhorst: I might make a ppa, works better for my workflow
01:27 mlankhorst: oh I want the full ubuntu desktop running on it..
01:28 mlankhorst: vblanked and all
01:28 gnurou: that would be great, means we would be able to compete with L4T
01:29 mlankhorst: the only remaining stuff has to do with the present extension, which allows you to flip an arbitrary pixmap to the screen
01:32 mlankhorst: since nouveau has no screens connected, it doesn't sync to vblank. Code has to become smarter to deal with it..
01:33 airlied: mlankhorst: that seems like thr wrong way to run things btw
01:33 airlied: display should be the DDX and rendering offloaded?
01:48 mlankhorst: airlied: perhaps, but how do you want to accelerate xrender then?
01:53 mlankhorst:was mostly following how the blob deals with it
01:57 mlankhorst: I'm not sure modesetting exposes the sinkoffload flag..
02:01 mlankhorst: airlied: hm that might be something I'll test tonight, see if adding sinkoffload to modesetting and setting DRI_PRIME=1 will work..
02:02 mlankhorst: and maybe making mesa smarter in case of DRI3, so DRI_PRIME=1 won't need to be set explicitly
02:03 mlankhorst: although the check would be pretty much 'is DRI_PRIME unset and is the default device using swrast?'
08:29 Lazuris: Wesh
08:32 Lazuris: C'est mort ici ? :o
11:14 fathercorby: What exactly goes on in this channel?
11:16 imirkin: see topic
11:19 fathercorby: I guess a better question would be what do you guys need help with?
11:19 imirkin: the biggest missing resource is developer time
11:19 pepee: hi. is there a way to disable nouveau from the kernel command line (other than nomodeset)?
11:20 imirkin: pepee: nouveau.modeset=0
11:20 imirkin: pepee: that should avoid disabling modesetting for, say, i915
11:21 pepee: ok, thanks imirkin
11:21 imirkin: [i'm guessing that was your issue with using nomodeset?]
11:22 fathercorby: Well the reason i am here is i have to nomodeset to use debian. I want to help with whatever i can
11:22 pepee: well, it's not my issue, someone is asking me for help... his pc has a AMD APU and an nvidia card, and he's getting a black screen somewhere in the process of running ubuntu from a live cd
11:22 imirkin: fathercorby: what gpu do you have?
11:22 fathercorby: Nvidia 360m
11:23 imirkin: fathercorby: hmmmm... what does 'lspci -nn -d 10de:' say?
11:23 imirkin: i'm looking for a GT21x number
11:23 fathercorby: Its gts215
11:23 imirkin: you mean GT215?
11:23 fathercorby: Yes sorry
11:23 imirkin: does it have gddr5 vram perchance?
11:24 fathercorby: Not sure i can let you know in about 2 hrs
11:26 fling: Is not opencl supported yet?
11:26 imirkin: fling: nope
11:27 buhman: fling: you haven't finished your opencl patchset yet?
11:27 fling: imirkin: is it supported with any free driver?
11:27 fling: buhman: no :<
11:27 imirkin: fathercorby: getting logs from a nouveau boot would be useful, as well as a description of what issues you see when you don't use 'nomodeset'
11:27 imirkin: fling: r600 and radeonsi drivers both support opencl
11:27 imirkin: (opencl 1.1, with modest parts of opencl 1.2)
11:27 fling: Are they worknig without proprietary firmware?
11:27 buhman: fling: http://dri.freedesktop.org/wiki/GalliumCompute/
11:28 fling: Thanks for the info.
11:28 imirkin: fling: i don't think any r600/radeonsi card can work without proprietary firmware on linux at all
11:28 fathercorby: I get big pixel blocks when i try to startx
11:28 imirkin: all the command processor/etc microcode is just uploaded as a blob
11:28 fling: I hope it will be replaced by openatom eventually.
11:28 imirkin: fathercorby: hm. well, getting dmesg logs from a boot without nouveau disabled would be instructional
11:29 imirkin: fling: seems unrelated... atom is the bios stuff, right?
11:29 fathercorby: Ok i can get that when i get home from work
11:29 imirkin: fling: i'm talking about the command processor/etc stuff
11:29 fling: imirkin: but it also replaces vbios.
11:29 imirkin: fling: ok, but that's the least of your concerns afaik
11:29 fling: heh
11:30 imirkin: fling: but i'm far from a radeon expert, you can ask for more details in #radeon. perhaps there's a wiki that explains the situation.
11:38 fathercorby: Anything else i can do imirkin?
11:39 imirkin: fathercorby: also what kernel are you using? GT215 should be fairly well supported (and has been for a while)
11:39 imirkin: the only long-standing issue has been GT215's with GDDR5 vram, but those are extremely rare
11:40 imirkin: however for those, the gpu would lock up immediately, wouldn't get so far as to display "big pixel blocks" :)
11:40 imirkin: but even those cards should be somewhat fixed now
11:40 imirkin: they still have issues, but not what you describe... what you describe is like a missing copy engine that we don't properly detect
11:41 imirkin: once you're in front of the computer i may have things for you to try. if i'm not around, file a bug at bugs.freedesktop.org and i'll leave some instructions
11:41 fathercorby: Ok cool
11:46 hasenov: hello, what is the status of the Maxwell NVidia card?
11:47 hasenov: i have the NV117 (GM107)GeForce GTX (750, 750 Ti) card
11:47 hasenov: and i cannot run XOrg with it
11:48 hasenov: according to https://bbs.archlinux.org/viewtopic.php?id=191566, the only way to successfully run XOrg is to do an MMIO trace
11:48 imirkin: hasenov: ben just pushed open ctxsw fw to his repo
11:48 imirkin: hasenov: afaik no one (other than him) have tested it
11:48 imirkin: hasenov: http://cgit.freedesktop.org/~darktama/nouveau
11:48 imirkin: you can build it as an out-of-tree style module against a 4.0-rc tree
11:49 huehner: imirkin: did want to give it a spin also on my 960 but no time yet for that (assuming it will work even unmodified there)
11:49 imirkin: hasenov: alternatively you do the mmiotrace method, see http://nouveau.freedesktop.org/wiki/NVC0_Firmware/
11:49 imirkin: huehner: won't help you
11:49 imirkin: huehner: GM20x has its own very special set of problems
11:49 imirkin: huehner: namely that we can't upload firmware to it :)
11:50 imirkin: it has that stupid security stuff unfortunately
11:50 huehner: that signed microcode topic?
11:50 imirkin: yup
11:50 huehner: is that all maxwell had that already
11:50 huehner: any news on that front?
11:50 imirkin: only GM20x... GM10x doesn't
11:50 imirkin: no news that i'm aware of
11:50 RSpliet: no, see ftp://download.nvidia.com/open-gpu-doc/Falcon-Security/1/Falcon-Security.html
11:50 huehner: i only remember post several month back about they'll look into that (publishing firmware)
11:51 imirkin: that's about all there is
11:52 imirkin: although curiously i just noticed in that document, "they may use virtual memory exclusively"
11:52 pepee: how come there is not a lot of info about openatom?
11:52 hasenov: imirkin: i tried to do MMIO trace and it wouldnt work, said something about a CPU lock
11:52 imirkin: pepee: because you're asking in the wrong channel? that's a radeon thing, no?
11:52 pepee: ah, heh, sorry :P
11:53 pepee: was reading the logs and got confused
11:53 imirkin: hasenov: mmiotrace turns off all (but one) cpu's
11:53 imirkin: hasenov: if it can't do that, it'll complain loudly and fail
11:54 hasenov: imirkin: yes, thats what it was doing i think, it locked up my comp and I had to cold reboot it
11:56 hasenov: imirkin: i dont know how to build an out-of-tree style module, is there any tutorial or anything you could point me to?
11:59 imirkin: hasenov: clone the tree i pointed you at and type "make". it's a pretty intense process :p
11:59 imirkin: hasenov: actually, "cd drm; make"
13:15 mlankhorst: why does xorg-server have to make cross-device sharing so hard?
13:35 airlied: mlankhorst: yeah I hadn't considered 2d accel actually
13:35 airlied: probably want to use glamor
13:35 airlied: I suppose it depends on what method has less overhead
13:36 airlied: mlankhorst: the X server is complicated because you forgot to send patchse to fix it
13:37 fathercorby: Imirkin it says gt215 gts 360m 10de:0cb1 rev a2
13:41 mlankhorst: airlied: :-( how silly of me
13:42 airlied: mlankhorst: does this mean we can get fence synced rendering cross-gpu? :)
13:42 mlankhorst: if you feel like it..
13:42 mlankhorst: but now that I made fences more generic everyone wants android fences for explicit sync :P
13:42 mlankhorst: including me tbh
13:43 airlied: yeah I suppose explicit sync makes more sense long term
13:43 airlied: so I'm not sure why you think the X server makes things difficult
13:43 mlankhorst: mostly because I don't see any calls that would allow me to flip a pixmap on a different crtc
13:44 airlied: because we don't have the concept of per-crtc pixmaps
13:45 airlied: there was talk of adding those at one point
13:45 airlied: also the concept of flipping is pretty alien to the core X server
13:45 mlankhorst: yeah..
13:46 specing: X is pretty alien
13:47 airlied: the code I wrote to override a crtc pixmap with a slave one is as close as we got
13:47 airlied: and that was just to make unredircted full screen 3D apps work better
13:47 airlied: over PRIME
13:49 mlankhorst: shrug, I guess I can test if modesetting can work with offload sink
13:50 mlankhorst: and then the user can choose between 2d accelerated (optimus) or 3d accelerated (prime)
13:50 mlankhorst: :D
13:50 airlied: the main problem with offload sink with dri2 is it had to do unaccel copies
13:50 airlied: but with glamor that should be fine
13:51 mlankhorst: I don't even have glamor for main device :P
13:51 airlied: yes, so dri2 will make it do a back->front copy using the cpu
13:52 airlied: probably best having the tegra as an output slave alright
13:52 airlied: like the USB devices
13:52 imirkin: fathercorby: logs would be good
13:52 imirkin: airlied: can we just roll back the patches that made X complicated? :)
13:53 imirkin:ducks
13:53 mlankhorst: airlied: don't care about dri2, nouveau has dri3 support..
13:53 imirkin: mlankhorst: last time i tried, ddx crashed when i tried to use dri3
13:53 imirkin: (with your exa stuff)
13:53 airlied: imirkin: you mean the initial import? :)
13:53 fathercorby: Kernel version is 3.2.0
13:53 mlankhorst: imirkin: yeah missed a vram_size check, v2 worked :P
13:53 imirkin: airlied: yes ;)
13:53 fathercorby: Ill get logs then
13:54 mlankhorst: and you also need to add some COHERENT stuff..
13:54 airlied: mlankhorst: well dri3 has to copy to screen at some point as well
13:54 imirkin: fathercorby: nah, don't bother
13:54 imirkin: fathercorby: 3.2.0 is _ancient_
13:54 mlankhorst: airlied: what if you run a compositor?
13:54 imirkin: i think it came out in 2012 or so
13:54 fathercorby: So update kernel image?
13:54 imirkin: fathercorby: yeah, i'd recommend at least kernel 3.10 or later... with kernel 3.19 you should have reclocking support for your GPU
13:57 airlied: mlankhorst: the final composited image will be copied then
13:58 airlied: but you can't run an offloaded compositor
13:58 mlankhorst: ah :/
13:58 airlied: since offloading requires a compositor
13:58 mlankhorst: ok in that case my setup is the correct one then..
13:58 airlied: so I suspect your initial plan was better than mine
13:58 mlankhorst: I think the best solution is to ignore gpu screens altogether and have nouveau handle it..
13:59 mlankhorst: but I really wish it was useful outside of my own usecase too
14:00 imirkin: mlankhorst: i'm talking about using dri3 on a regular desktop gpu... i did that a month or two ago, not long after the last of your patches landed
14:00 mlankhorst: ah k
14:00 mlankhorst: wasn't crashing here..
14:00 imirkin: mlankhorst: either the ddx crashed, or the client hung... don't remember which tbh
14:00 imirkin: but it definitely very clearly didn't work at all
14:00 imirkin: perhaps i was trying gallium-nine at the time, since it required dri3
14:00 imirkin: in any case, it definitely left a sour taste in my mouth
14:01 tobijk: imirkin: offloading with dri3 works fine, maybe its just the ddx
14:01 mlankhorst: imirkin: there were some bugs with xorg-server and present too
14:02 imirkin: mlankhorst: ah, maybe that was it, i was on an older xserver (1.15)
14:02 imirkin: mlankhorst: perhaps just shut the thing off for x server versions that were known to be b0rked
14:02 mlankhorst: imirkin: yeah but what if they backport patches?
14:03 imirkin: mlankhorst: then they can backport patches to nouveau as well
14:03 mlankhorst: I think disabling it for 1.15 is fine then
14:04 mlankhorst: some of the xorg-servers had the present fixes backported too
14:04 imirkin: actual released ones, or distro patches?
14:05 mlankhorst: some of the present ones mention backporting to 1.16.2, so..
14:05 imirkin: so make that a minimum? dunno.
14:05 imirkin: i'd much rather dri3 be disabled unnecessarily
14:05 imirkin: than people getting *WEIRD* issues that are next to impossible to diagnose
14:05 mlankhorst: I guess 1.16.3 is minimum, can check for that..
14:06 imirkin: my solution to the problem was --disable-dri3 in mesa
14:06 imirkin: but not everyone has that luxury
14:06 mlankhorst: you can always add LIBGL_DRI3_DISABLE to env
14:06 imirkin: yeah. or i can --disable-dri3 :)
14:06 imirkin: i hate having permanent env vars like that
14:07 imirkin: just causes problems coz i forget about them
14:07 mlankhorst: or prevent dri3 in xorg.conf..
14:07 imirkin: ooh, didn't know about that one
14:07 imirkin: but if i were to do that, i would have had to restart X
14:08 imirkin: at which point i would have just gone back to the pre-dri3 ddx
14:08 imirkin:restarts X monthly at most
14:08 mlankhorst: lucky you :p
14:08 mlankhorst: nouveau seems less stable for me
14:08 mlankhorst: mostly kernel panic though
14:08 mlankhorst: so it might not actually be nouveau
14:08 imirkin: uptime: 44 days, current X has been running as long
14:09 imirkin: or maybe you run max-texture-size in parallel
14:09 mlankhorst: haha
14:09 imirkin: i avoid doing piglit runs in general
14:09 imirkin: i do very little GL stuff
14:09 mlankhorst: seriously I tried so many things, never found out why..
14:09 imirkin: i don't actually exercise nouveau that much on a regular basis
14:10 imirkin: beyond the stuff in the ddx, which is pretty simple and well-tested
14:15 mlankhorst: I wish reclocking worked :p
14:15 imirkin: mlankhorst: i thought it did for you
14:16 imirkin: or you know another way you can make that wish come true is... do the work to make it happen ;)
14:16 mlankhorst: I've looked at the stuff, it's not exactly trivial
14:17 imirkin: not exactly
14:17 imirkin: but you may be able to reuse some of the work ben's done for kepler now
14:17 imirkin: both the specifics and the overall approach
14:18 imirkin: but it'd probably be like a 3-month long project, esp if you didn't do it full time
14:18 mlankhorst: I have evenings, in which I don't exactly have much focus
14:19 mlankhorst: going to read then sleep, nn :)
14:20 imirkin: see ya
14:57 Karlton: say I did an apitrace that is 2095 frames long, now how would I trim it down to the last few frames?
14:58 imirkin: there's a apitrace trim, you can pass it a frame number
15:01 Karlton: I did apitrace trim --exact --frames=1500-2095 but then it did not replay
15:02 imirkin: hm, dunno what --exact does
15:02 Karlton: it works if I trim the end frames off
15:04 Karlton: maybe I should not use --exact but it seemed to have been running the trim for a long time without it
15:04 imirkin: yeah, it takes *forever*
15:32 tobijk: Karlton: you still try to trace the pinkish texture?
15:35 Karlton: tobijk: No, I am trying to trace a different game that has issues that could be cause by the same problem
15:36 tobijk: Karlton: ah, ithink i finally nearing myself to the glcall
15:41 imirkin: tobijk: if you can get it down to a specific frame (ideally draw call) in a trace, i can take a look at it to see if it brings me any ideas why kepler might be broken
15:42 tobijk: i have narrowed it down to call 134756-134924 in frame 321
15:42 imirkin: well, only glDraw* calls do anything
15:42 tobijk: between those at least the fb gets pink
15:42 imirkin: so figure out which draw it is
15:42 imirkin: you can use qapitrace to help with that :)
15:43 tobijk: yeah im tracing along nouveau and intel with it right now
15:44 imirkin: ooh fun, call list!
15:44 imirkin: that's a nice potential source of issues!
15:45 tobijk: if qapitrace would just hand me the states in between :/
15:45 imirkin: there are none
15:45 imirkin: that's the first draw after the working one
15:45 imirkin: so it's the draw @134924
15:45 tobijk: yep
15:48 imirkin: tobijk: looking at the surfaces for that draw
15:48 imirkin: which color attachment is the purple one?
15:49 tobijk: that my problem, it does not hand me the extra info you should get with "lookup state" :/
15:49 imirkin: double-click on it
15:49 tobijk: i'm not and idiot :P
15:50 tobijk: maybe i should checkoutout a stable version of apitrace though...
15:52 imirkin: this is what it looks like for me: http://i.imgur.com/EwkuBE9.png
15:53 tobijk: yeah i cant get the info on that call, on some others i got it easily
15:53 tobijk: ill compile 6.1, give me some minutes
15:53 imirkin: weird
16:04 tobijk: ah now
16:04 tobijk: its attachment0
16:04 imirkin: what about texture7?
16:04 imirkin: is that one all purple?
16:04 imirkin: for me, visually attachment0 == texture7
16:04 imirkin: perhaps they're a little different but definitely very similar
16:05 tobijk: 7 is pink as well
16:05 imirkin: ok, so that's the problem
16:05 imirkin: need to figure out where it comes from
16:08 tobijk: yeah i can query the states now, going to do that for a while i guess :)
16:14 tobijk: meh, that texture is from the huge frame 320 :/ that may take a while
16:15 imirkin: divide and conquer
16:25 tobijk: oom killed ~-~
16:27 imirkin: conquered! :)
17:17 tobijk: imirkin: 131716 @0 glDrawElements(mode = GL_TRIANGLES, count = 7374, type = GL_UNSIGNED_INT, indices = NULL)
17:18 tobijk: draws the second part of the scene and it brings a wrong color
17:18 tobijk: scene = texture7
17:18 imirkin: cool
17:18 imirkin: what frame?
17:18 tobijk: 320
17:20 imirkin: ok, so in that draw, attachment0 is purple?
17:20 imirkin: but gl_texture7 is not?
17:21 tobijk: no texture7 is purple from there on
17:21 tobijk: 131715, the texture is not rendered completely
17:21 tobijk: which 131716 does
17:25 tobijk: imirkin: http://i.imgur.com/c5AwRn7.png -> http://i.imgur.com/YmLIm1H.png
17:25 imirkin: hm i see
17:25 imirkin: they're the same texture
17:25 imirkin: i wonder if it's sampling and rendering at the same time
17:25 imirkin: that'd be unfortunate