On 11/28/07, Keith Whitwell <[EMAIL PROTECTED]> wrote:
>
>
> In my ideal world, the entity which knows and cares about cliprects
> should be the one that does the swapbuffers, or at least is in control
> of the process. That entity is the X server.
>
> Instead of tying ourselves into knots trying to figure out how to get
> some other entity a sufficiently up-to-date set of cliprects to make
> this work (which is what was wrong with DRI 1.0), maybe we should try
> and figure out how to get the X server to efficiently orchestrate
> swapbuffers.
>
> In particular it seems like we have:
>
> 1) The X server knows about cliprects.
> 2) The kernel knows about IRQ reception.
> 3) The kernel knows how to submit rendering commands to hardware.
> 4) Userspace is where we want to craft rendering commands.
>
> Given the above, what do we think about swapbuffers:
>
> a) Swapbuffers is a rendering command
> b) which depends on cliprect information
> c) that needs to be fired as soon as possible after an IRQ
> receipt.
>
> So:
> swapbuffers should be crafted from userspace (a, 4)
> ... by the X server (b, 1)
> ... and should be actually fired by the kernel (c, 2, 3)
Well, on nvidia hw, you don't even need to fire from the kernel (thanks to a
special fifo command that waits for vsync).
So I'd love it if going through the kernel for swapbuffers was abstracted by
the interface.
I propose something like:
>
> 0) 3D client submits rendering to the kernel and receives back a fence.
>
> 1) 3D client wants to do swapbuffers. It sends a message to the X
> server asking it "please do me a swapbuffers after this fence has
> completed".
>
> 2) X server crafts (somehow) commands implementing swapbuffers for this
> drawable under the current set of cliprects and passes it to the kernel
> along with the fence.
>
> 3) The kernel keeps that batchbuffer to the side until
> a) the commands associated with the fence have been submitted to
> hardware.
> b) the next vblank IRQ arrives.
>
> when both of these are true, the kernel simply submits the prepared
> swapbuffer commands through the lowest latency path to hardware.
>
> But what happens if the cliprects change? The 100% perfect solution
> looks like:
>
> The X server knows all about cliprect changes, and can use fences or
> other mechanisms to keep track of which swapbuffers are outstanding. At
> the time of a cliprect change, it must create new swapbuffer commandsets
> for all pending swapbuffers and re-submit those to the kernel.
>
> These new sets of commands must be tied to the progress of the X
> server's own rendering command stream so that the kernel fires the
> appropriate one to land the swapbuffers to the correct destination as
> the X server's own rendering flies by.
Yes that was the basis for my thinking as well. By inserting the swapbuffers
into the normal flow of X commands, we remove the need for syncing with the
X server at swapbuffer time.
In the simplest case, where the kernel puts commands onto the one true
> ring as it receives them, the kernel can simply discard the old
> swapbuffer command. Indeed this is true also if the kernel has a
> ring-per-context and uses one of those rings to serialize the X server
> rendering and swapbuffers commands.
Come on, admit that's a hack to get 100'000 fps in glxgears :)
Note that condition 3a) above is always true in the current i915.o
> one-true-ring/single-fifo approach to hardware serialization.
Yes, I think those details of how to wait should be left driver-dependent
and abstracted in user space. So that we have the choice of calling the
kernel, doing it from user space only, relying on a single fifo or whatever.
I think the above can work and seems more straight-forward than many of
> the proposed alternatives.
This is what I want to do too. Especially since in the nvidia case we don't
have the issue of routing vblank interrupts to user space for that.
So, the only issue I'm worried about is the latency induced by this
approach. When the DRM does the swaps you can ensure it'll get executed
pretty fast. If X has been stuffing piles of commands into its command
buffer, it might not be so fast. What this means is that 3D might be slowed
down by 2D rendering (think especially of the case of EXA fallbacks which
will sync your fifo). In that case, ensuring a no-fallback EXA would become
relevant in achieving smooth 3D performance. But at least it solves the
issue of sluggish OpenGL window moves and resizes (/me looks at the nvidia
binary driver behaviour).
Stephane
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
