02:02 mlankhorst: imirkin: valgrind doesn't know about the ioctl's libdrm uses, so it assumes everything has to be initialised. :)
02:03 mlankhorst: I guess it could be fixed..
02:07 mlankhorst: either by copying the valgrind preamble from xf86drmMode.c and doing something like VG(VALGRIND_MAKE_MEM_DEFINED(&bla->fd, sizeof(bla->fd)); or setting fd to -1 or something..
02:11 mlankhorst: latter is less code and faster
05:49 pmoreau: ahellquist|work: Hi! I didn't had time to look back at the Optimus code and I most likely won't have time this week either.
05:50 pmoreau: Otherwise I don't think there has been any progress on the HUB_INIT timeout issue. But follow the bug report for more info.
05:50 < ahellquist|work> pmoreau: ok, thanks for the update. I'll check again in a week or so, if it's ok.
05:52 pmoreau: Sure
05:52 pmoreau: I'll ping you on IRC if I have time in between
08:36 mlankhorst: boo, none of the special usb hid drivers are enabled in tegra defconfig :(
08:43 imirkin: why do you need them?
08:43 mlankhorst: to plug in a keyboard and mouse
08:44 imirkin: seems like a pretty far-fetched use-case...
08:44 imirkin: [what keyboard/mouse need more than usbhid.ko?]
08:45 mlankhorst: my logitech
08:46 imirkin: weird. i've never had to do anything fancy.
08:46 mlankhorst: it's a old one
08:46 imirkin: but also my logitech is the original mouseman :)
08:46 imirkin: i've had it for ~15y, might be time for a new one
08:47 mlankhorst: the new one needs yet another driver :P
08:47 imirkin: hehe
09:38 mlankhorst: aw, only 55 fps with glamor
09:39 imirkin: doing what?
09:47 mlankhorst: compiz + glxgears :/
09:54 mupuf: mlankhorst: with vblank_mode=0? :o
10:23 mlankhorst: mupuf: nah with blit to tegra framebuffer
10:24 imirkin: mlankhorst: can't they just share?
10:25 imirkin: why can't they all just get along!
10:25 mlankhorst: oh I did that too..
10:25 imirkin: was that the tiling situation?
10:26 imirkin: should be easy to hack nouveau to output to a tiled buffer
10:26 mlankhorst: tiling's easy, just a hack that's needed..
10:26 mlankhorst: in modesetting and nouveau ddx
10:26 imirkin: right
10:27 mlankhorst: just a sec, I'll know soon if it works with glamor too or not
10:28 mlankhorst: seems to have not blown up, probably
10:29 mlankhorst: bah.. gpu error :(
10:34 mlankhorst: there's something odd going wrong with those page flips..
10:39 mlankhorst: yeah..
10:39 mlankhorst: imirkin: it seems that sharing the random bo's is causing the issue :/
10:40 imirkin: hmmmmm... can you quantify 'issue' in any way?
10:43 mlankhorst: all the random nouveau crashes etc
10:43 imirkin: "crashes"?
10:43 imirkin: what does the kernel say (if anything)?
10:43 mlankhorst: yeah, random errors in dmesg
10:44 imirkin: pastebin?
10:46 mlankhorst: http://paste.debian.net/162961/
10:48 imirkin: mlankhorst: src/nvc0_accel.c: uint32_t class = (pNv->dev->chipset < 0xf0) ? 0xa040 : 0xa140
10:48 imirkin: you probably want to fix that up
10:49 imirkin: i _assume_ it wants a140
10:50 mlankhorst: but mesa does the same there, hmz..
10:50 imirkin: oh right
10:51 imirkin: and gk20a_graph_sclass talks about a040
10:51 imirkin: weird
10:51 imirkin: which is weird coz gk208 uses a140
10:51 imirkin: gnurou: can you confirm whether gk20a has a040 or a140?
10:52 mlankhorst: oh right it's wrong..
10:53 imirkin: should glance at the gk20a android driver...
10:53 mlankhorst: hm on nve4 with p2mf it binds a0b5 to SUBC_COPY
10:53 imirkin: gk20a android drivers say it's a040
10:54 mlankhorst: I wonder why..
10:54 imirkin: but would still be nice to confirm.
10:54 imirkin: a0b5 is the copy engine
10:54 imirkin: p2mf is done by gr (or pfifo)
10:55 mlankhorst: NVAccelInitCOPY_NVE0 should be doing the same, so probably harmless
10:55 imirkin: oh wait, i take that back -- gk20a does have a copy engine
10:55 imirkin: but only one...
10:57 mlankhorst: yeah, harmless though?
10:57 imirkin: yeah, i think so
10:58 imirkin: which doesn't explain why you get nouveau E[ PFIFO][57000000.gpu] PBDMA0: ch 3 [Xorg[2210]] subc 2 mthd 0x0000 data 0x0000a040
10:58 mlankhorst: that happens after the whole gpptr thing
10:58 mlankhorst: usually i get a ton of 0s there first
10:59 imirkin: not sure what GPPTR means -- i guess _some_ sort of complaint re the ptrs in the gpfifo ring
10:59 mlankhorst: neither
11:01 mlankhorst: maybe the tegra dislikes scanning out and operating from nouveau at the same time.
11:03 imirkin: doubtful
11:03 mlankhorst: if I don't use present things work at least..
11:27 mlankhorst: hm, if I use a hack to always have a tiled shared buffer too. :/
12:17 mlankhorst: maybe I should port my vm guard page patch to the tegra nouveau module
12:58 gordan: Is there anyone here who can tell me if it is possible to get the Nvidia BIOS contents out of a GPU without using nvflash? I'm only asking because nvflash chokes on the EEPROM ID on my card.
13:07 pmoreau: gordan: nvagetbios from envytools should be able to get the VBIOS.
13:13 gordan: It seems to be resulting in corrupted extracted images.
13:13 gordan: Regardless of whether a driver is loaded (nvidia or nouveau).
13:14 gordan: nvagetbios -s prom results in a 0 filled file.
13:14 gordan: No extraction method specified (using -s extraction_method). Defaulting to PRAMIN.
13:14 gordan: Attempt to extract the vbios from card 0 (nv117) using PRAMIN.
13:15 gordan: Invalid signature(0x55aa). You may want to try another retrieval method.
13:15 gordan: You may want to run nvagetbios -s prom instead!
13:15 gordan: Vbios extracted but it may be corrupted!
13:15 gordan: Is there a
13:15 gordan: anything else I can try?
18:59 gnurou: imirkin: mlankhorst: confirming that GK20A has a040
19:00 gnurou: GK20A is closer to the GK1 family when it comes to supported classes
19:01 gnurou: the only non-GK1 class it supports is a297, which is unique to it as it seems
19:03 imirkin: gnurou: it also takes fuc5 context switching firmware
19:03 imirkin: which i guess is part of that a297 class
19:05 skeggsb: imirkin: did you manage to get ours to work?
19:08 imirkin: skeggsb: haven't tried it
19:08 skeggsb: i still need to set a dev environment up on my jetson board.. it seems like such a lot of work though
19:08 imirkin: skeggsb: i ran into some sort of trouble.... what was it... hm. i do remember i finally got it to boot up with my kernel
19:08 imirkin: perhaps it got late and i was sleepy :)
19:08 skeggsb: hehe, that's a good reason
19:10 skeggsb:bbiab - lunch
22:08 thelukester: There's a few WebGL conformance tests that fail with nouveau drivers but pass with the proprietary ones. Should I file a bug report?
23:01 Lazik: thelukester : yes
23:15 gnurou: meh, the Android GK20A driver initializes GR in a completely different order from what Nouveau does... why is that
23:18 skeggsb: gnurou: that's rather odd, because we pretty much initialise it (with a couple of differences) the same way as the binary driver
23:18 skeggsb: and.. well. the gk20a driver look largely copy+pasted from resman in parts :P
23:20 gnurou: skeggsb: yeah, I would assume Nouveau follows resman as closely as possible. Yet Android's nvgpu seems to do things in a completely different order
23:20 gnurou: I don't think it is copy/pasted from resman actually
23:21 gnurou:doesn't bother to check since he could not communicate the outcome anyway
23:21 gnurou: that's interesting though, it seems like you can reorder things safely
23:25 skeggsb: well, i obviously haven't seen resman's source, but the sequences and certain parts of the code that clearly will never apply to the k1 made me wonder :)
23:31 gnurou:hopes resman is cleaner than nvgpu
23:35 skeggsb: undoubtedly :P
23:47 gnurou: skeggsb: btw, how do you group the write sequences into packs, and how do you decide to name them?
23:48 gnurou: I mean, if all you have as input is a trace from the blob, how do you infer what belongs where?