From: <sm...@wa...> - 2003-04-23 09:37:37
|
Good day In light of the new driver configuration project (the one using XML to store config options, accessible by GUI and text editor) beginning the intial coding phase, deciding on common driver options should be done now. A quick summary of what I'm talking about for those who do not have time or don't care to read the design doc: All drivers have configuration options, some of these options are unique to (a) particular driver(s) and some are not. Deciding on common options used by more than one driver makes life easier in the long run, eg it prevents divergence in terms of naming of the same option. I am talking about environment variables here. eg. LIBGL_NO_VSYNC=1 LIBGL_THROTTLE_REFRESH=1 LIBGL_DEBUG=true LIBGL_SYNC_REFRESH=1 LIBGL_ALWAYS_INDIRECT=1 So if anyone has any config options which they feel should or should not be comon options let me know. Examples Vsync on / off 16 / 32 bit colour Should probably be common. I'm going to ask on #dri-devel irc.freenode.net. But feel free to ask on there and give my email address (I am only in one time zone...) or ask them to post their thoughts on dri-devel. Liam ---- it depends |
From: Felix <fx...@gm...> - 2003-04-23 10:16:17
|
On Tue, 22 Apr 2003 14:54:13 +0200 sm...@wa... wrote: > Good day > > In light of the new driver configuration project (the one using XML to > store config options, accessible by GUI and text editor) beginning the > intial coding phase, deciding on common driver options should be done > now. Thanks for taking up this issue! > > A quick summary of what I'm talking about for those who do not have time > or don't care to read the design doc: > > All drivers have configuration options, some of these options are unique > to (a) particular driver(s) and some are not. > > Deciding on common options used by more than one driver makes life > easier in the long run, eg it prevents divergence in terms of naming of > the same option. > > I am talking about environment variables here. > eg. > > LIBGL_NO_VSYNC=1 > LIBGL_THROTTLE_REFRESH=1 > LIBGL_DEBUG=true > LIBGL_SYNC_REFRESH=1 > LIBGL_ALWAYS_INDIRECT=1 LIBGL_DEBUG and LIBGL_ALWAYS_INDIRECT affect behaviour of libgl before a client-side 3D driver is loaded. The new configuration scheme happens only inside the driver. So these two options don't make sense in this scheme. > > So if anyone has any config options which they feel should or should > not be comon options let me know. > > Examples > Vsync on / off > 16 / 32 bit colour The frame buffer color depth is set in XF86Config. What should be configured in the new configuration file is the *texture* color depth. Vsync is controlled by the other three environment variables above. > > Should probably be common. > > I'm going to ask on #dri-devel irc.freenode.net. > But feel free to ask on there and give my email address (I am only in > one time zone...) or ask them to post their thoughts on dri-devel. > > Liam > ---- > it depends Regards, Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything fx...@gm... \___/ \___/ U at the same time. |
From: <sm...@wa...> - 2003-04-23 19:44:53
|
> > In light of the new driver configuration project (the one using XML > > to store config options, accessible by GUI and text editor) > > beginning the intial coding phase, deciding on common driver options > > should be done now. > > Thanks for taking up this issue! No problem even though I was one of those protesting against the use of XML, this is important no matter what configuration file type is used, seeing as how this will affect the drivers. > > A quick summary of what I'm talking about for those who do not have > > time or don't care to read the design doc: > > > > All drivers have configuration options, some of these options are > > unique to (a) particular driver(s) and some are not. > > > > Deciding on common options used by more than one driver makes life > > easier in the long run, eg it prevents divergence in terms of naming > > of the same option. > > > > I am talking about environment variables here. > > eg. > > > > LIBGL_NO_VSYNC=1 > > LIBGL_THROTTLE_REFRESH=1 > > LIBGL_DEBUG=true > > LIBGL_SYNC_REFRESH=1 > > LIBGL_ALWAYS_INDIRECT=1 > > LIBGL_DEBUG and LIBGL_ALWAYS_INDIRECT affect behaviour of libgl before > a client-side 3D driver is loaded. The new configuration scheme > happens only inside the driver. So these two options don't make sense > in this scheme. You are correct they are not driver (esp not dri driver) options, but they are examples of environment variables. <g> > > So if anyone has any config options which they feel should or should > > not be comon options let me know. > > > > Examples > > Vsync on / off > > 16 / 32 bit colour > > The frame buffer color depth is set in XF86Config. What should be > configured in the new configuration file is the *texture* color depth. > Vsync is controlled by the other three environment variables above. Man oh man we just don't comunicate very well. <g> I pretty much know that I covered vsync above, the are two different example lists. Who said it was fb colour depth? <g> Liam ---- it depends |
From: Ian R. <id...@us...> - 2003-04-23 20:39:53
|
sm...@wa... wrote: > I am talking about environment variables here. > eg. > > LIBGL_NO_VSYNC=1 > LIBGL_THROTTLE_REFRESH=1 > LIBGL_DEBUG=true > LIBGL_SYNC_REFRESH=1 > LIBGL_ALWAYS_INDIRECT=1 > > So if anyone has any config options which they feel should or should > not be comon options let me know. > > Examples > Vsync on / off > 16 / 32 bit colour > > Should probably be common. How about an option to enable / disable page flipping? There's also the 'LIBGL_PERFORMANCE_BOXES' env. var. that's used by a couple drivers. A few drivers also have *_NO_IRQS, *_NO_TCL, *_NO_VTXFMT, and *_NO_CODEGEN. These are mostly debug / developer options. When FXT1 support is added for Voodoo4 (if ever) and i830/i845 we'll probably want an option to force texture compression on. I can't think of any others right now. I think we'll just have to be careful in the future when options are added. When we add an option for a specific driver, we'll have to ask, "Could this option or some slight variant be generally useful?" |
From: <sm...@wa...> - 2003-04-24 17:42:56
|
> > I am talking about environment variables here. > > eg. > > > > LIBGL_NO_VSYNC=1 > > LIBGL_THROTTLE_REFRESH=1 > > LIBGL_DEBUG=true > > LIBGL_SYNC_REFRESH=1 > > LIBGL_ALWAYS_INDIRECT=1 > > > > So if anyone has any config options which they feel should or should > > not be comon options let me know. > > > > Examples > > Vsync on / off > > 16 / 32 bit colour > > > > Should probably be common. > > How about an option to enable / disable page flipping? There's also > the 'LIBGL_PERFORMANCE_BOXES' env. var. that's used by a couple > drivers. A few drivers also have *_NO_IRQS, *_NO_TCL, *_NO_VTXFMT, > and *_NO_CODEGEN. These are mostly debug / developer options. Yeah I think so, was eyeing them on the dri_driver_features page. > When FXT1 support is added for Voodoo4 (if ever) and i830/i845 we'll > probably want an option to force texture compression on. I can't > think of any others right now. > > I think we'll just have to be careful in the future when options are > added. When we add an option for a specific driver, we'll have to > ask, "Could this option or some slight variant be generally useful?" Well that pretty much is the whole problem right there. Either its no / few common options now and when options are added they must be considered for common option status or; We have many common options now and when a new option is added look to see if its already covered by a common option. Obviously it will never be one or the other every time. But trying not to let it become a mess is th eimportant thing here. Liam ---- it depends |
From: Felix <fx...@gm...> - 2003-04-24 10:32:25
|
I remembered some talking about options that would change the initial state to enable certain features for applications that don't know about them, such as anisotropic filtering and anti-aliasing. Are there more such features that are supported by the existing hardware and DRI drivers? On Tue, 22 Apr 2003 14:54:13 +0200 sm...@wa... wrote: > Good day > > In light of the new driver configuration project (the one using XML to > store config options, accessible by GUI and text editor) beginning the > intial coding phase, deciding on common driver options should be done > now. [...] > Liam > ---- > it depends ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything fx...@gm... \___/ \___/ U at the same time. |
From: <sm...@wa...> - 2003-04-24 17:43:02
|
On Thu, 24 Apr 2003 12:32:13 +0200 Felix K=FChling <fx...@gm...> wrote: > I remembered some talking about options that would change the initial > state to enable certain features for applications that don't know > about them, such as anisotropic filtering and anti-aliasing. Are there > more such features that are supported by the existing hardware and DRI > drivers? You mean like the options available under windows drivers? I'll have to go trawling for environment variables in the web archives, although the only ones I can remember seeing are things like verbose debugging, diabling tcl, irq's, code gen, and of course vsync debate. One thing I've just though of is do we just pretend that features like HyperZ don't exist because they are not supported under DRI, and as of yet there are no "plugins" from ATI? =20 Liam ---- it depends=20 |
From: Mike A. H. <mh...@ww...> - 2003-04-24 19:17:33
|
On Thu, 24 Apr 2003 sm...@wa... wrote: >> I remembered some talking about options that would change the initial >> state to enable certain features for applications that don't know >> about them, such as anisotropic filtering and anti-aliasing. Are there >> more such features that are supported by the existing hardware and DRI >> drivers? >You mean like the options available under windows drivers? > >I'll have to go trawling for environment variables in the web archives, >although the only ones I can remember seeing are things like verbose >debugging, diabling tcl, irq's, code gen, and of course vsync debate. > >One thing I've just though of is do we just pretend that features like >HyperZ don't exist because they are not supported under DRI, and as of >yet there are no "plugins" from ATI? ATI has their own proprietary drivers which implement support for the features in their hardware. I'm not sure that it would make any sense to them to provide proprietary hardware support both as full drivers and also go and do more work to provide it also as a plugin to an open source driver. I'd like to see full open source drivers as the next guy would, but I don't see any vendor providing hardware support in 10 different formats as that isn't something realistic. -- Mike A. Harris |
From: <sm...@we...> - 2003-04-24 23:28:50
|
> >> I remembered some talking about options that would change the initial > >> state to enable certain features for applications that don't know > >> about them, such as anisotropic filtering and anti-aliasing. Are there > >> more such features that are supported by the existing hardware and DRI > >> drivers? > >You mean like the options available under windows drivers? > > > >I'll have to go trawling for environment variables in the web archives, > >although the only ones I can remember seeing are things like verbose > >debugging, diabling tcl, irq's, code gen, and of course vsync debate. > > > >One thing I've just though of is do we just pretend that features like > >HyperZ don't exist because they are not supported under DRI, and as of > >yet there are no "plugins" from ATI? > > ATI has their own proprietary drivers which implement support for > the features in their hardware. I'm not sure that it would make > any sense to them to provide proprietary hardware support both as > full drivers and also go and do more work to provide it also as a > plugin to an open source driver. > > I'd like to see full open source drivers as the next guy would, > but I don't see any vendor providing hardware support in 10 > different formats as that isn't something realistic. Ja well no fine. This wasn't a rant against ATI, imo they are the best supporters of oss in terms of drivers for graphics cards. Same thing goes for features like texture compression, pretend it doesnt exist? implement it and say its not supported? in other words how do you plan for possible future occurences. Do it only when it absolutely has to be done, or before then. lIam |
From: D. H. <dha...@dr...> - 2003-04-25 15:48:18
|
The beauty of the configuration system is that configuration options do not have to be planned out before hand. They can be added as we go along. This is why we have the configuration tool query the driver. This is also one of the benefits of using a format like XML where we can describe the options in the level of detail that we need. These two important features of the new system allows us to have a GUI tool parse the configuration data and be able to render the actual GUI forms based on that. The only thing to remember is to not randomly add options ... if it is a generic option then we can add a macro to assist developers in implementing that configuration option. The more controled approach we use ... the better off everyone will be with this. On Fri, 25 Apr 2003 sm...@we... wrote: > > > >> I remembered some talking about options that would change the initial > > >> state to enable certain features for applications that don't know > > >> about them, such as anisotropic filtering and anti-aliasing. Are there > > >> more such features that are supported by the existing hardware and DRI > > >> drivers? > > >You mean like the options available under windows drivers? > > > > > >I'll have to go trawling for environment variables in the web archives, > > >although the only ones I can remember seeing are things like verbose > > >debugging, diabling tcl, irq's, code gen, and of course vsync debate. > > > > > >One thing I've just though of is do we just pretend that features like > > >HyperZ don't exist because they are not supported under DRI, and as of > > >yet there are no "plugins" from ATI? > > > > ATI has their own proprietary drivers which implement support for > > the features in their hardware. I'm not sure that it would make > > any sense to them to provide proprietary hardware support both as > > full drivers and also go and do more work to provide it also as a > > plugin to an open source driver. > > > > I'd like to see full open source drivers as the next guy would, > > but I don't see any vendor providing hardware support in 10 > > different formats as that isn't something realistic. > Ja well no fine. > > This wasn't a rant against ATI, imo they are the best supporters of oss > in terms of drivers for graphics cards. > > Same thing goes for features like texture compression, pretend it doesnt > exist? implement it and say its not supported? in other words how do you > plan for possible future occurences. Do it only when it absolutely has > to be done, or before then. > > lIam > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- //========================================================\\ || D. Hageman <dha...@dr...> || \\========================================================// |