On 09/01/2009 02:06 PM, Daniel Vetter wrote: > 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.
This. This so hard it hurts. > 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. Then have an Intel-specific bit of code. Do a batchbuffer checker/relocator/munger; we've got one for Radeons, and I'm sure you guys need to do something similar for relocating BOs. ~ C. ------------------------------------------------------------------------------ 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
