DirectFB - Home of the pragmatist Roadmap

[directfb-dev] Re: [PATCH] G450/G550 detection for CRTC2
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-dev] Re: [PATCH] G450/G550 detection for CRTC2

> The bad thing is that I can't have many windows open when I start mplayer
> or DirectFB can't allocate video memory when blitting.

Bah!  That sucks.

> I think the surface
> manager should throw out less used stuff but this doesn't seem to happen
> consistently. Perhaps the other windows are really busy somehow or video
> memory may be too fragmented. This is problem happens @ 32bpp

Which at 640x480 is about 9MB.  Just under a third of the memory on
the card.

> with a 32MB
> card. With a 16 MB card I can't even run XDirectFB @ 32bpp since there
> won't be enough memory left for the CRTC2 buffers.

Wow.  Remember when 1MB of video memory was lots and 2MB was a dream?  :-)

> It allows mplayer to do something useful while we wait for the vsync.

Right.  I figured that.  But how much does it do while the thread
waits for vsync though?  Does it actually even get to decoding an
additional (third right?  One being displayed, a second in the back
buffer which will become displayed when the vsync happens and the
third in main memory which gets blitted to the back buffer when the
vsync happens) frame?

Which makes me wonder... the video card does the flip between the back
buffer and the "front" buffer automatically, right?  The process of
flipping to the back buffer (the new front buffer) is simply pointing
the card at the address space of the back buffer and telling it to
display that buffer when the vsync happens (every other vsync though,
because each buffer holds both odd and even fields), right?  So we
have two chunks of memory (buffers) on the card and we just keep
pointing the display engine on the card to the two chunks, alternating
one after the other, round robbin-like.  Do I have it correct so far?

We are also decoding MPlayer frames into main memory and copying them
to the back buffer rather than decoding them directly into the back
buffer.  Still right so far?  The waiting for vsync in MPlayer is just
waiting for the card to be done with the current buffer and switch to
the new buffer so that MPlayer can copy the in-main-memory buffer to
the back buffer and decode another frame to the in-main-memory buffer.

Do I have it all correct?

I really should sit down one day and dissect the actual a/v playing
engine of MPlayer.

> Unfortunately this doesn't help as much as I'd like. Flip() waits
> for the
> card to become idle before flipping

What do you mean "idle"?  Is there a good reason to wait for it to be
idle?  What exactly does Flip() do?  I thought it's only purpose was
to block the calling process until the vsync interrupt arrives (i.e.
to let the process know that the next frame is being displayed).

> and since we do Blit() and Flip() in
> this order the blit will keep the card busy for some time. The wait for
> idle function polls the status register in a tight loop which keeps
> my CPU busy. Perhaps it would work better with a dual CPU machine.



Brian J. Murrell

Attachment: pgp00025.pgp
Description: PGP signature

Home | Main Index | Thread Index / Development / Old Archives