(no subject)

2004-11-27 Thread Chris
Do you want a cheap Watch?
http://ciq.hensi.com

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: DGA and tearing effects

2004-11-27 Thread swivel
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

2004-11-27 Thread James Wright
   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

2004-11-27 Thread Michel Dänzer
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

2004-11-27 Thread Mark Vojkovich
   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

2004-11-27 Thread Mark Vojkovich
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


gots it all - whatcha needin?

2004-11-27 Thread Abel . Drew
Hello,

I heard you would be curious about a massive dizcounnt on your medz-rx  you 
may purrchaze directly from our fda-manufacturers.
Lower overhead allows us to provide quality drugs at much lower. No dr-script 
required.
Gotothis: http://szfb.approvedthemeasure.com/?a=552io

Truly yours,
Abel Drew 




RE: DGA and tearing effects

2004-11-27 Thread Eugene Farinas
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

2004-11-27 Thread swivel
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