Re: [Dri-devel] problems with CVS head and i810
Dave Airlie wrote: Removing the Option XvMCSurfaces 6 from my XF86Config file seems to make everyone a bit happier again... will do some more testing tomorrow to make sure this is what was causing it .. and I meant glxgears from RH7.3.. hands were ahead of brain yesterday.. Well for me this means I'll lose the line above - not even sure why it was in there.. Sounds like there are some problems with memory allocation that have sneaked into the i810 driver. This was always tricky code and may have rotted over time (eg with the addition of direct-rendering xv ) Keith --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] no keyboard control over X server ?
On Tue, Dec 17, 2002 at 01:12:32PM +0100, Martin Spott wrote: On Tue, Dec 17, 2002 at 10:58:27AM +, Alan Hourihane wrote: I can't stop the X server any more by hitting ctrl-alt-backspace and I can't switch to any virtual console with alt-F? Mistake on my end ? No, a side effect. You have to install the new xkbcomp stuff from the XFree86 CVS. Either that or easier for now to start with Xserver with XKB disabled. You can do that with -kb at startup or do it in the XF86Config with Option XkbDisable. Thanks. Disabling KBD extensions is not an option because it disables the backslash on my keyboard :-/ Then use xmodmap (the traditional way) or go fetch the new xkbcomp stuff from XFree86 CVS. Alan. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 notes issues
Keith Whitwell wrote:
Andy Ross wrote:
ATI blows you guys away in glxgears. I see 38% faster frame rates
with their drivers.
Actually what gears does most is glClear and glXSwapBuffers, with a
small amount of glCallList. You can speed up swapbuffers by turning
page flipping on in the XF86Config - there are some correctness issues
which is why it isn't always on. ATI have proprietry hw interfaces
for implementing glClear that we'll never have access too and this is
a big hit
It looks like the display list optimizations would be the bigger win.
The 38% number is close to the asymptote (I saw about 32%) as the
window size approaches infinity. Shrinking the window down to just a
handful of pixels gives a 2x advantage to ATI.
You also don't exhibit a texture border bug that the ATI drivers have
We fallback on some texture border cases
OK, after more reading of the spec and Brian's comments and writing a
quick glut test, I think I've got a handle on what's going on. It
turns out that outside of software Mesa and the ATI linux drivers, no
one in the free world interprets the GL_CLAMP wrap mode correctly.
Everyone else, including the DRI drivers, uses it as a synonym for
GL_CLAMP_TO_EDGE. As it happens, FlightGear (at least) depends on
this misinterpretation.
[For those interested, this also turns out to be the source of the
performance issue I mentioned with the ATI drivers. In trying to be
correct, they end up taking a slow path with GL_CLAMP that halves the
frame rate in FlightGear when close to a runway. Changing all the
usage to GL_CLAMP_TO_EDGE got almost a 2x speedup.]
So technically, there is a DRI compliance issue here. I've attached
the little test that I wrote to illustrate the problem. It draws four
adjacent checkerboard quads and cycles between the wrap modes on key
presses. With GL_CLAMP, you should see dark stripes along the quad
edges where the black border color is sampled. Software mesa gets
this right, but the r200 driver doesn't.
But since no one else does this correctly, and fixing it breaks
FlightGear, my vote is to ignore the issue. :)
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in conflagrations. They only get better one by one.
- Sting (misquoted)
#include stdio.h
#include GL/gl.h
#include GL/glu.h
#include GL/glut.h
#define TSZ 32
unsigned char tex[TSZ*TSZ*3];
int state = 0;
/* Tile the texture using four exactly adjacent quads */
void display()
{
glClear(GL_COLOR_BUFFER_BIT);
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex2f(-0.5, -0.5);
glTexCoord2f(0, 1); glVertex2f(-0.5, 0.0);
glTexCoord2f(1, 1); glVertex2f( 0.0, 0.0);
glTexCoord2f(1, 0); glVertex2f( 0.0, -0.5);
glTexCoord2f(0, 0); glVertex2f(-0.5, 0.0);
glTexCoord2f(0, 1); glVertex2f(-0.5, 0.5);
glTexCoord2f(1, 1); glVertex2f( 0.0, 0.5);
glTexCoord2f(1, 0); glVertex2f( 0.0, 0.0);
glTexCoord2f(0, 0); glVertex2f( 0.0, 0.0);
glTexCoord2f(0, 1); glVertex2f( 0.0, 0.5);
glTexCoord2f(1, 1); glVertex2f( 0.5, 0.5);
glTexCoord2f(1, 0); glVertex2f( 0.5, 0.0);
glTexCoord2f(0, 0); glVertex2f( 0.0, -0.5);
glTexCoord2f(0, 1); glVertex2f( 0.0, 0.0);
glTexCoord2f(1, 1); glVertex2f( 0.5, 0.0);
glTexCoord2f(1, 0); glVertex2f( 0.5, -0.5);
glEnd();
glutSwapBuffers();
}
/* Cycle the texture border mode when the user presses a key */
void keyboard(unsigned char k, int mx, int my)
{
if(state == 0) {
printf(GL_CLAMP_TO_EDGE\n);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
} else if(state == 1) {
printf(GL_CLAMP\n);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
} else if(state == 2) {
printf(GL_REPEAT\n);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
}
if(++state = 3)
state = 0;
glutPostRedisplay();
}
/* Generate a 33%/66% gray mipmapped checkerboard. */
void init()
{
int i, j;
for(i=0; iTSZ; i++) {
for(j=0; jTSZ; j++) {
unsigned char* pix = tex + 3*(i*TSZ + j);
pix[0] = pix[1] = pix[2] = (i+j)1 ? 170 : 85;
}
}
gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGB, TSZ, TSZ, GL_RGB,
GL_UNSIGNED_BYTE, tex);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glEnable(GL_TEXTURE_2D);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
}
int main(int argc, char** argv)
{
glutInit(argc, argv);
glutInitDisplayMode(GLUT_DOUBLE |
Re: [Dri-devel] R200 notes issues
On Tue, Dec 17, 2002 at 09:59:57AM -0800, Andy Ross wrote: So technically, there is a DRI compliance issue here. I've attached the little test that I wrote to illustrate the problem. It draws four adjacent checkerboard quads and cycles between the wrap modes on key presses. With GL_CLAMP, you should see dark stripes along the quad edges where the black border color is sampled. Software mesa gets this right, but the r200 driver doesn't. Heh...look at demos/texwrap.c in Mesa. This does basically the same thing, but it enumerates all of the advertised modes, even the various mirror modes. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] lockups w/ AGP 4x
On Fri, Dec 13, 2002 at 10:45:45PM -0500, [EMAIL PROTECTED] wrote: Using the texmem-0-0-1 branch from CVS and enabling AGP 4x in XF86Config-4 causes X to lock upon startup. If I have my xinitrc setup to run Quake III alone, I first get the bare black and white X background and cursor for about a second and then some strange lines move across a black screen; I can't switch VT's and ssh'ing in doesn't work. If I have my xinitrc setup to run windowmaker, however, I can ssh in. I then try to kill X via an HUP, but that doesn't work and I try kill -9. At that point, ssh stops working. If it helps at all, the texmem-0-0-1 branch I was previously using (from Nov. 1) works fine with AGP 4x. My system is a Mobile P-4 1.8 ghz with a 16 MB 4x AGP M7. Sorry if this message belongs in the users board. Do you have fast-writes enabled? Does it work at AGP 2x? I'll see if I can look into this in the next few days, but I've got a bunch of other stuff already on my plate. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 notes issues
On Tue, Dec 17, 2002 at 01:52:05PM -0800, Andy Ross wrote: Ian Romanick wrote: Heh...look at demos/texwrap.c in Mesa. This does basically the same thing, but it enumerates all of the advertised modes, even the various mirror modes. Silly me. Why bother trying to learn about something and share the knowlege when I could have just... what, exactly? :) Accept my profuse apologies for the hubris of posting the thing. But I can't apologize for writing it. Uh...I wasn't trying to berate you or anything. I only mentioned it in case you had any plans to improve or enhance your test. Rather than doing more work on the test you wrote, you would probably find it more fruitful to make enhancements to the test burried in the Mesa source. In any case, it might be interesting to find out which other cases the DRI drivers don't match the ATI drivers. It would also be interesting to figure out which of those cases are SW fallbacks in the ATI drivers. In the DRI code, the cases that are SW fallbacks are the cases when the 1-pixel texture border is used. IIRC, you can toggle the 1-pixel texture border in the Mesa test with the b key. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [PATCH] i810 cleanup
Nice one, that gets rid of my tearing - thanks Matthew, it works except now I get some jumpiness on my screen when a new texture is coming on, I've got 5 rotating reels of 4 textured quads and when the new ones are about to come on the top of the reel it seems to jump a bit... Not sure if the fullscreen would help here.. I need to time each render and see if this one takes a lot longer than the others.. Dave. Sottek, Matthew J said: The easiest way to get rid of tearing is to make the ring buffer wait before the back-front blit. This is a very simple mechanism that will work even for windowed 3d, and if you are running just one 3d client the wait time should not alter your performance much. Or rather, the performance decrease should not be different than any other correct rendering. Just add a GFXCMDPARSER_LOAD_SCAN_LINES_INCL and a GFXCMDPARSER_WAIT_FOR_EVENT prior to the blit. This will hold the blit as long as it would tear on the screen. Small windows will not have to wait for a vblank, they only wait while the current scan intersects the blit. If you don't want to do that, you can just use the wait for event to block until the vblank as I mentioned before. This will make the rendering at least correct, you can then work on the page flipping as an optimization for full screen. -Matt -Original Message- From: Dave Airlie [mailto:[EMAIL PROTECTED]] Sent: Monday, December 16, 2002 6:57 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] [PATCH] i810 cleanup Well the i830 page flip code is using async flips, the main thing I want to use page flipping for on my i815 is sync'ed flips so I don't see the tearing that is so really obvious and gives people headaches.. (don't need to be getting sued here!!). It's not the timing I'm worried about it's the tearing, it can be slow as long as its not really ugly... the i815 can't do async page flipping properly anyways there is a bug in the silicon I would assume they fixed it for the i830 ... Also my current application is a single 3D window taking up the full screen, I doubt I'll ever any 2d windows interfering which is handy for me... My major issue now is finding a CVS tree which works for me on my development platform that I can then add code to. As my patch doesn't affect anything other than cleanup can you check it in? Dave. The 830 page flipping code is turned off for some good reasons: - I haven't seen it work without really visible corruption on the flip - typically flashing and blank areas - It isn't actually all that fast - there is a delay while (presumably) the ramdac cache or fifo drains - this is comparable to the time to blit the window itself. The crossover point was about 300x300 on my test box, but would vary for different machines. - Because of the above, it is necessary to wait for the flip to finish before clearing the backbuffer starting the next frame, otherwise you see this happen. Actually this invalidates my explanation of the delay -- the fact that you can see the clear implies that the ramdac is still grabbing new values from the frontbuffer, so I don't really know what the delay arises from. Keith -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] patch for host.def
Attached is a patch for host.def, so that things will compile on solaris at a basic level. [course, nothing will WORK yet. but, one thing at a time] Note that I originally posted this to the Bugs database on sourceforge, but got an email that I shouldnt do that. If folks shouldnt do that, then please truely disable that interface! --- host.defFri Sep 8 13:33:49 2000 +++ host.def.newFri Sep 8 13:39:11 2000 @@ -3,15 +3,24 @@ #define LibraryCDebugFlags -O2 #define BuildServersOnly YES #define XF86CardDrivers vga tdfx i810 mga r128 glint + +# if defined(SunArchitecture) +#define DefaultCCOptions -Wall -g +#define HasGlide3 NO +#else #define LinuxDistribution LinuxRedHat + #define GccWarningOptions -Wall -Wpointer-arith -Wstrict-prototypes \ -Wmissing-prototypes -Wmissing-declarations \ -Wnested-externs + #define DefaultCCOptions -ansi GccWarningOptions -pipe -g +#define HasGlide3 YES +#endif + #define NormalLibGlx NO #define BuildXF86DRI YES -#define HasGlide3 YES #ifdef i386Architecture #define MesaUse3DNow
Re: [Dri-devel] patch for host.def
And which host.def is this a patch against ? It does not match the trunk's versions at all. For a start there is no definition of LinuxDistribution in the trunks host.def file. You shouldn't need OS level patches like this at the host.def level. Please post more details on the errors that you are getting during building of the trunk. Alan. On Tue, Dec 17, 2002 at 04:08:03PM -0800, Philip Brown wrote: Attached is a patch for host.def, so that things will compile on solaris at a basic level. [course, nothing will WORK yet. but, one thing at a time] Note that I originally posted this to the Bugs database on sourceforge, but got an email that I shouldnt do that. If folks shouldnt do that, then please truely disable that interface! --- host.defFri Sep 8 13:33:49 2000 +++ host.def.newFri Sep 8 13:39:11 2000 @@ -3,15 +3,24 @@ #define LibraryCDebugFlags -O2 #define BuildServersOnly YES #define XF86CardDrivers vga tdfx i810 mga r128 glint + +# if defined(SunArchitecture) +#define DefaultCCOptions -Wall -g +#define HasGlide3 NO +#else #define LinuxDistribution LinuxRedHat + #define GccWarningOptions -Wall -Wpointer-arith -Wstrict-prototypes \ -Wmissing-prototypes -Wmissing-declarations \ -Wnested-externs + #define DefaultCCOptions -ansi GccWarningOptions -pipe -g +#define HasGlide3 YES +#endif + #define NormalLibGlx NO #define BuildXF86DRI YES -#define HasGlide3 YES #ifdef i386Architecture #define MesaUse3DNow --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for host.def
On Wed, Dec 18, 2002 at 12:17:29AM +, Alan Hourihane wrote: And which host.def is this a patch against ? It does not match the trunk's versions at all. For a start there is no definition of LinuxDistribution in the trunks host.def file. You shouldn't need OS level patches like this at the host.def level. Please post more details on the errors that you are getting during building of the trunk. Ah, sorry. Going back a week or two in memory to when I posted it to sourceforge, I think I took it off a static tarfile, which I took at the time to be the stable distribution or some such. As far as not needing OS level patches at the host.def level... Some features, namely, Glide3, seem to be only valid for particular OSes, so it would have to be an OS level patch. As far as WHERE it goes, please suggest/patch whereever you find it to be most appropriate. I'm just reporting what I needed to get the stuff to initially configure, and so forth. I made a quick run at a patch, and have moved on to other things. For those who have a deeper understanding of the config files, please do the right thing whereever it is now appropriate. --- host.defFri Sep 8 13:33:49 2000 +++ host.def.newFri Sep 8 13:39:11 2000 @@ -3,15 +3,24 @@ #define LibraryCDebugFlags -O2 #define BuildServersOnly YES #define XF86CardDrivers vga tdfx i810 mga r128 glint + +# if defined(SunArchitecture) +#define DefaultCCOptions -Wall -g +#define HasGlide3 NO +#else #define LinuxDistribution LinuxRedHat + #define GccWarningOptions -Wall -Wpointer-arith -Wstrict-prototypes \ -Wmissing-prototypes -Wmissing-declarations \ -Wnested-externs + #define DefaultCCOptions -ansi GccWarningOptions -pipe -g +#define HasGlide3 YES +#endif + #define NormalLibGlx NO #define BuildXF86DRI YES -#define HasGlide3 YES #ifdef i386Architecture #define MesaUse3DNow --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for host.def
On Tue, Dec 17, 2002 at 04:49:48PM -0800, Philip Brown wrote: On Wed, Dec 18, 2002 at 12:17:29AM +, Alan Hourihane wrote: And which host.def is this a patch against ? It does not match the trunk's versions at all. For a start there is no definition of LinuxDistribution in the trunks host.def file. You shouldn't need OS level patches like this at the host.def level. Please post more details on the errors that you are getting during building of the trunk. Ah, sorry. Going back a week or two in memory to when I posted it to sourceforge, I think I took it off a static tarfile, which I took at the time to be the stable distribution or some such. As far as not needing OS level patches at the host.def level... Some features, namely, Glide3, seem to be only valid for particular OSes, so it would have to be an OS level patch. As far as WHERE it goes, please suggest/patch whereever you find it to be most appropriate. I'm just reporting what I needed to get the stuff to initially configure, and so forth. HasGlide3 is set to NO by default and only enabled on Linux with an i386 or Alpha architecture. I made a quick run at a patch, and have moved on to other things. For those who have a deeper understanding of the config files, please do the right thing whereever it is now appropriate. Whereever you got the sources from, this patch is no longer necessary if you use the DRI trunk. But if you do get build problems, please post again, I'd be glad to help. Alan. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for host.def
On Wed, Dec 18, 2002 at 12:57:45AM +, Alan Hourihane wrote: HasGlide3 is set to NO by default and only enabled on Linux with an i386 or Alpha architecture. Good to know that it is fixed in later versions. I was using Solaris i386, so I was probably running afoul of old bad assumptions about i386 at the time. Hopefully it is now checking for BOTH Linux and i386, as you say. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [PATCH] i810 cleanup
Well that's a dodgy application on my part.. it now works sync'd with it .. How should I do this without changing the kernel i810 module? is there an way from the OpenGL level to do this that I could propogate down? Dave. Dave Airlie said: Nice one, that gets rid of my tearing - thanks Matthew, it works except now I get some jumpiness on my screen when a new texture is coming on, I've got 5 rotating reels of 4 textured quads and when the new ones are about to come on the top of the reel it seems to jump a bit... Not sure if the fullscreen would help here.. I need to time each render and see if this one takes a lot longer than the others.. Dave. Sottek, Matthew J said: The easiest way to get rid of tearing is to make the ring buffer wait before the back-front blit. This is a very simple mechanism that will work even for windowed 3d, and if you are running just one 3d client the wait time should not alter your performance much. Or rather, the performance decrease should not be different than any other correct rendering. Just add a GFXCMDPARSER_LOAD_SCAN_LINES_INCL and a GFXCMDPARSER_WAIT_FOR_EVENT prior to the blit. This will hold the blit as long as it would tear on the screen. Small windows will not have to wait for a vblank, they only wait while the current scan intersects the blit. If you don't want to do that, you can just use the wait for event to block until the vblank as I mentioned before. This will make the rendering at least correct, you can then work on the page flipping as an optimization for full screen. -Matt -Original Message- From: Dave Airlie [mailto:[EMAIL PROTECTED]] Sent: Monday, December 16, 2002 6:57 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Dri-devel] [PATCH] i810 cleanup Well the i830 page flip code is using async flips, the main thing I want to use page flipping for on my i815 is sync'ed flips so I don't see the tearing that is so really obvious and gives people headaches.. (don't need to be getting sued here!!). It's not the timing I'm worried about it's the tearing, it can be slow as long as its not really ugly... the i815 can't do async page flipping properly anyways there is a bug in the silicon I would assume they fixed it for the i830 ... Also my current application is a single 3D window taking up the full screen, I doubt I'll ever any 2d windows interfering which is handy for me... My major issue now is finding a CVS tree which works for me on my development platform that I can then add code to. As my patch doesn't affect anything other than cleanup can you check it in? Dave. The 830 page flipping code is turned off for some good reasons: - I haven't seen it work without really visible corruption on the flip - typically flashing and blank areas - It isn't actually all that fast - there is a delay while (presumably) the ramdac cache or fifo drains - this is comparable to the time to blit the window itself. The crossover point was about 300x300 on my test box, but would vary for different machines. - Because of the above, it is necessary to wait for the flip to finish before clearing the backbuffer starting the next frame, otherwise you see this happen. Actually this invalidates my explanation of the delay -- the fact that you can see the clear implies that the ramdac is still grabbing new values from the frontbuffer, so I don't really know what the delay arises from. Keith -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/
