On Wed, Dec 04, 2002 at 06:28:55PM -0800, Allen Akin wrote: > 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.
I believe that application level preference setting is the only reasonable way to do it for remote rendering, modulo the wrapper library thread. :) > | 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? What's "fast" will depend on how the app uses the API. For example, sending packed ubyte colors my be faster for a given card, but if the app calls glColor4f a lot, it may be faster to send float colors and avoid the conversion from float to ubyte. This isn't the best example (since the driver could probably deduce the usage at run-time), but it's the right general idea. A lot of this stuff could be covered by some sort of extensions, but I doubt that many apps (even the ones that could really benefit) would use them. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
