On Tue, Sep 01, 2009 at 10:56:18AM -0400, Alex Deucher wrote: > I'm failing to see why we need an overlay ioctl at all. You end up > pulling a relatively large amount of state setup into the drm. Why > not treat the overlay like EXA or textured video or 3D? The overlay > regs are pipelined on most chips so you can program them from command > buffers. Just convert the overlay code in the ddx to use gem/ttm and > build an appropriate command buffer or in the case of gallium add > overlay support in the device specific code and use gem/ttm, etc.. > You could even use it to support GL overlays.
Actually that seems to be the original idea, at least there was already some infrastructure in the driver to support this path. The problem is that at least on intel, the overlay hw is _very_ fragile and you can easily hang the complete chip. To prevent this a delicate dance is needed, carefully sync with the crtc output state. So at least on intel, some overlay support on the kernel side is needed to at least prevent race conditions that may hang the chip. > Alex Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: 079 365 57 48 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
