Re: DGA and tearing effects
Out of interest what method are you using to wait for the vblank in DGA? To vsync properly in DGA I have been having to perform a page flip (asking for it to be done next retrace), then waiting for this operation to complete; XDGASetViewport(Xdisplay, Xscreen, 0, Xdga.db * Xdga.height, XDGAFlipRetrace); while (XDGAGetViewportStatus(Xdisplay, Xscreen)); Would like to compare various methods to see if this is the way to go... Note that Xdga.db toggles between 0 and 1 every frame flip, to enable proper page flipping, as we always copy to the hidden page, then use the above code to flip and wait. Thanks, James On Sun, 28 Nov 2004 13:21:18 +0800 Eugene Farinas [EMAIL PROTECTED] wrote: Thanks for your help guys! I've managed to remove the tearing on our DGA program but the consequence is that the rendering speed went from a max of 15 fps (w/o vsync) to 9 fps (w/ vsync). Initially, the image reading from the camera and the copying to the framebuffer was in a single thread (w/c was still displaying tearing artifacts even with vsync), but now I've separated them into two threads, one thread reads the image from the camera, and the other writes to the framebuffer. The read thread reads the image from the camera, does some image manipulation on the image (converts 8-bit image to 16-bit), and copies the image on a temporary buffer. The write thread copies the temporary buffer to the framebuffer by using memcpy. My task now is to move up the fps to a respectable 13 to 14 fps max. Eugene M. Fariñas Design Engineer, Eazix, Inc. B.S. Applied Physics, UPLB -Original Message- From: Mark Vojkovich [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 6:23 AM To: [EMAIL PROTECTED] Subject: Re: DGA and tearing effects On Sat, 27 Nov 2004, James Wright wrote: My understanding is that flat panels do not scan a screen as a CRT does, so there is no vertcial blank period to perform a page flip. They do have a refresh rate of usually around 60Hz, but his is simply how aften the pixels are able to switch states, or how often the display is refreshed from the panels backbuffer. In a DGA mode if you try waiting for a vblank with a flat panel, then the page flip is performed immediately, instead of waiting for anything. The panels own circuits decide when to change the display anyway, so anything you try to do yourself is moot. If I am incorrect, then I apologise... That's sortof the correct idea for when using the panel's VGA interface. For the VGA interface, the panel is not necessarily refreshing at the rate coming through the VGA connector. For DVI, the panel is refreshing at the rate coming through the DVI connector, but this doesn't necessarily correspond to the timings programmed in the VGA registers. At least on the hardware I've worked on, the VGA timing merely correspond to the input to the flat panel scaler in the graphics chip, not the output going to the panel. Mark. On Sat, 27 Nov 2004 13:37:01 -0500 Michel Dänzer [EMAIL PROTECTED] wrote: On Sat, 2004-11-27 at 16:40 +, James Wright wrote: About a year ago I was using DGA for my games graphics library. I was told by various people that using DGA was not the way to go. At first I thought this was nonsense, as you can't get vsync using the more standard XPutImage method (and get tearing). However, all changed when I bought a laptop with TFT screen. Problem is, there is no vsync on the new LCD/TFT monitors! There is in my experience, at least if you use the panel's native mode. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ 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 --- Incoming 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 --- 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
Re: DGA and tearing effects
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
Re: DGA and tearing effects
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; jiSize; 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
Re: DGA and tearing effects
About a year ago I was using DGA for my games graphics library. I was told
by various people that using DGA was not the way to go. At first I thought this
was nonsense, as you can't get vsync using the more standard XPutImage method
(and get tearing). However, all changed when I bought a laptop with TFT screen.
Problem is, there is no vsync on the new LCD/TFT monitors! So you get tearing
anyway! The result is I now draw to an XImage and use XPutImage (using SHM is
avaiable), and just forget about vsyncing. Still got a DGA mode if people wanna
try it, but on LCD screens its pointless... (my findings anyway)...
On Sat, 27 Nov 2004 09:19:04 -0600
[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; jiSize; 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
Re: DGA and tearing effects
On Sat, 2004-11-27 at 16:40 +, James Wright wrote: About a year ago I was using DGA for my games graphics library. I was told by various people that using DGA was not the way to go. At first I thought this was nonsense, as you can't get vsync using the more standard XPutImage method (and get tearing). However, all changed when I bought a laptop with TFT screen. Problem is, there is no vsync on the new LCD/TFT monitors! There is in my experience, at least if you use the panel's native mode. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA and tearing effects
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; jiSize; 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
Re: DGA and tearing effects
On Sat, 27 Nov 2004, James Wright wrote: My understanding is that flat panels do not scan a screen as a CRT does, so there is no vertcial blank period to perform a page flip. They do have a refresh rate of usually around 60Hz, but his is simply how aften the pixels are able to switch states, or how often the display is refreshed from the panels backbuffer. In a DGA mode if you try waiting for a vblank with a flat panel, then the page flip is performed immediately, instead of waiting for anything. The panels own circuits decide when to change the display anyway, so anything you try to do yourself is moot. If I am incorrect, then I apologise... That's sortof the correct idea for when using the panel's VGA interface. For the VGA interface, the panel is not necessarily refreshing at the rate coming through the VGA connector. For DVI, the panel is refreshing at the rate coming through the DVI connector, but this doesn't necessarily correspond to the timings programmed in the VGA registers. At least on the hardware I've worked on, the VGA timing merely correspond to the input to the flat panel scaler in the graphics chip, not the output going to the panel. Mark. On Sat, 27 Nov 2004 13:37:01 -0500 Michel Dänzer [EMAIL PROTECTED] wrote: On Sat, 2004-11-27 at 16:40 +, James Wright wrote: About a year ago I was using DGA for my games graphics library. I was told by various people that using DGA was not the way to go. At first I thought this was nonsense, as you can't get vsync using the more standard XPutImage method (and get tearing). However, all changed when I bought a laptop with TFT screen. Problem is, there is no vsync on the new LCD/TFT monitors! There is in my experience, at least if you use the panel's native mode. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ 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
RE: DGA and tearing effects
Thanks for your help guys! I've managed to remove the tearing on our DGA program but the consequence is that the rendering speed went from a max of 15 fps (w/o vsync) to 9 fps (w/ vsync). Initially, the image reading from the camera and the copying to the framebuffer was in a single thread (w/c was still displaying tearing artifacts even with vsync), but now I've separated them into two threads, one thread reads the image from the camera, and the other writes to the framebuffer. The read thread reads the image from the camera, does some image manipulation on the image (converts 8-bit image to 16-bit), and copies the image on a temporary buffer. The write thread copies the temporary buffer to the framebuffer by using memcpy. My task now is to move up the fps to a respectable 13 to 14 fps max. Eugene M. Fariñas Design Engineer, Eazix, Inc. B.S. Applied Physics, UPLB -Original Message- From: Mark Vojkovich [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 6:23 AM To: [EMAIL PROTECTED] Subject: Re: DGA and tearing effects On Sat, 27 Nov 2004, James Wright wrote: My understanding is that flat panels do not scan a screen as a CRT does, so there is no vertcial blank period to perform a page flip. They do have a refresh rate of usually around 60Hz, but his is simply how aften the pixels are able to switch states, or how often the display is refreshed from the panels backbuffer. In a DGA mode if you try waiting for a vblank with a flat panel, then the page flip is performed immediately, instead of waiting for anything. The panels own circuits decide when to change the display anyway, so anything you try to do yourself is moot. If I am incorrect, then I apologise... That's sortof the correct idea for when using the panel's VGA interface. For the VGA interface, the panel is not necessarily refreshing at the rate coming through the VGA connector. For DVI, the panel is refreshing at the rate coming through the DVI connector, but this doesn't necessarily correspond to the timings programmed in the VGA registers. At least on the hardware I've worked on, the VGA timing merely correspond to the input to the flat panel scaler in the graphics chip, not the output going to the panel. Mark. On Sat, 27 Nov 2004 13:37:01 -0500 Michel Dänzer [EMAIL PROTECTED] wrote: On Sat, 2004-11-27 at 16:40 +, James Wright wrote: About a year ago I was using DGA for my games graphics library. I was told by various people that using DGA was not the way to go. At first I thought this was nonsense, as you can't get vsync using the more standard XPutImage method (and get tearing). However, all changed when I bought a laptop with TFT screen. Problem is, there is no vsync on the new LCD/TFT monitors! There is in my experience, at least if you use the panel's native mode. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer ___ 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 --- Incoming 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 --- 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
Re: DGA and tearing effects
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? 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
RE: DGA and tearing effects
We're using an AMD gx2 geode processor for our embedded project. I've modified
the code in order to sync the framebuffer copying with the vertical refresh.
void CAM_APP::DisplayImage_NoPartial(unsigned char* offset)
{
register int j;
register unsigned long caddr = (unsigned long) offset;
unsigned char *buffer = g_bBuf;
for(j=0; jiSize; buffer+=2,j++){
*( (unsigned short*) buffer ) = sTable[g_pBuf[j]];
}
gfx_wait_vertical_blank();
memcpy((void*)offset, (void*)g_bBuf, IMG_SIZE);
}
Where g_bBuf is a temporary buffer, buffer holds the start address of g_bBuf,
g_pBuf holds the image received from the camera, and gfx_wait_vertical_blank()
waits for vsync to end. We've greatly minimized the tearing artifacts during
rendering but the framerate slowed down from 15 to 11 fps.
Eugene M. Fariñas
Design Engineer
Eazix, Inc.
BSAP, UPLB
-Original Message-
From: Mark Vojkovich [mailto:[EMAIL PROTECTED]
Sent: Friday, November 26, 2004 7:51 AM
To: [EMAIL PROTECTED]
Subject: Re: DGA and tearing effects
Some OpenGL drivers can do vblank synced flips (NVIDIA's can).
glDrawPixels + glXSwapBuffers should be faster than a DGA implementation.
Even XPutImage should be faster than a DGA implementation, but like
you've pointed out, there's no way to sync XPutImage to vblank.
DGA is frequently broken in drivers so it's good to use something
else.
Mark.
On Thu, 25 Nov 2004, James Wright wrote:
Isn't DGA mode being phased out? I been using XPutImage and the XVidMode
extension to provide fullscreen instead. Only problem being you have no
control over when the image is actually copied to the display, so tearing
results, unless someone else here would like to enlighten me...
On Thu, 25 Nov 2004 11:38:17 -0800 (PST)
Mark Vojkovich [EMAIL PROTECTED] 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; jiSize; 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
---
Incoming 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
---
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
RE: DGA and tearing effects
Continuation...
We didn't use OpenGL or implemented page flipping because we don't want to make
big modifications on the code in such a very short time.
Eugene M. Fariñas
Design Engineer
Eazix, Inc.
BSAP, UPLB
-Original Message-
From: Eugene Farinas
Sent: Friday, November 26, 2004 3:58 PM
To: [EMAIL PROTECTED]
Subject: RE: DGA and tearing effects
We're using an AMD gx2 geode processor for our embedded project. I've modified
the code in order to sync the framebuffer copying with the vertical refresh.
void CAM_APP::DisplayImage_NoPartial(unsigned char* offset)
{
register int j;
register unsigned long caddr = (unsigned long) offset;
unsigned char *buffer = g_bBuf;
for(j=0; jiSize; buffer+=2,j++){
*( (unsigned short*) buffer ) = sTable[g_pBuf[j]];
}
gfx_wait_vertical_blank();
memcpy((void*)offset, (void*)g_bBuf, IMG_SIZE);
}
Where g_bBuf is a temporary buffer, buffer holds the start address of g_bBuf,
g_pBuf holds the image received from the camera, and gfx_wait_vertical_blank()
waits for vsync to end. We've greatly minimized the tearing artifacts during
rendering but the framerate slowed down from 15 to 11 fps.
Eugene M. Fariñas
Design Engineer
Eazix, Inc.
BSAP, UPLB
-Original Message-
From: Mark Vojkovich [mailto:[EMAIL PROTECTED]
Sent: Friday, November 26, 2004 7:51 AM
To: [EMAIL PROTECTED]
Subject: Re: DGA and tearing effects
Some OpenGL drivers can do vblank synced flips (NVIDIA's can).
glDrawPixels + glXSwapBuffers should be faster than a DGA implementation.
Even XPutImage should be faster than a DGA implementation, but like
you've pointed out, there's no way to sync XPutImage to vblank.
DGA is frequently broken in drivers so it's good to use something
else.
Mark.
On Thu, 25 Nov 2004, James Wright wrote:
Isn't DGA mode being phased out? I been using XPutImage and the XVidMode
extension to provide fullscreen instead. Only problem being you have no
control over when the image is actually copied to the display, so tearing
results, unless someone else here would like to enlighten me...
On Thu, 25 Nov 2004 11:38:17 -0800 (PST)
Mark Vojkovich [EMAIL PROTECTED] 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; jiSize; 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
---
Incoming 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
---
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
---
Incoming 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
---
Outgoing mail is certified
Re: DGA and tearing effects
What mechanism are you using to sync to vertical retrace?
Also, the for loop you provide is not going to be very fast code
for copying the buffer, at least not in my experiences. Try using
something like memcpy() for the bulk of the copying, perhaps a memcpy()
invocation per horizontal line. Maybe even when waiting for vert
retrace your copy is simply too slow and cannot finish before the gun starts
up again. Perhaps try drawing to off-screen video memory and then
waiting for vert retrace before you page flip to the off-screen memory?
Cheers.
On Thu, Nov 25, 2004 at 03:38:56PM +0800, 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; jiSize; 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
Re: DGA and tearing effects
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; jiSize; 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
Re: DGA and tearing effects
Isn't DGA mode being phased out? I been using XPutImage and the XVidMode
extension to provide fullscreen instead. Only problem being you have no control
over when the image is actually copied to the display, so tearing results,
unless someone else here would like to enlighten me...
On Thu, 25 Nov 2004 11:38:17 -0800 (PST)
Mark Vojkovich [EMAIL PROTECTED] 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; jiSize; 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
DGA and tearing effects
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; jiSize; 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
