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