DirectFB - Home of the pragmatist Roadmap


[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga
Mailing List archive

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

[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga



On Sun, Dec 08, 2002 at 03:59:12AM +0500, Antonino Daplas wrote:
> On Sat, 2002-12-07 at 14:27,
> a40e8119bbddbe7b3d281db117f19b32@interlinx.bc.ca wrote:
> > PIII-600.  That should be fast enough I would think.
> > 
> Depends on the data.  Should be fast enough for VCD like mpegs, but DVD
> needs a very fast bus/CPU.

600 MHz Duron seems to be more than enough. Actually about a year ago I
still used XFree86 dualhead with software color conversion and scaling to
play DVDs/DivXs on my TV. I think it was just enough to get it done. But
any other activity caused dropped frames. Oh the horrors of those months I
suffered with that crap.

> 2. Waiting for vsync does not necessarily mean that the actual flip has
> occured.  If this happens, mplayer may begin writing to the same buffer
> that is in the process of being flipped (can cause shaky display, or
> visual artifacts). In some hardware, there is an extra flag which says,
> "yes a vsync has occured, but I'm only setting this flag after the
> actual buffer flip".  I don't know about matrox hardware, but maybe
> there is one like that.  Or just wait for the end of vblank, since the
> end of vblank occurs some time after the end of vsync.

The docs only say that the changes in the registers become active after
the beginning of the next vertical blank. Nothing else.

> 3.  Direct rendering to video memory might not be the correct way to go,
> not just for reasons 1 and 2.  It's better if the mplayer backend do the
> processing of video to a temporary buffer in system memory, instead of
> directly to video ram (This is how Xvideo does it). At first glance, it
> might seem slower, but mplayer may read the contents of the previous
> buffer (for hardware MC, or whatever?), and video memory reads are
> 10-20x slower than writes.

We aren't writing to video memory. The temporary buffers are allocated
without specifying their location. Thus they are allocated in system
memory and are copied to video memory as needed. And DirectFB should make
sure the the copy is complete before the blit happens.

But perhaps the blit hasn't completed when we flip the buffers... Ok, I
admit to being an idiot. When I added the vsync stuff I copied it straight
out of the fbdev stuff without thinking. The gfxcard_sync(); is totally
misplaced. Obviosly it should be before programming the registers not
after. I attached a patch to fix this.

Brian, please test if it helps.

Dok, I think the BES should need this too so I included it in the patch...

> 4.  Which is why we really need an AGP surface in DirectFB for things
> like video :)

Yes AGP would be nice. We wouldn't have to copy the frames to video memory
before blitting.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
Index: gfxdrivers/matrox/matrox_bes.c
===================================================================
RCS file: /cvs/directfb/DirectFB/gfxdrivers/matrox/matrox_bes.c,v
retrieving revision 1.31
diff -u -r1.31 matrox_bes.c
--- gfxdrivers/matrox/matrox_bes.c	23 Oct 2002 15:58:22 -0000	1.31
+++ gfxdrivers/matrox/matrox_bes.c	7 Dec 2002 21:57:55 -0000
@@ -373,6 +373,7 @@
      dfb_surface_flip_buffers( surface );
      
      bes_calc_regs( mdrv, mbes, layer, &mbes->config );
+     dfb_gfxcard_sync();
      bes_set_regs( mdrv, mbes, onsync );
 
      if (onsync)
Index: gfxdrivers/matrox/matrox_crtc2.c
===================================================================
RCS file: /cvs/directfb/DirectFB/gfxdrivers/matrox/matrox_crtc2.c,v
retrieving revision 1.6
diff -u -r1.6 matrox_crtc2.c
--- gfxdrivers/matrox/matrox_crtc2.c	5 Dec 2002 12:00:52 -0000	1.6
+++ gfxdrivers/matrox/matrox_crtc2.c	7 Dec 2002 21:57:58 -0000
@@ -416,7 +415,6 @@
 {
      int vdisplay = (dfb_config->matrox_ntsc ? 486/2 : 576/2) + 2;
 #ifdef FBIO_WAITFORVSYNC
-     dfb_gfxcard_sync();
      if (ioctl( dfb_fbdev->fd, FBIO_WAITFORVSYNC, &one ))
 #endif
           while ((mga_in32( mdrv->mmio_base, C2VCOUNT ) & 0x00000FFF) != vdisplay)
@@ -454,6 +452,7 @@
 
      mga_out32( mmio, mcrtc2->regs.c2CTL,     C2CTL );
      mga_out32( mmio, mcrtc2->regs.c2DATACTL, C2DATACTL );
+     mga_out32( mmio, mcrtc2->regs.c2OFFSET,  C2OFFSET );
      mga_out32( mmio, mcrtc2->regs.c2HPARAM,  C2HPARAM );
      mga_out32( mmio, mcrtc2->regs.c2VPARAM,  C2VPARAM );
      mga_out32( mmio, mcrtc2->regs.c2HSYNC,   C2HSYNC );
@@ -549,6 +548,9 @@
                return;
      }
 
+     /* interleaved fields */
+     mcrtc2->regs.c2OFFSET = surface->front_buffer->video.pitch * 2;
+
      {
           int hdisplay, htotal, vdisplay, vtotal;
 
@@ -589,9 +591,6 @@
      int            vdisplay     = (dfb_config->matrox_ntsc ? 486/2 : 576/2) + 2;
      int            line;
 
-     /* interleaved fields */
-     mcrtc2->regs.c2OFFSET = front_buffer->video.pitch * 2;
-
      mcrtc2->regs.c2STARTADD1 = front_buffer->video.offset;
      mcrtc2->regs.c2STARTADD0 = front_buffer->video.offset + front_buffer->video.pitch;
 
@@ -614,12 +613,13 @@
                break;
      }
 
+     dfb_gfxcard_sync();
+
      line = mga_in32( mmio, C2VCOUNT ) & 0x00000FFF;
      if (line + 6 > vdisplay && line < vdisplay)
           while ((mga_in32( mmio, C2VCOUNT ) & 0x00000FFF) != vdisplay)
                ;
 
-     mga_out32( mmio, mcrtc2->regs.c2OFFSET, C2OFFSET );
      mga_out32( mmio, mcrtc2->regs.c2STARTADD1, C2STARTADD1 );
      mga_out32( mmio, mcrtc2->regs.c2STARTADD0, C2STARTADD0 );
      mga_out32( mmio, mcrtc2->regs.c2PL2STARTADD1, C2PL2STARTADD1 );

Home | Main Index | Thread Index


directfb.org / Development / Old Archives