RE: [Dri-devel] [PATCH] i810 cleanup
> BTW: Did you go with "wait for scanline" or "wait for vblank"? The > latter is more invasive... if you were doing multiple windowed > clients there would only be ONE buffer flip per retrace to be shared > between the clients. I just went with the wait for vblank (patch attached for demonstration purposes...) as I'm only doing a single 3d application full screen... and I'll probably just use that for our purposes here, as I need to keep a stable tree with minor patches - regulated industry isn't always the best :-) Dave. > > -Matt > > -Original Message- > From: Dave Airlie [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 17, 2002 8:39 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: 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
Re: [Dri-devel] [PATCH] i810 cleanup
On Wed, Dec 18, 2002 at 09:28:24AM -0800, Sottek, Matthew J wrote: > Does OpenGL make any requirements on the atomic-ness (atomicity?) of > a buffer flip? If so, I would assert that allowing part of a flip to > be visible on one frame and the rest visible on the next is not > a valid implementation and therefore the non-tearing implementation is > a requirement not a feature. Brian may know better, but I believe that core OpenGL makes no claims about the timing of buffer swap operations. I believe that is completely in the domain of the windowing interface layer. In terms of WGL and GLX, I believe that, without GLX_SGI_swap_control, GLX_SGI_video_sync, or GLX_OML_sync_control (or the WGL synonyms), there is no guarantee either. With GLX_SGI_swap_control, there is a guarantee of at least N (where N is 1 at context creation) vertical refereshes between buffer swaps. N can be set using glXSwapIntervalSGI. http://oss.sgi.com/projects/ogl-sample/registry/SGI/swap_control.txt With GLX_OML_sync_control, the application has even more control. The function glXSwapBuffersMscOML allows the application to specify that the swap happen when a specific refresh has happened or when the refresh number satisfies the equation ((frame % D) == R). http://oss.sgi.com/projects/ogl-sample/registry/OML/glx_sync_control.txt That said, neither of these extensions is /currently/ supported by DRI. I emphasise currently because I'm done implementing the device independent parts of both extensions, and I'm about 90% complete implementing the device dependent parts for the Radeon and MGA drivers. Hopefully, all of that code will be commited to the texmem-0-0-1 branch by the end of the year. Hopefully. If async (wrt to code execution, not wrt to vertical retrace) swaps are to be done in the i8xx drivers (which is a VERY GOOD idea), you will NEED a mechanism to know when the swap has happened. One part of the OML extension is the ability to query the number of buffer swap operations that have COMPLETED. The other extension that is interesting and is related to this is WGL_I3D_swap_frame_usage. http://oss.sgi.com/projects/ogl-sample/registry/I3D/wgl_swap_frame_usage.txt As long as the i8xx drivers can be made to support GLX_SGI_swap_control, GLX_OML_sync_control, and GLX_SGI_video_sync (really just a subset of GLX_OML_sync_control), go nuts! :) > On the other hand, if everyone is used to having no guarantee of > non-tearing behavior then they would likely not welcome the change. > Things like running gears at X FPS would certainly be slowed down. > > BTW: Did you go with "wait for scanline" or "wait for vblank"? The > latter is more invasive... if you were doing multiple windowed > clients there would only be ONE buffer flip per retrace to be shared > between the clients. Doing some sort of syncing to prevent tearing is a Good Thing(tm). The other drivers that implement this sort of functionality control it with environment variables. Look at radeonWaitForVBlank in lib/GL/mesa/src/drv/radeon/radeon_ioctl.c. It would probably be a good idea to do so here as well. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [PATCH] i810 cleanup
Does OpenGL make any requirements on the atomic-ness (atomicity?) of a buffer flip? If so, I would assert that allowing part of a flip to be visible on one frame and the rest visible on the next is not a valid implementation and therefore the non-tearing implementation is a requirement not a feature. On the other hand, if everyone is used to having no guarantee of non-tearing behavior then they would likely not welcome the change. Things like running gears at X FPS would certainly be slowed down. BTW: Did you go with "wait for scanline" or "wait for vblank"? The latter is more invasive... if you were doing multiple windowed clients there would only be ONE buffer flip per retrace to be shared between the clients. -Matt -Original Message- From: Dave Airlie [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 8:39 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 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 b
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/ >> ___ &
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
RE: [Dri-devel] [PATCH] i810 cleanup
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 --- 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 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
Re: [Dri-devel] [PATCH] i810 cleanup
On Mon, 2002-12-16 at 14:21, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Mon, 2002-12-16 at 14:04, Keith Whitwell wrote: > > > >>I think maybe I decided copying was ok as long as: > >>- you rig XAA (or whatever) to always draw into the current front buffer. > >>- you use cliprects to exclude the 3d window so that the backbuffer never > >>gets scribbled. > > > > > > Right, I keep forgetting about the issues involved with mixing X11 and > > OpenGL. If we exclude the 3D window, it doesn't matter which buffer is > > drawn to though, or am I missing something again? > > It matters because then you'd only see the results when X and GL agree on > which one is the front buffer... That's what I've been missing. So indeed it looks like the X rendering code would have to be extended to handle this correctly. Or might there already be code for this in related to the double buffering extension? Meanwhile, using shadowfb instead of the mi shadow module seems to keep the X display outside of the 3D window from getting corrupted at least. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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
Michel Dänzer wrote: On Mon, 2002-12-16 at 14:04, Keith Whitwell wrote: I think maybe I decided copying was ok as long as: - you rig XAA (or whatever) to always draw into the current front buffer. - you use cliprects to exclude the 3d window so that the backbuffer never gets scribbled. Right, I keep forgetting about the issues involved with mixing X11 and OpenGL. If we exclude the 3D window, it doesn't matter which buffer is drawn to though, or am I missing something again? It matters because then you'd only see the results when X and GL agree on which one is the front buffer... I don't see what difference it makes when the copy happens -- I think the current shadow module implementation is fine for that. For one, there can be no copy between to flips... Oh yes, that's a good point. 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] [PATCH] i810 cleanup
On Mon, 2002-12-16 at 14:04, Keith Whitwell wrote: > > I think maybe I decided copying was ok as long as: > - you rig XAA (or whatever) to always draw into the current front buffer. > - you use cliprects to exclude the 3d window so that the backbuffer never > gets scribbled. Right, I keep forgetting about the issues involved with mixing X11 and OpenGL. If we exclude the 3D window, it doesn't matter which buffer is drawn to though, or am I missing something again? > I don't see what difference it makes when the copy happens -- I think the > current shadow module implementation is fine for that. For one, there can be no copy between to flips... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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
Michel Dänzer wrote: On Mon, 2002-12-16 at 13:47, Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: 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 Presumably it uses the mi shadow module, and you should try shadowfb instead? Have you (or anyone else, for that matter) had a chance to try my patch for the radeon driver? I haven't. I'll have to go back to the last email thread I had on this, with Alan Hourihane, where (I think) I convinced myself once again that there was no way any copying scheme could ever be completely correct, and that only double-drawing could do the job properly. I on the other hand am pretty convinced that double drawing will never work. :) Because it doesn't handle unaccelerated primitives, or how does it? You have to double draw everything. I don't have an implementation, but a correct one would do those twice, too. And how is drawing things twice different to drawing them once and then copying? The problem with the mi shadow module is that the copy doesn't happen immediately after drawing. I think maybe I decided copying was ok as long as: - you rig XAA (or whatever) to always draw into the current front buffer. - you use cliprects to exclude the 3d window so that the backbuffer never gets scribbled. I don't see what difference it makes when the copy happens -- I think the current shadow module implementation is fine for that. 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] [PATCH] i810 cleanup
Michel Dänzer wrote: On Mon, 2002-12-16 at 13:47, Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: 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 Presumably it uses the mi shadow module, and you should try shadowfb instead? Have you (or anyone else, for that matter) had a chance to try my patch for the radeon driver? I haven't. I'll have to go back to the last email thread I had on this, with Alan Hourihane, where (I think) I convinced myself once again that there was no way any copying scheme could ever be completely correct, and that only double-drawing could do the job properly. I on the other hand am pretty convinced that double drawing will never work. :) Because it doesn't handle unaccelerated primitives, or how does it? You have to double draw everything. I don't have an implementation, but a correct one would do those twice, too. And how is drawing things twice different to drawing them once and then copying? The problem with the mi shadow module is that the copy doesn't happen immediately after drawing. I guess the trouble is with what else gets copied. I'm not sure exactly what I ended up deciding (whether copying was ok or not), but things to think about revolve around what happens when Xlib and GL drawing occur in the same drawable (yes, it's well defined). 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] [PATCH] i810 cleanup
On Mon, 2002-12-16 at 13:47, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote: > > > >>Michel Dänzer wrote: > >> > >>>On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: > >>> > >>> > 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 > >>> > >>> > >>>Presumably it uses the mi shadow module, and you should try shadowfb > >>>instead? Have you (or anyone else, for that matter) had a chance to try > >>>my patch for the radeon driver? > >> > >>I haven't. I'll have to go back to the last email thread I had on this, with > >>Alan Hourihane, where (I think) I convinced myself once again that there was > >>no way any copying scheme could ever be completely correct, and that only > >>double-drawing could do the job properly. > > > > > > I on the other hand am pretty convinced that double drawing will never > > work. :) Because it doesn't handle unaccelerated primitives, or how does > > it? > > You have to double draw everything. I don't have an implementation, but a > correct one would do those twice, too. And how is drawing things twice different to drawing them once and then copying? The problem with the mi shadow module is that the copy doesn't happen immediately after drawing. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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
Michel Dänzer wrote: On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: 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 Presumably it uses the mi shadow module, and you should try shadowfb instead? Have you (or anyone else, for that matter) had a chance to try my patch for the radeon driver? I haven't. I'll have to go back to the last email thread I had on this, with Alan Hourihane, where (I think) I convinced myself once again that there was no way any copying scheme could ever be completely correct, and that only double-drawing could do the job properly. I on the other hand am pretty convinced that double drawing will never work. :) Because it doesn't handle unaccelerated primitives, or how does it? You have to double draw everything. I don't have an implementation, but a correct one would do those twice, too. 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] [PATCH] i810 cleanup
On Mon, 2002-12-16 at 13:34, Keith Whitwell wrote: > Michel Dänzer wrote: > > On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: > > > >>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 > > > > > > Presumably it uses the mi shadow module, and you should try shadowfb > > instead? Have you (or anyone else, for that matter) had a chance to try > > my patch for the radeon driver? > > I haven't. I'll have to go back to the last email thread I had on this, with > Alan Hourihane, where (I think) I convinced myself once again that there was > no way any copying scheme could ever be completely correct, and that only > double-drawing could do the job properly. I on the other hand am pretty convinced that double drawing will never work. :) Because it doesn't handle unaccelerated primitives, or how does it? > However, that's not the problem with the i830 - I mean hardware flashes, image > breakup, etc on the flip. I see, but even without that the mi shadow module would likely cause problems. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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
Michel Dänzer wrote: On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: 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 Presumably it uses the mi shadow module, and you should try shadowfb instead? Have you (or anyone else, for that matter) had a chance to try my patch for the radeon driver? I haven't. I'll have to go back to the last email thread I had on this, with Alan Hourihane, where (I think) I convinced myself once again that there was no way any copying scheme could ever be completely correct, and that only double-drawing could do the job properly. However, that's not the problem with the i830 - I mean hardware flashes, image breakup, etc on the flip. 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] [PATCH] i810 cleanup
On Mon, 2002-12-16 at 10:47, Keith Whitwell wrote: > > 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 Presumably it uses the mi shadow module, and you should try shadowfb instead? Have you (or anyone else, for that matter) had a chance to try my patch for the radeon driver? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- 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
Dave Airlie wrote: This takes some of the stuff that was recently submitted to the xfree86.org for the i830 and tries to move the i810 along similiar lines... is all cosmetic apart from a new define for the FRONTBUFFER command this is what they call it in the i815 spec anyways. I'm submitting the equivalent patch to xfree86 (well slightly changed) for their tree also. Then I'll start moving over the i830 page flipping code from the xfree86 tree into an i810 driver. Anyone want to sync up our i830 with xfree86's? 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 --- 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
doh doh!! wasn't sync'ed properly with the tree (damn firewall!!)... this diff is a bit better and doesn't remove functionality... Dave. Dave Airlie said: > This takes some of the stuff that was recently submitted to the > xfree86.org for the i830 and tries to move the i810 along similiar > lines... > > is all cosmetic apart from a new define for the FRONTBUFFER command this > is what they call it in the i815 spec anyways. > > I'm submitting the equivalent patch to xfree86 (well slightly changed) > for their tree also. > > Then I'll start moving over the i830 page flipping code from the xfree86 > tree into an i810 driver. Anyone want to sync up our i830 with > xfree86's? > > Dave. > > -- > David Airlie, Software Engineer > http://www.skynet.ie/~airlied / [EMAIL PROTECTED] > pam_smb / Linux DecStation / Linux VAX / ILUG person -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person dri_diff Description: Binary data
