This seams like a no brainer to me. The Xserver! It would be a good
place to intercept vblanks, if it dosen't allready, and connects to
clients and card any way. A little more beef for the ?2d driver? or X
server to keep track of pending swaps for all dri clients, but if it were
GLX it would be
I'd prefer the kernel implementation. If you do the swapping in
user-space you require a context switch to each client that needs to
swap. However, you need to react to the vblank interrupt as fast as
possible in order to finish the swap during the vertical retrace.
If that turns out to be too
Dose most DACs have dublebuffering or do you realy only have from the
start of the vtrace to the end to do your update? If you can having from
the start of the vtrace untill the end of the next vtrace todo your
swaping is optimal.
- If you only have one FB. Pad each, or some, commands with
On Tue, 2004-03-09 at 05:28, Ian Romanick wrote:
- Keep the queue of pending swaps in the user-space driver. Add an
ioctl for the kernel to deliver a signal to the app / driver when a
specified vblank has occured.
FWIW, that wouldn't need to be added, it's been in place for a while. :)
-
Mike Mestnik wrote:
This seams like a no brainer to me. The Xserver! It would be a good
place to intercept vblanks, if it dosen't allready, and connects to
clients and card any way. A little more beef for the ?2d driver? or X
server to keep track of pending swaps for all dri clients, but if it
Felix Kühling wrote:
I'd prefer the kernel implementation. If you do the swapping in
user-space you require a context switch to each client that needs to
swap. However, you need to react to the vblank interrupt as fast as
possible in order to finish the swap during the vertical retrace.
I hadn't
On Tue, 2004-03-09 at 17:42, Ian Romanick wrote:
Mike Mestnik wrote:
This seams like a no brainer to me. The Xserver! It would be a good
place to intercept vblanks, if it dosen't allready, and connects to
clients and card any way. A little more beef for the ?2d driver? or X
server to
On Tue, 2004-03-09 at 17:50, Ian Romanick wrote:
Michel Dnzer wrote:
On Tue, 2004-03-09 at 05:28, Ian Romanick wrote:
- Keep the queue of pending swaps in the user-space driver. Spawn a
second thread that *only* performs swaps. It blocks on a futuex or
similar the gets uped each time a
Around 18 o'clock on Mar 9, Michel Daenzer wrote:
BTW, the composite extension will require buffer swaps to be handled by
the X server (as well as per-context buffers, ...), so we might as well
start planning how to get there. :)
Ah, Composite isn't as X-centric as it might first appear...
On Tue, 2004-03-09 at 19:18, Keith Packard wrote:
Around 18 o'clock on Mar 9, Michel Daenzer wrote:
BTW, the composite extension will require buffer swaps to be handled by
the X server (as well as per-context buffers, ...), so we might as well
start planning how to get there. :)
Ah,
Around 19 o'clock on Mar 9, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote:
My point is that the kernel can't do it on its own, as only the
composite manager knows what the final result should look like.
True enough. Of course, the compositing manager will likely double buffer
the whole screen so
Keith Packard wrote:
Around 18 o'clock on Mar 9, Michel Daenzer wrote:
BTW, the composite extension will require buffer swaps to be handled by
the X server (as well as per-context buffers, ...), so we might as well
start planning how to get there. :)
Ah, Composite isn't as X-centric as it might
On Mon, 08 Mar 2004 20:28:55 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
[snip]
per-window backbuffers and a bunch of other stuff. Actually, given
enough memory, each time a swap happened the driver could just allocate
a new backbuffer to render to. When the swap happened the old
backbuffer
Felix Kühling wrote:
On Tue, 09 Mar 2004 16:25:43 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Tue, 2004-03-09 at 12:29, Felix Kühling wrote:
I've been thinking about this before and I got stuck at a more practical
problem. Maybe my thoughts are a bit Radeon-centric though. The problem
is that
Felix Kühling wrote:
On Mon, 08 Mar 2004 20:28:55 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
[snip]
per-window backbuffers and a bunch of other stuff. Actually, given
enough memory, each time a swap happened the driver could just allocate
a new backbuffer to render to. When the swap happened
On Tue, 09 Mar 2004 16:25:43 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Tue, 2004-03-09 at 12:29, Felix Kühling wrote:
[snip]
We discussed this before and it was concluded that there needs to be
some sort of high priority command queue. IIRC certain hardware (was it
i8xx?) has such
On Tue, 2004-03-09 at 19:44, Ian Romanick wrote:
Excluding the pageflip case, in the current setup we have an
offscreen backbuffer that needs to be copied to the frontbuffer. This
happens completely under the control of the 3D driver. With composite,
are both the backbuffer and the
On Tue, 2004-03-09 at 22:39, Felix Khling wrote:
Sorry for spamming ... I just had another idea. Can't we use MMIO for
buffer swapping?
No. MMIO register writes to FIFO'd registers while the CP is busy are a
sure recipe for a chip lockup, because sooner or later the FIFO will
overflow. So
I'd like to discuss / revisit what it will take to implement
asynchronous swapping. By this I mean glXSwapBuffers returns
immediately even if the driver needs to wait several frames (due to the
swap interval or whatever) to actually do the swap.
I've thought of a couple ways to do this, but they
On Mon, Mar 08, 2004 at 08:28:55PM -0800, Ian Romanick wrote:
| ...
| - Implement the wait in the kernel. The driver calls a new swap ioctl
| that takes the 'target' frame as a parameter. The kernel mainains a
| queue of pending swaps that is checked each time a vblank interrupt is
| handled.
20 matches
Mail list logo
