On 11/27/07, Thomas Hellström <[EMAIL PROTECTED]> wrote:
>
> 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.
Then why don't you do it in user space ? You could very well do swapbuffers
in the DDX (and cliprects then become a non-issue).
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.
Yes, I don't think we should base the open source DRI design upon specs that
have to be kept hidden. Especially if that hardware is not relevant in any
way technically.
Stephane
-------------------------------------------------------------------------
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
