On Tue, 2004-03-09 at 20:57, 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:
> > >
> > > We discussed this before and it was concluded that there needs to be
> > > some sort of high priori
On Tue, 2004-03-09 at 22:39, Felix KÃhling 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
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 th
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?)
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
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 tha
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
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
> backb
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 fi
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
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. :)
>
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 17:50, Ian Romanick wrote:
> Michel DÃnzer 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 upe
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
> >
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 t
Michel DÃnzer wrote:
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
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 i
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 you have rendering commands queued in the ring buffer. When the
> vblank IRQ occurs you
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. :)
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 enuff
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 com
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 b
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. ..
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 a
24 matches
Mail list logo