On Wed, Dec 04, 2002 at 02:21:30PM -0800, Ian Romanick wrote: | Remote indirect rendering is a problem no matter how you slice it.
Well, maybe not if you handle preference-setting at the application level, rather than trying to do it at the library or driver levels. Then it can be dynamic, or there can be multiple sets of preferences for local vs. remote connections, or different preferences can be used simultaneously if the app has both types of connections open at the same time. | Here's another example that somebody just reminded me about. Quite a few of | the "CAD" cards out there have ways to tune internal optimization | parameters. These can be things as simple as what vertex format to prefer | (i.e., float colors vs. packed ubyte colors) ... I'm confused about this one. Surely the driver knows which vertex formats are efficient. Is this a space/time tradeoff hint that's given to the driver for controlling display-list compilation? Or something more sophisticated? Or a tool for optimizing benchmark results? | As far as I can tell, there is no way either an app or a wrapper library | could communicate this information to the driver. The usual way to solve this kind of problem is with an extension. That way the app can control which vertex formats are used for which display lists (for example) based on how it knows the dlists will be used. Otherwise, the driver has to apply the vertex format preference to all dlists, and it's easy to see how that could make performance worse or even lead to poor rendering (if the colors aren't stored with enough precision for some dlists). Yes, this requires source-code changes in the app. But if the functionality is genuinely valuable, once one vendor provides it, the market will drive other hardware vendors to provide it and app developers to use it. And the OpenGL extension mechanism provides a portable way to access the feature. Controlling this sort of stuff with a driver-level preference is sometimes useful as a temporary workaround, or as a solution to political problems like finessing benchmarking rules, but it isn't something you'd want to depend on in the long run because it has too many failure modes. If folks want to spend effort on this they should be aware that it's a fragile mechanism with a lot less return for the effort than simply handling preferences at the right level (in the apps). Don't expect it to solve the hard problems. Allen ------------------------------------------------------- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
