In my opinion, direct framebuffer rendering is passe. My
recommendation is to render into system memory, use glDrawPixels
to copy to a GLXDrawable's back buffer and then use glXSwapBuffers
to display the buffer. At least with NVIDIA's binary drivers
this should be faster than direct framebuffer rendering because
rendering to system memory is cached, and glDrawPixels uses DMA,
and if the __GL_SYNC_TO_VBLANK environment variable is set,
glXSwapBuffers will sync to vblank regardless of whether you
are rendering to full screen or a smaller window.
This would be the most portable method, and I would hope
all OpenGL implementations have a way to do vblank-synced
swaps by now.
Mark.
On Sat, 27 Nov 2004 [EMAIL PROTECTED] wrote:
> Is XFree86 w/DGA the only way to achieve high performance direct
> framebuffer rendering (page flipped) without any negative artifacts on
> linux?
>
> I'm using svgalib w/vesa right now for a strictly 8bpp project and the
> only way I've managed to get fast (full) frame rates without tearing or
> flickering is page flipping when linear frame buffer is supported.
> However, it took some vga hacks to reliably sync before the flip (just
> waiting for retrace doesnt work, I duplicated the Abrash-documented method
> reading the vga status port and waiting til it is mid-scan (display enable)
> to set the start address then waiting for retrace to ensure the new offset
> gets a draw in).
>
> It's working fine on all my test machines which it would tear on before I
> implemented the Abrash method (previously I just waited for vertical
> retrace then flipped the page), but now it tears on the only box the old
> approach worked flawlessly on :( It looks like my matrox millenium II
> notices when you change the display start address mid-scan and
> demonstrates this with a regular (every frame) tear. My Abrash books say
> to set the address while the display is enabled as it's supposed to have
> latched onto the last start address for the duration of the scan... grr.
>
> Any suggestions would be much appreciated, I know this is a bit of a
> thread-hijack but it's somewhat related to Eugene's question. I've been
> considering going down the DGA route and adding X to the mix due to
> the problems I've been encountering... I'm just not sure it will solve
> all the problems, and will probably add new ones.
>
> Thanks in advance for any input, I'm sure many of you have had to deal
> with similar issues.
>
>
> On Thu, Nov 25, 2004 at 11:38:17AM -0800, Mark Vojkovich wrote:
> > If you want tearless rendering you should be flipping. Ie. render
> > to a non displayed portion of the framebuffer, then call XDGASetViewport
> > to display it after the copy is finished. See the DGA test apps at
> > http://www.xfree86.org/~mvojkovi/, specifically texture.tar.gz.
> > If the texture and skull demos aren't tearless, there is a bug in the
> > DGA driver support for your card.
> >
> >
> > Mark.
> >
> > On Thu, 25 Nov 2004, Eugene Farinas wrote:
> >
> > > Hi guys! We're developing a DGA program that render full screen at
> > > 1280x1024 16 bpp 15fps the video image read from a sony camera, but we're
> > > experiencing tearing artifacts during rendering. This is a part of the
> > > code that copies the data to the frame buffer:
> > >
> > > void CAM_APP::DisplayImage_NoPartial(unsigned char* offset)
> > > {
> > > register int j;
> > > register unsigned long caddr = (unsigned long) offset;
> > > for(j=0; j<iSize; caddr+=2,j++){
> > > *( (unsigned short*) caddr ) = sTable[g_pBuf[j]];
> > > }
> > > }
> > >
> > > Where the offset is the start of the buffer destination, and g_pBuf is
> > > the data captured from the camera. we've tried copying the data during
> > > vertical resync but we're still experiencing tearing on the image. We're
> > > using an AMD gx2 geode processor w/ 128 mb ram and 8mb vram. I would like
> > > to ask your help in removing the tearing artifacts. Thanks.
> > >
> > > ---
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.797 / Virus Database: 541 - Release Date: 11/15/2004
> > >
> > >
> > > _______________________________________________
> > > Devel mailing list
> > > [EMAIL PROTECTED]
> > > http://XFree86.Org/mailman/listinfo/devel
> > >
> > _______________________________________________
> > Devel mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
