- 06 11月, 2009 3 次提交
-
-
由 Daniel Vetter 提交于
As long as the gpu can keep up, neither the cpu (waiting for gpu) nore the gpu (waiting for vblank to do an overlay flip) stalls. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
Now that the cache flushing of the memory based overlay regs works, we can safely switch off the overlay. Beforehand it was only disabled (like in userspace). Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
This implements intel overlay support for kms via a device-specific ioctl. Thomas Hellstrom brought up the idea of a general ioctl (on dri-devel). We've reached the conclusion that such an infrastructure only makes sense when multiple kms overlay implementations exists, which atm don't (and it doesn't look like this is gonna change). Open issues: - Runs in sync with the gpu, i.e. unnecessary waiting. I've decided to wait on this because the hw tends to hang when changing something in this area. I left some dummy functions as infrastructure. - polyphase filtering uses a static table. - uses uninterruptible sleeps. Unfortunately the alternatives may unnecessarily wedged the hw if/when we timeout too early (and userspace only overloaded the batch buffers with stuff worth a few secs of gpu time). Changes since v1: - fix off-by-one misconception on my side. This fixes fullscreen playback. Changes since v2: - add underrun detection as spec'ed for i965. - flush caches properly, fixing visual corruptions. Changes since v4: - fix up cache flushing of overlay memory regs. - killed require_pipe_a logic - it hangs the chip. Tested-By: diego.abelenda@gmail.com (on a 865G) Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> [anholt: Resolved against the MADVISE ioctl going in before this one] Signed-off-by: NEric Anholt <eric@anholt.net>
-