From: David D. H. <wow...@sk...> - 2003-04-07 11:30:51
|
I just pulled the texmem-0-0-1 branch and now all the GL apps are running synced to vsync (tunnel, gears, etc.) I don't have either of the frame sync environment variables set. What else would turn on the frame sync code? |
From: Ian R. <id...@us...> - 2003-04-07 16:45:28
|
David D. Hagood wrote: > I just pulled the texmem-0-0-1 branch and now all the GL apps are > running synced to vsync (tunnel, gears, etc.) > > I don't have either of the frame sync environment variables set. > > What else would turn on the frame sync code? There are basically four states that the driver can be in WRT vertical refresh synchronization. 1. Application preference. The application can select the number of vertical refreshes that must occur between buffer swaps (aka the swap interval). The default value is 1. This is the default setting. 2. No-vsync. No swap throttling or refresh synchronization occurs. This is the old default, but it is now controlled by setting 'LIBGL_NO_VSYNC=1'. 3. "Throttle refresh." This is like #1, but the application cannot change the swap interval from the default setting of 1. This is selected by 'LIBGL_THROTTLE_REFRESH=1'. IMHO, this setting is of little use and should be depricated. 4. Sync to refresh. I have grouped this option apart from the others because it tries to achieve a different purpose. The other settings control the swap-rate, but this option tries to prevent tearing during buffer swaps. The current implementation is to wait for the vertical refresh before swapping and is selected with 'LIBGL_SYNC_REFRESH=1'. I believe that this option is mis-named. When page-flipping is enabled, this option is not needed. On architectures (such as i8x0) that can wait for an arbitrary beam position (i.e., the bottom of the 3D window), it need not wait for the vertical refresh. In fact, it may not need to wait at all. This all only applies to the MGA, Radeon, and R200 drivers in the texmem branch. It should only take someone w/Rage 128 hardware about 20 minutes to make the necessary changes to that driver. :) I picked #1 as the default because we now expose the GLX_SGI_swap_control (and GLX_MESA_swap_control) extension. I didn't want to break applications ported to XFree86 from other X11 / GLX implementations to break. The extension spec states that the default value of the swap interval is 1. That said, I think that the old LIBGL_THROTTLE_REFRESH and LIBGL_SYNC_REFRESH options should be depricated. The functionality of LIBGL_THROTTLE_REFRESH has already been replaced. I believe that the functionality of LIBGL_SYNC_REFRESH should be made the default, and a new option should be added. The new option should be something along the lines of LIBGL_NO_PREVENT_TEARING. Either that or we could keep the current env. variables and expose the new settings through the new configuration file / utility. :) |
From: Keith W. <ke...@tu...> - 2003-04-07 16:54:22
|
Ian Romanick wrote: > David D. Hagood wrote: > >> I just pulled the texmem-0-0-1 branch and now all the GL apps are >> running synced to vsync (tunnel, gears, etc.) >> >> I don't have either of the frame sync environment variables set. >> >> What else would turn on the frame sync code? > > > There are basically four states that the driver can be in WRT vertical > refresh synchronization. > > 1. Application preference. The application can select the number of > vertical refreshes that must occur between buffer swaps (aka the swap > interval). The default value is 1. This is the default setting. > > 2. No-vsync. No swap throttling or refresh synchronization occurs. This > is the old default, but it is now controlled by setting 'LIBGL_NO_VSYNC=1'. > > 3. "Throttle refresh." This is like #1, but the application cannot > change the swap interval from the default setting of 1. This is > selected by 'LIBGL_THROTTLE_REFRESH=1'. IMHO, this setting is of little > use and should be depricated. > > 4. Sync to refresh. I have grouped this option apart from the others > because it tries to achieve a different purpose. The other settings > control the swap-rate, but this option tries to prevent tearing during > buffer swaps. The current implementation is to wait for the vertical > refresh before swapping and is selected with 'LIBGL_SYNC_REFRESH=1'. I > believe that this option is mis-named. When page-flipping is enabled, > this option is not needed. On architectures (such as i8x0) that can > wait for an arbitrary beam position (i.e., the bottom of the 3D window), > it need not wait for the vertical refresh. In fact, it may not need to > wait at all. > > This all only applies to the MGA, Radeon, and R200 drivers in the texmem > branch. It should only take someone w/Rage 128 hardware about 20 > minutes to make the necessary changes to that driver. :) > > I picked #1 as the default because we now expose the > GLX_SGI_swap_control (and GLX_MESA_swap_control) extension. I didn't > want to break applications ported to XFree86 from other X11 / GLX > implementations to break. The extension spec states that the default > value of the swap interval is 1. > > That said, I think that the old LIBGL_THROTTLE_REFRESH and > LIBGL_SYNC_REFRESH options should be depricated. The functionality of > LIBGL_THROTTLE_REFRESH has already been replaced. I believe that the > functionality of LIBGL_SYNC_REFRESH should be made the default, and a > new option should be added. The new option should be something along > the lines of LIBGL_NO_PREVENT_TEARING. > > Either that or we could keep the current env. variables and expose the > new settings through the new configuration file / utility. :) My experience with the tdfx driver, which used to default to sync-to-vsync swapping is that you really don't want to be releasing drivers that default that way, as 99% of the users just want gears to go as fast as possible, and that 98% of those will post on dri-devel if it doesn't. Which ends up wasting a lot of time with the same question over and over, or else makes us look uncaring because we can't be bothered answering the same question one more time. Keith |
From: Ian R. <id...@us...> - 2003-04-07 17:23:57
|
Keith Whitwell wrote: > Ian Romanick wrote: > >> David D. Hagood wrote: >> >>> I just pulled the texmem-0-0-1 branch and now all the GL apps are >>> running synced to vsync (tunnel, gears, etc.) >>> >>> I don't have either of the frame sync environment variables set. >>> >>> What else would turn on the frame sync code? >> >> >> >> There are basically four states that the driver can be in WRT vertical >> refresh synchronization. >> >> 1. Application preference. The application can select the number of >> vertical refreshes that must occur between buffer swaps (aka the swap >> interval). The default value is 1. This is the default setting. >> >> 2. No-vsync. No swap throttling or refresh synchronization occurs. >> This is the old default, but it is now controlled by setting >> 'LIBGL_NO_VSYNC=1'. >> >> 3. "Throttle refresh." This is like #1, but the application cannot >> change the swap interval from the default setting of 1. This is >> selected by 'LIBGL_THROTTLE_REFRESH=1'. IMHO, this setting is of >> little use and should be depricated. >> >> 4. Sync to refresh. I have grouped this option apart from the others >> because it tries to achieve a different purpose. The other settings >> control the swap-rate, but this option tries to prevent tearing during >> buffer swaps. The current implementation is to wait for the vertical >> refresh before swapping and is selected with 'LIBGL_SYNC_REFRESH=1'. >> I believe that this option is mis-named. When page-flipping is >> enabled, this option is not needed. On architectures (such as i8x0) >> that can wait for an arbitrary beam position (i.e., the bottom of the >> 3D window), it need not wait for the vertical refresh. In fact, it >> may not need to wait at all. >> >> This all only applies to the MGA, Radeon, and R200 drivers in the >> texmem branch. It should only take someone w/Rage 128 hardware about >> 20 minutes to make the necessary changes to that driver. :) >> >> I picked #1 as the default because we now expose the >> GLX_SGI_swap_control (and GLX_MESA_swap_control) extension. I didn't >> want to break applications ported to XFree86 from other X11 / GLX >> implementations to break. The extension spec states that the default >> value of the swap interval is 1. >> >> That said, I think that the old LIBGL_THROTTLE_REFRESH and >> LIBGL_SYNC_REFRESH options should be depricated. The functionality of >> LIBGL_THROTTLE_REFRESH has already been replaced. I believe that the >> functionality of LIBGL_SYNC_REFRESH should be made the default, and a >> new option should be added. The new option should be something along >> the lines of LIBGL_NO_PREVENT_TEARING. >> >> Either that or we could keep the current env. variables and expose the >> new settings through the new configuration file / utility. :) > > > My experience with the tdfx driver, which used to default to > sync-to-vsync swapping is that you really don't want to be releasing > drivers that default that way, as 99% of the users just want gears to go > as fast as possible, and that 98% of those will post on dri-devel if it > doesn't. Which ends up wasting a lot of time with the same question > over and over, or else makes us look uncaring because we can't be > bothered answering the same question one more time. Is your recommendation to stick with #1, but set the default swap interval "back" to 0? In that case, I'd probably also change the LIBGL_THROTTLE_REFRESH case to be #1, but set the default swap interval to 1. On every other system I've used (Windows, MacOS, and other versions of X), setting the swap interval to 1 *is* the default. Users have to specificially disable that setting via some sort of configuration. It's unfortunate that we picked the "wrong" default to begin with. :( I'd prefer to leave things the way that I have them, but you're reasoning is very compelling...and I'm not as stuborn as I used to be. :) |
From: Allen A. <ak...@po...> - 2003-04-07 18:03:35
|
On Mon, Apr 07, 2003 at 10:23:48AM -0700, Ian Romanick wrote: | On every other system I've used (Windows, MacOS, and other versions of | X), setting the swap interval to 1 *is* the default. Users have to | specificially disable that setting via some sort of configuration. That's my understanding, too. | I'd prefer to leave things the way that I have them... Same here, despite the potential hassles that Keith mentioned. Allen |
From: Leif D. <lde...@re...> - 2003-04-07 18:26:54
|
On Mon, 7 Apr 2003, Ian Romanick wrote: > Keith Whitwell wrote: > > Ian Romanick wrote: > > > >> David D. Hagood wrote: > >> > >>> I just pulled the texmem-0-0-1 branch and now all the GL apps are > >>> running synced to vsync (tunnel, gears, etc.) > >>> > >>> I don't have either of the frame sync environment variables set. > >>> > >>> What else would turn on the frame sync code? > >> > >> > >> > >> There are basically four states that the driver can be in WRT vertical > >> refresh synchronization. > >> > >> 1. Application preference. The application can select the number of > >> vertical refreshes that must occur between buffer swaps (aka the swap > >> interval). The default value is 1. This is the default setting. > >> > >> 2. No-vsync. No swap throttling or refresh synchronization occurs. > >> This is the old default, but it is now controlled by setting > >> 'LIBGL_NO_VSYNC=1'. > >> > >> 3. "Throttle refresh." This is like #1, but the application cannot > >> change the swap interval from the default setting of 1. This is > >> selected by 'LIBGL_THROTTLE_REFRESH=1'. IMHO, this setting is of > >> little use and should be depricated. > >> > >> 4. Sync to refresh. I have grouped this option apart from the others > >> because it tries to achieve a different purpose. The other settings > >> control the swap-rate, but this option tries to prevent tearing during > >> buffer swaps. The current implementation is to wait for the vertical > >> refresh before swapping and is selected with 'LIBGL_SYNC_REFRESH=1'. > >> I believe that this option is mis-named. When page-flipping is > >> enabled, this option is not needed. On architectures (such as i8x0) > >> that can wait for an arbitrary beam position (i.e., the bottom of the > >> 3D window), it need not wait for the vertical refresh. In fact, it > >> may not need to wait at all. > >> > >> This all only applies to the MGA, Radeon, and R200 drivers in the > >> texmem branch. It should only take someone w/Rage 128 hardware about > >> 20 minutes to make the necessary changes to that driver. :) > >> > >> I picked #1 as the default because we now expose the > >> GLX_SGI_swap_control (and GLX_MESA_swap_control) extension. I didn't > >> want to break applications ported to XFree86 from other X11 / GLX > >> implementations to break. The extension spec states that the default > >> value of the swap interval is 1. > >> > >> That said, I think that the old LIBGL_THROTTLE_REFRESH and > >> LIBGL_SYNC_REFRESH options should be depricated. The functionality of > >> LIBGL_THROTTLE_REFRESH has already been replaced. I believe that the > >> functionality of LIBGL_SYNC_REFRESH should be made the default, and a > >> new option should be added. The new option should be something along > >> the lines of LIBGL_NO_PREVENT_TEARING. > >> > >> Either that or we could keep the current env. variables and expose the > >> new settings through the new configuration file / utility. :) > > > > > > My experience with the tdfx driver, which used to default to > > sync-to-vsync swapping is that you really don't want to be releasing > > drivers that default that way, as 99% of the users just want gears to go > > as fast as possible, and that 98% of those will post on dri-devel if it > > doesn't. Which ends up wasting a lot of time with the same question > > over and over, or else makes us look uncaring because we can't be > > bothered answering the same question one more time. > > Is your recommendation to stick with #1, but set the default swap > interval "back" to 0? In that case, I'd probably also change the > LIBGL_THROTTLE_REFRESH case to be #1, but set the default swap interval > to 1. > > On every other system I've used (Windows, MacOS, and other versions of > X), setting the swap interval to 1 *is* the default. Users have to > specificially disable that setting via some sort of configuration. It's > unfortunate that we picked the "wrong" default to begin with. :( > > I'd prefer to leave things the way that I have them, but you're > reasoning is very compelling...and I'm not as stuborn as I used to be. :) Here's my $0.02... I also think vsync should be the default, as Ian says that's usually the case with other implementations. In addition, don't some of the extensions exposed require the default interval to be 1 according to the spec? IMO, it's preferable to favor quality in this regard, and start out with no tearing. People interested in raw FPS (e.g. gamers and people running benchmarks), will likely be familiar with the concept of turning off vsync to max out the framerate. It will require some re-education and promiment documentation regarding the settings (this would be a good thing to have in a GUI config tool), but I think we need to continue to dispell the myth that gears is a useful benchmark. This would be a good candidate for the user FAQ. -- Leif Delgass http://www.retinalburn.net |
From: Keith W. <ke...@tu...> - 2003-04-07 18:38:31
|
Leif Delgass wrote: > On Mon, 7 Apr 2003, Ian Romanick wrote: > > >>Keith Whitwell wrote: >> >>>Ian Romanick wrote: >>> >>> >>>>David D. Hagood wrote: >>>> >>>> >>>>>I just pulled the texmem-0-0-1 branch and now all the GL apps are >>>>>running synced to vsync (tunnel, gears, etc.) >>>>> >>>>>I don't have either of the frame sync environment variables set. >>>>> >>>>>What else would turn on the frame sync code? >>>> >>>> >>>> >>>>There are basically four states that the driver can be in WRT vertical >>>>refresh synchronization. >>>> >>>>1. Application preference. The application can select the number of >>>>vertical refreshes that must occur between buffer swaps (aka the swap >>>>interval). The default value is 1. This is the default setting. >>>> >>>>2. No-vsync. No swap throttling or refresh synchronization occurs. >>>>This is the old default, but it is now controlled by setting >>>>'LIBGL_NO_VSYNC=1'. >>>> >>>>3. "Throttle refresh." This is like #1, but the application cannot >>>>change the swap interval from the default setting of 1. This is >>>>selected by 'LIBGL_THROTTLE_REFRESH=1'. IMHO, this setting is of >>>>little use and should be depricated. >>>> >>>>4. Sync to refresh. I have grouped this option apart from the others >>>>because it tries to achieve a different purpose. The other settings >>>>control the swap-rate, but this option tries to prevent tearing during >>>>buffer swaps. The current implementation is to wait for the vertical >>>>refresh before swapping and is selected with 'LIBGL_SYNC_REFRESH=1'. >>>>I believe that this option is mis-named. When page-flipping is >>>>enabled, this option is not needed. On architectures (such as i8x0) >>>>that can wait for an arbitrary beam position (i.e., the bottom of the >>>>3D window), it need not wait for the vertical refresh. In fact, it >>>>may not need to wait at all. >>>> >>>>This all only applies to the MGA, Radeon, and R200 drivers in the >>>>texmem branch. It should only take someone w/Rage 128 hardware about >>>>20 minutes to make the necessary changes to that driver. :) >>>> >>>>I picked #1 as the default because we now expose the >>>>GLX_SGI_swap_control (and GLX_MESA_swap_control) extension. I didn't >>>>want to break applications ported to XFree86 from other X11 / GLX >>>>implementations to break. The extension spec states that the default >>>>value of the swap interval is 1. >>>> >>>>That said, I think that the old LIBGL_THROTTLE_REFRESH and >>>>LIBGL_SYNC_REFRESH options should be depricated. The functionality of >>>>LIBGL_THROTTLE_REFRESH has already been replaced. I believe that the >>>>functionality of LIBGL_SYNC_REFRESH should be made the default, and a >>>>new option should be added. The new option should be something along >>>>the lines of LIBGL_NO_PREVENT_TEARING. >>>> >>>>Either that or we could keep the current env. variables and expose the >>>>new settings through the new configuration file / utility. :) >>> >>> >>>My experience with the tdfx driver, which used to default to >>>sync-to-vsync swapping is that you really don't want to be releasing >>>drivers that default that way, as 99% of the users just want gears to go >>>as fast as possible, and that 98% of those will post on dri-devel if it >>>doesn't. Which ends up wasting a lot of time with the same question >>>over and over, or else makes us look uncaring because we can't be >>>bothered answering the same question one more time. >> >>Is your recommendation to stick with #1, but set the default swap >>interval "back" to 0? In that case, I'd probably also change the >>LIBGL_THROTTLE_REFRESH case to be #1, but set the default swap interval >>to 1. >> >>On every other system I've used (Windows, MacOS, and other versions of >>X), setting the swap interval to 1 *is* the default. Users have to >>specificially disable that setting via some sort of configuration. It's >>unfortunate that we picked the "wrong" default to begin with. :( >> >>I'd prefer to leave things the way that I have them, but you're >>reasoning is very compelling...and I'm not as stuborn as I used to be. :) > > > Here's my $0.02... > > I also think vsync should be the default, as Ian says that's usually the > case with other implementations. In addition, don't some of the > extensions exposed require the default interval to be 1 according to the > spec? IMO, it's preferable to favor quality in this regard, and start out > with no tearing. People interested in raw FPS (e.g. gamers and people > running benchmarks), will likely be familiar with the concept of turning > off vsync to max out the framerate. This is 99% of 3d users. Why marginalize them. The current behaviour is what people are used to. The few people that care otherwise will be more likely to investigate the vsync extensions/issues, and much easier to deal with as there are only about 10 of them. > It will require some re-education and promiment documentation regarding > the settings (this would be a good thing to have in a GUI config tool), > but I think we need to continue to dispell the myth that gears is a useful > benchmark. This would be a good candidate for the user FAQ. Why make so much work for us? For what? Keith |
From: Ian R. <id...@us...> - 2003-04-07 19:19:14
|
Keith Whitwell wrote: > Leif Delgass wrote: > >> Here's my $0.02... >> >> I also think vsync should be the default, as Ian says that's usually the >> case with other implementations. In addition, don't some of the >> extensions exposed require the default interval to be 1 according to the Yes. The SGI version of the spec says that the initial value is 1. The MESA version also says that the initial value is 1, but we could change that. In light of what we're saying here, it seems that the initial value should be "0 or 1". This will require applications set the value they actually want or just accept the system / user-set default. http://oss.sgi.com/projects/ogl-sample/registry/SGI/swap_control.txt >> spec? IMO, it's preferable to favor quality in this regard, and start >> out Tearing is a secondary issue. By using page-flipping or just delaying the swap (i.e., using an asynchronous buffer swap) until the beam gets to the bottom of the window we can avoid tearing without changing the swap interval. At some level it can throttle the frame rate, but it doesn't need to. If the window is (10,10)-(50,50), there's nothing to say was can't 150 "buffer swaps" when the beam reaches raster 51. :) >> with no tearing. People interested in raw FPS (e.g. gamers and people >> running benchmarks), will likely be familiar with the concept of turning >> off vsync to max out the framerate. > > This is 99% of 3d users. Why marginalize them. The current behaviour > is what people are used to. The few people that care otherwise will be > more likely to investigate the vsync extensions/issues, and much easier > to deal with as there are only about 10 of them. Well...we're not marginalizing them, per se. We're not taking away any functionality. We're just changing the way they get at it. Right now, 99% of the 3D users on XFree86 are gamers. However, the tides are changing! There are a lot of companies (not just the one where I work!) that see Linux as the next place for high-end 3D "CAD" apps to go. Even more so than Windows, we *really* need to think about how to keep *both* groups happy. >> It will require some re-education and promiment documentation regarding >> the settings (this would be a good thing to have in a GUI config tool), >> but I think we need to continue to dispell the myth that gears is a >> useful benchmark. This would be a good candidate for the user FAQ. > > Why make so much work for us? For what? I think that's the only real issue. What will be more work for us? Educating the people that want the default swap interval to be 0 or the people that want the default swap interval to be 1. The other issue is with 3rd party close-source drivers. I think one goal should be to have XFree86, as a platform, be consistent. As other companies bring 3D drivers to XFree86, are they going to want to make the same choice? This isn't as big of an issue, but it is still something to think about. Afterall, whatever we decide the default is becomes the "correct" answer. :) All things considered, I don't care that much either way. |
From: Leif D. <lde...@re...> - 2003-04-07 20:17:23
|
On Mon, 7 Apr 2003, Ian Romanick wrote: > Keith Whitwell wrote: > > Leif Delgass wrote: > > > >> Here's my $0.02... > >> > >> I also think vsync should be the default, as Ian says that's usually the > >> case with other implementations. In addition, don't some of the > >> extensions exposed require the default interval to be 1 according to the > > Yes. The SGI version of the spec says that the initial value is 1. The > MESA version also says that the initial value is 1, but we could change > that. In light of what we're saying here, it seems that the initial > value should be "0 or 1". This will require applications set the value > they actually want or just accept the system / user-set default. Wouldn't it be a problem to expose two extensions with different default values? > http://oss.sgi.com/projects/ogl-sample/registry/SGI/swap_control.txt > > >> spec? IMO, it's preferable to favor quality in this regard, and start > >> out > > Tearing is a secondary issue. By using page-flipping or just delaying > the swap (i.e., using an asynchronous buffer swap) until the beam gets > to the bottom of the window we can avoid tearing without changing the > swap interval. At some level it can throttle the frame rate, but it > doesn't need to. If the window is (10,10)-(50,50), there's nothing to > say was can't 150 "buffer swaps" when the beam reaches raster 51. :) With radeon, page flipping is currently done asynchronously. Otherwise you wouldn't get the huge gears numbers with page flipping on. The image will tear at the current scanline when the flip is executed, which is why the wait for vblank is needed to prevent tearing for page flipping as well as buffer swapping with blits. It's also possible to program the card to delay the flip until vblank, I believe. In either case, you can't let the card draw into the new back buffer until the flip has actually taken effect. In my experiments with mach64, I found that page flipping works best when synchronized with the vertical blank. I found a bit in the HW_DEBUG register that allows asynchronous flips, but it has issues (there's often one scanline that flickers at the point where the flip happens. The programmer's guide doesn't even mention this bit in the section about "smooth animation" which describes page flipping. > >> with no tearing. People interested in raw FPS (e.g. gamers and people > >> running benchmarks), will likely be familiar with the concept of turning > >> off vsync to max out the framerate. > > > > This is 99% of 3d users. Why marginalize them. The current behaviour > > is what people are used to. The few people that care otherwise will be > > more likely to investigate the vsync extensions/issues, and much easier > > to deal with as there are only about 10 of them. > > Well...we're not marginalizing them, per se. We're not taking away any > functionality. We're just changing the way they get at it. Right now, > 99% of the 3D users on XFree86 are gamers. However, the tides are > changing! There are a lot of companies (not just the one where I work!) > that see Linux as the next place for high-end 3D "CAD" apps to go. > > Even more so than Windows, we *really* need to think about how to keep > *both* groups happy. This was my thinking as well. In addition to graphics workstation type users, there are casual/occasional 3D users that will use screensavers, multimedia visualization plugins, the occasional game, etc. I think preventing tearing by default will give better visual quality with a minimal performance impact to these users, who are the ones most likely to _not_ change the default settings. People that want more control can just set an env. var in their profile and be done with it, use application settings, or force vsync off for particular apps. > >> It will require some re-education and promiment documentation regarding > >> the settings (this would be a good thing to have in a GUI config tool), > >> but I think we need to continue to dispell the myth that gears is a > >> useful benchmark. This would be a good candidate for the user FAQ. > > > > Why make so much work for us? For what? > > I think that's the only real issue. What will be more work for us? > Educating the people that want the default swap interval to be 0 or the > people that want the default swap interval to be 1. This is what FAQs and the user list are for. At any rate, gears framerates shouldn't drive development. I think if more people ignored the gears numbers and tried out the apps they actually use and care about, more people might decide vsyc is better in some cases. I've played quake 3, ut, and other games with vsync on. I don't notice much of a performance difference and it looks smoother without the flickering and tearing that is very noticable in some situations. > The other issue is with 3rd party close-source drivers. I think one > goal should be to have XFree86, as a platform, be consistent. As other > companies bring 3D drivers to XFree86, are they going to want to make > the same choice? This isn't as big of an issue, but it is still > something to think about. Afterall, whatever we decide the default is > becomes the "correct" answer. :) > > All things considered, I don't care that much either way. -- Leif Delgass http://www.retinalburn.net |
From: Mike A. H. <mh...@re...> - 2003-04-08 02:11:11
|
On Mon, 7 Apr 2003, Keith Whitwell wrote: >> I also think vsync should be the default, as Ian says that's usually the >> case with other implementations. In addition, don't some of the >> extensions exposed require the default interval to be 1 according to the >> spec? IMO, it's preferable to favor quality in this regard, and start out >> with no tearing. People interested in raw FPS (e.g. gamers and people >> running benchmarks), will likely be familiar with the concept of turning >> off vsync to max out the framerate. > >This is 99% of 3d users. Why marginalize them. The current behaviour is what >people are used to. The few people that care otherwise will be more likely to >investigate the vsync extensions/issues, and much easier to deal with as there >are only about 10 of them. I agree. Default settings of things in all software should reflect what the majority of users expect to happen. Changing this default to end up having thousands of users complain about FPS rates of DRI drivers sucking is a bad idea. It would stand only to give DRI a black eye. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat |
From: David D. H. <wow...@sk...> - 2003-04-08 11:55:46
|
Mike A. Harris wrote: > I agree. Default settings of things in all software should > reflect what the majority of users expect to happen. Well, it would have helped me if there were a good document somewhere obvious on dri.sourceforge.net that explained the change - I had to run strings on the module, followed by a Googling to find the vars I did. But my vote would be for the default to be no sync - if an application wants to change that it can. |
From: Ian R. <id...@us...> - 2003-04-08 19:26:31
|
David D. Hagood wrote: > Mike A. Harris wrote: > >> I agree. Default settings of things in all software should reflect >> what the majority of users expect to happen. > > Well, it would have helped me if there were a good document somewhere > obvious on dri.sourceforge.net that explained the change - I had to run > strings on the module, followed by a Googling to find the vars I did. That's because it was in a development branch. > But my vote would be for the default to be no sync - if an application > wants to change that it can. The problem is that the SGI extension doesn't give an application any way to determine what the current swap interval is. Therefore, at start-up the application has to assume that the extension is correctly implemented, and the default value is 1. By the definition of the extension, if the app wants the value to be 1, it doesn't need to do anything. |
From: Ian R. <id...@us...> - 2003-04-08 20:10:31
|
Mike A. Harris wrote: > On Mon, 7 Apr 2003, Keith Whitwell wrote: > >>>I also think vsync should be the default, as Ian says that's usually the >>>case with other implementations. In addition, don't some of the >>>extensions exposed require the default interval to be 1 according to the >>>spec? IMO, it's preferable to favor quality in this regard, and start out >>>with no tearing. People interested in raw FPS (e.g. gamers and people >>>running benchmarks), will likely be familiar with the concept of turning >>>off vsync to max out the framerate. >> >>This is 99% of 3d users. Why marginalize them. The current behaviour is what >>people are used to. The few people that care otherwise will be more likely to >>investigate the vsync extensions/issues, and much easier to deal with as there >>are only about 10 of them. > > I agree. Default settings of things in all software should > reflect what the majority of users expect to happen. Changing > this default to end up having thousands of users complain about > FPS rates of DRI drivers sucking is a bad idea. It would stand > only to give DRI a black eye. [NOTE: Please read the whole message before flaming the first couple paragraphs.] I am going to agree with your conclusion, but I strongly disagree with the way you got there. There is a specification from *1995* that states the glXSwapBuffers swaps the buffers at most once per vertical refresh. Our drivers do not work that way and are therefore in error. The fact that our users have come to rely on the fact that our drivers are wrong does not magically make them right. In terms of precedent, keep in mind the SGI, MacOS, Windows, AIX, and (probably) Sun *ALL* default to vsync on. If GLIBC implemented some "special" behavior where calling fread with a NULL data pointer did something "useful," it would be in error. It wouldn't matter how much software came depend on that behavior, it would still be wrong. GCC has broken with existing behavior a number of times to fix bugs. The recent C++ ABI breakages were painful, but necessary. I would say that they were waaaaay more painful than telling users to put 'export LIBGL_NO_VSYNC=1' in ~/.bashrc. :) If someone ports a multi-million line application from some other version of Unix / X to an XFree86 platform that uses this extension, they will expect the interval to be 1. Having it be 0 is incorrect and will only give DRI a black eye. :) The question comes down to this: do we want to answer scores of questions from users about the new behavior or do we want to answer far fewer questions from developers about problems with our implementation of the extension. My current thinking is to leave the non-vsync behavior (current trunk). When the global configuration file becomes available, the behavior will be determined by a value in the config file. Each distro will then be able to set whatever value in the global config file it thinks will be serve its customers. At that time we can re-evaluate the issue. In the mean time I'm also going to modify glxgears to make use of a few of the new GLX extensions supported by the texmem-0-0-1 branch. I'll send out the new version in a few days. |
From: Keith W. <ke...@tu...> - 2003-04-09 08:37:29
|
> [NOTE: Please read the whole message before flaming the first couple > paragraphs.] > > I am going to agree with your conclusion, but I strongly disagree with > the way you got there. There is a specification from *1995* that states > the glXSwapBuffers swaps the buffers at most once per vertical refresh. > Our drivers do not work that way and are therefore in error. The fact > that our users have come to rely on the fact that our drivers are wrong > does not magically make them right. In terms of precedent, keep in mind > the SGI, MacOS, Windows, AIX, and (probably) Sun *ALL* default to vsync on. This gets us back to the configuration tool. Windows may or may not default to synced operation, but all the drivers have a control panel where you can turn that behaviour off. Keith |
From: Jens O. <je...@tu...> - 2003-04-09 17:04:12
|
Ian Romanick wrote: > My current thinking is to leave the non-vsync behavior (current trunk). > When the global configuration file becomes available, the behavior will > be determined by a value in the config file. Each distro will then be > able to set whatever value in the global config file it thinks will be > serve its customers. At that time we can re-evaluate the issue. > > In the mean time I'm also going to modify glxgears to make use of a few > of the new GLX extensions supported by the texmem-0-0-1 branch. I'll > send out the new version in a few days. This illustrate my concern with the config file issue. We're putting distros in the situation of having to choose which market they are in when we should really be concentrating on the API or extending the API so that one graphics subsystem can work well for both the gaming and the multi-million dollar app. If the current implementation is in violation of the specification, why can't we create an extension that can be used by game developers who need to run frame rates higher than the vertical refresh limit? Yes, this is more work for us, and yes it will take time for all games to adopt the extension...but this is along term fix that we should provide rather than segmenting the market long term. No, I don't believe that an easy to use tool for switching the default will solve the problem for the masses. Easy to use tools are good, but ultimately, it's the default value as set by the distribution that's critical. Allowing distro's to support high end applications and games with the same settings...even on the same session...right out of the box should be our goal. -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Ian R. <id...@us...> - 2003-04-09 18:25:19
|
Jens Owen wrote: > Ian Romanick wrote: > >> My current thinking is to leave the non-vsync behavior (current >> trunk). When the global configuration file becomes available, the >> behavior will be determined by a value in the config file. Each >> distro will then be able to set whatever value in the global config >> file it thinks will be serve its customers. At that time we can >> re-evaluate the issue. >> >> In the mean time I'm also going to modify glxgears to make use of a >> few of the new GLX extensions supported by the texmem-0-0-1 branch. >> I'll send out the new version in a few days. > > > This illustrate my concern with the config file issue. We're putting > distros in the situation of having to choose which market they are in > when we should really be concentrating on the API or extending the API > so that one graphics subsystem can work well for both the gaming and the > multi-million dollar app. > > If the current implementation is in violation of the specification, why > can't we create an extension that can be used by game developers who > need to run frame rates higher than the vertical refresh limit? In either case, the app doesn't necessarily have to change. In the trunk the user can enable the vsync behavior with 'export LIBGL_THROTTLE=1', and in the texmem branch the user can disable the vsync behavior with 'export LIBGL_NO_VSYNC=1'. In terms of user "power," both are equal. The only question is of the default. > Yes, this is more work for us, and yes it will take time for all games > to adopt the extension...but this is along term fix that we should > provide rather than segmenting the market long term. I think this is one of the cases where you can't please all of the people all of the time. I would really like for our implementation to be correct to the letter (and the spirit) of the spec. I think that will give us more credibility in the eyes of a lot of developers. It will do so especially in the eyes of the types of developers that a lot of people (like me!) who are enthusiastic about various open-source operating systems would like to attract. At the same time, I don't want to spend any more time than I have to answering questions like, "gears/quake3/tuxracer/whatever only gets 72fps now, but it used to get 157fps. What gives?!?" > No, I don't believe that an easy to use tool for switching the default > will solve the problem for the masses. Easy to use tools are good, but > ultimately, it's the default value as set by the distribution that's > critical. Allowing distro's to support high end applications and games > with the same settings...even on the same session...right out of the box > should be our goal. Using the proposed config file *or* the existing env. variables, we can achieve 99% of that. If I do: glxgears & LIBGL_NO_VSYNC=y glxgears & I get one window running at 75fps and one at 1480fps. We could get the same fragmentation today. We could easilly have a distro that prefered the by-the-book implementation. It could put 'export LIBGL_THROTTLE=1' in /etc/bashrc. Having it handled by a config file makes the differences more obvious and much easier (for everyone) to manage. |
From: Jens O. <je...@tu...> - 2003-04-09 20:18:48
|
Ian Romanick wrote: > In either case, the app doesn't necessarily have to change. If the game applications can't use an extension to enable this, then we are creating a long term either/or type of issue by avoiding a solution that's controlled by the application via extending OpenGL. I agree there are many short term possibilities that can (and should) be brought into play in to handle the either/or situation we have to live with in the existing application base. -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Jens O. <je...@tu...> - 2003-04-09 20:38:39
|
Jens Owen wrote: > Ian Romanick wrote: > >> In either case, the app doesn't necessarily have to change. > > > If the game applications can't use an extension to enable this... Ian, After further reading on GLX_MESA_swap_control I see you've already defined the extension I was advocating (I assume that you defined it, because the only place googe found it was a DRI-devel posting from you). I'll work on removing that shoe flavor from my mouth now... Regards, Jens -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Andreas S. <A.S...@gm...> - 2003-04-07 21:02:29
|
Am 2003.04.07 18:51:38 +0200 schrieb(en) Keith Whitwell: > My experience with the tdfx driver, which used to default to=20 > sync-to-vsync swapping is that you really don't want to be=20 > releasing drivers that default that way, as 99% of the users just=20 > want gears to go as fast as possible, and that 98% of those will=20 > post on dri-devel if it doesn't. Which ends up wasting a lot of=20 > time with the same question over and over, or else makes us look=20 > uncaring because we can't be bothered answering the same question=20 > one more time. >=20 > Keith >=20 1. I was told that glxgears never was a good "benchmark". But for people who just want to use it as a simple check if direct rendering works, glxgears should just be updated with support for the GLX_SGI_swap_control (and GLX_MESA_swap_control) extension. If the extension is available, print out some docu about the vblank-facts, set it to 0 and go on... Maybe even something like a second scene/version with much more=20 cogwheels, multitexturing, blending, env.mapping could be added. (polished, oily or rusty gears or even chains could be shown...) 2. The first XFree-Version with code from current texmem-branch would be 4.4.0 or so, there should be enough time to communicate the "new" (=3Dright) behavior. It can just be added to the DRI-FAQ. 3. Maybe some applications could even gain performance or become less "laggy" with the new scheduler of linux 2.5 / 2.6 and the new vblank-behavior? Has anyone tried this? But 4: what happens when more 3d-contexts are open: Could one slow context brakedown the others? best regards, Andreas |
From: Ian R. <id...@us...> - 2003-04-07 22:06:13
|
Andreas Stenglein wrote: > Am 2003.04.07 18:51:38 +0200 schrieb(en) Keith Whitwell: > >> My experience with the tdfx driver, which used to default to >> sync-to-vsync swapping is that you really don't want to be releasing >> drivers that default that way, as 99% of the users just want gears to >> go as fast as possible, and that 98% of those will post on dri-devel >> if it doesn't. Which ends up wasting a lot of time with the same >> question over and over, or else makes us look uncaring because we >> can't be bothered answering the same question one more time. >> >> Keith >> > > 1. I was told that glxgears never was a good "benchmark". > But for people who just want to use it as a simple check if > direct rendering works, glxgears should just be updated with > support for the GLX_SGI_swap_control (and GLX_MESA_swap_control) > extension. > If the extension is available, print out some docu about the > vblank-facts, set it to 0 and go on... As far as setting the swap interval to 0, that would only work with the MESA version. That and being able to query the current swap interval are the only differences between the two. > 2. The first XFree-Version with code from current texmem-branch > would be 4.4.0 or so, there should be enough time to communicate > the "new" (=right) behavior. It can just be added to the DRI-FAQ. BUT! With the code in the trunk we will get questions / bug reports from people. The code is only on the texmem-0-0-1 branch now, and we already received at least 2 questions in the last 2 weeks. > 3. Maybe some applications could even gain performance > or become less "laggy" with the new scheduler of linux 2.5 / 2.6 > and the new vblank-behavior? Has anyone tried this? > > But 4: what happens when more 3d-contexts are open: > Could one slow context brakedown the others? Only if the contexts are within one process. I believe this is part of the reason why the GLX_SGIX_swap_group extension was created. http://oss.sgi.com/projects/ogl-sample/registry/SGIX/swap_group.txt |
From: Michel <mi...@da...> - 2003-04-07 23:02:14
|
On Mon, 2003-04-07 at 18:45, Ian Romanick wrote: > > There are basically four states that the driver can be in WRT vertical > refresh synchronization. > > 1. Application preference. The application can select the number of > vertical refreshes that must occur between buffer swaps (aka the swap > interval). The default value is 1. This is the default setting. > > 2. No-vsync. No swap throttling or refresh synchronization occurs. > This is the old default, but it is now controlled by setting > 'LIBGL_NO_VSYNC=1'. > > 3. "Throttle refresh." This is like #1, but the application cannot > change the swap interval from the default setting of 1. This is > selected by 'LIBGL_THROTTLE_REFRESH=1'. IMHO, this setting is of little > use and should be depricated. Why not simply drop it in favour of the new default? Assuming it stays, that is, which I vote for, along with adding support for the swap extension(s) to glxgears. Don't the nvidia drivers default to this as well? > 4. Sync to refresh. I have grouped this option apart from the others > because it tries to achieve a different purpose. The other settings > control the swap-rate, but this option tries to prevent tearing during > buffer swaps. The current implementation is to wait for the vertical > refresh before swapping and is selected with 'LIBGL_SYNC_REFRESH=1'. I > believe that this option is mis-named. When page-flipping is enabled, > this option is not needed. Yes it is, as Leif pointed out. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Alan H. <al...@fa...> - 2003-04-07 23:15:44
|
On Tue, Apr 08, 2003 at 01:02:07AM +0200, Michel D=E4nzer wrote: > On Mon, 2003-04-07 at 18:45, Ian Romanick wrote:=20 > >=20 > > There are basically four states that the driver can be in WRT vertica= l=20 > > refresh synchronization. > >=20 > > 1. Application preference. The application can select the number of=20 > > vertical refreshes that must occur between buffer swaps (aka the swap= =20 > > interval). The default value is 1. This is the default setting. > >=20 > > 2. No-vsync. No swap throttling or refresh synchronization occurs.=20 > > This is the old default, but it is now controlled by setting=20 > > 'LIBGL_NO_VSYNC=3D1'. > >=20 > > 3. "Throttle refresh." This is like #1, but the application cannot=20 > > change the swap interval from the default setting of 1. This is=20 > > selected by 'LIBGL_THROTTLE_REFRESH=3D1'. IMHO, this setting is of l= ittle=20 > > use and should be depricated. >=20 > Why not simply drop it in favour of the new default? Assuming it stays= , > that is, which I vote for, along with adding support for the swap > extension(s) to glxgears. Don't the nvidia drivers default to this as > well? =20 No. I get over 4000 fps with glxgears on a Quadro4 750XGL, by default. Alan. |