[07:36] "Hello, world!\n" [11:25] does pre-sandy bridge even allow snooped access? [11:36] woops wrong channel :) [13:16] .. running kernel with kmemcheck is scary [22:11] RAOF: great success :D [22:11] dmabufmgr seems to work [22:12] i adapted the code for nouveau to use the hardware for waiting [22:21] which turned into a 800 line patch :s [22:54] Huge success! [22:57] RAOF: yeah was just tracking 2 bugs today, first one was in my test program with how I marked intel relocations. I needed a noop for testing, but it ended up executing the address as command, second one was probably due to some stuff not firing in idle stait, and workaround was adding some busyloops [22:58] eg schedtool ... 'while true; do true; done' on all cpus [22:59] :) [23:01] http://people.canonical.com/~mlankhorst/prime-sync/ full patchset, probably best to use drm-intel-next-queue git tree [23:02] i wanted to grab the delayed fput git tree too, but it hangs early on in boot [23:04] a hacky max_cstate=0? ;) [23:05] I may have to get you to give me some pointers for what needs to be done on the radeon side. That might be a fun project at 2am when Zoë's crying :) [23:07] RAOF: oh I could do it easily myself [23:08] RAOF: anyhow you need to create a read-only mapping and add a wait-ge op for a dma-buf [23:09] well, either read-only or userspace inaccessible.. [23:10] ive glanced through the documentation so I know r600 supports the operations at least [23:12] but the easiest case is adapting i915 [23:13] oh btw, DON'T create a gem object for your sync bo, it will deadlock [23:14] besides that radeon uses ttm so there's no real need for involving gem [23:28] RAOF: night [23:28] Good night :)(