On Nov 27, 2007 10:41 AM, Thomas Hellström <[EMAIL PROTECTED]> wrote: ... > >>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.
And the kernel will have to somehow communicate the list of clip rects to this firmware/pixel-shader in one way or another, maybe fixing up the code or providing a tri-list buffer or something. I don't really know, but it already sounds too complicated for the kernel, in my opinion. Another problem is that it's not just swapbuffer - anything that touches the front buffer have to respect the cliprects - glCopyPixels and glXCopySubBufferMESA - and thus have to happen in the kernel. > 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. I understand, but I'm starting to doubt the "cliprects and swapbuffer in the kernel" design anyhow. I wasn't going this route originally, but since we already had that in place for i915 vblank buffer swaps, I figured we might as well go that route. I'm not sure the buffer swap from the vblank tasklet is really necessary to begin with... are there benchmarks showing that the irq->userspace latency was too big for this to work in userspace? My proposal back at XDS was to have a shared host memory ring buffer where the X server pushes cliprect changes and clients read it out from there and I still think that's nice design. In a lockless world, the superioctl arguments optionally include the buffer head (as a timestamp) so that the kernel can detect whether a swap buffer batchbuffer is stale. If it is, meaning the X server published cliprect changes, the submit fails and the client must recompute the batchbuffer for the swap command and resubmit after parsing the new cliprects. When rendering to a private back buffer, clip rects aren't relevant and so the superioctl wont have the buffer head field set and the kernel will never discard it. I dunno, maybe I'm just rambling... Kristian ------------------------------------------------------------------------- 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
