Kristian Høgsberg wrote: >On Nov 22, 2007 4:03 AM, Thomas Hellström <[EMAIL PROTECTED]> wrote: >... > > >>There are probably various ways to do this, which is another argument >>for keeping super-ioctls device-specific. >>For i915-type hardware, Dave's approach above is probably the most >>attracting one. >>For Poulsbo, all state is always implicitly included, usually as a >>reference to a buffer object, so we don't really bother about contexts here. >>For hardware like the Unichrome, the state is stored in a limited set of >>registers. >>Here the drm can keep a copy of those registers for each context and do >>a smart update on a context switch. >> >>However, there are cases where it is very difficult to use cliprects >>from the drm, though I wouldn't say impossible. >> >> > >The idea is to keep the cliprects in the kernel and only render double >buffered. The only code that needs to worry about cliprects is swap >buffer, either immediate or synced to vblank. What are the cliprect >problems you mention? > >Kristian > > Hi, Kristian. Sorry for the late response.
What I'm thinking about is the case where the swapbuffers needs to be done by the 3D engine, and with increasingly complex hardware this will at the very least mean some sort of pixel-shader code in the kernel, or perhaps loaded by the kernel firmware interface as a firmware snippet. If we take Poulsbo as an example, the 2D engine is present and open, and swapbuffers can be done using it, but since the 2D- and 3D engines operate separately they are synced in software by the TTM memory manager fence class arbitration code, and we lose performance since we cannot pipeline 3D tasks as we'd want to. If the 3D engine were open, we'd still need a vast amount of code in the kernel to be able to just to a 3D blit. This is even more complicated by the fact that we may not be able to implement 3D blits in the kernel for IP protection reasons. Note that I'm just stating the problem here. I'm not arguing that this should influence the DRI2 design. /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
