On Sun, 28 Nov 2004 [EMAIL PROTECTED] wrote:
> The problem with this is my project targets older laptops, it's a engine
> management system tuning suite and alot of these car guys have junk bin
> laptops sitting in their cars (pentium class) with a wide array of graphic
> chipsets and displays. I don't think anyone will be using a accelerated
> glx system, won't find any nvidia's here. I chose VESA because it seems
> to be the easiest way to get higher than vga resolutions reliably on
> the target hardware... going this route tosses acceleration capabilities
> out the window hence the strive to use direct framebuffer rendering (at
> least when linear framebuffer is available).
>
> It may be passe, but it's the fastest method (and oh so beautiful) I've
> managed
> to wring out of my p133 development workstation.
>
> Does this glx method provide great results even on Xvesa non-nvidia
> systems?
I don't have a good survey of OpenGL implementations.
You might ask one of the DRI or Mesa-related lists if vsynced
buffers swaps are very common, or still rare. And also, what kind
of glDrawPixels performance they get. I would guess not much attention
has been paid to old pre-AGP machines such as yours though,
so maybe OpenGL is not such a great solution for such old hardware.
Mark.
>
> Also, I was not aware that the flat panels had this vertical retrace
> issue... one of my test machines has a 18" flat panel and it was tearing
> like crazy when I just did a vga_waitretrace() before doing the page
> flip. However it should be noted, that after switching to Abrashes
> method of polling the display enable bit before performing the flip and
> then waiting for retrace has eliminated all tearing on the flat panel
> display... this was tested in 640x480 800x600 1024x768 and 1280x1024
> the native resolution of the panel. It has however, caused some tearing on
> my 133 w/matrox on a CRT where before there was none... this I suspect
> is a matroxism though.
>
> Thanks for the replies, this thread has been prettty informative thus
> far.
>
> Cheers.
>
> On Sat, Nov 27, 2004 at 01:56:44PM -0800, Mark Vojkovich wrote:
> > 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
> _______________________________________________
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
