Ronny V. Vindenes schrieb:
I haven't tested it yet either, but it struck me that if we're going to add support for "non-essential" software-only extensions then we probably should add a driconf option to enable/disable such extensions since their existence can affect which code paths clients take?
Well, once the programmable codepath in Mesa is optimized a bit, this probably won't be much slower than fixed-function, even with hardware tcl. I think that programmable functionality an essential extension, if you look about at the discussion about glitz, X on top of OpenGL, etc Jon Smirl pointed out that even fragment shaders might be necessary By the way, the i915 driver already does vertex program in software. An option in driconf to enable NV_vertex_program might be useful, I left it out of my patch, but the the only thing to be done to enable it once my patch is applied would be to add it to the extension string. Maybe we should seperate between software-only extensions that don't really cause a slowdown (like vertex programs), and those that do (like fragment programs or depth textures), that would be similar to what Nvidia does (the latter have to be enabled seperately, while the former are always there). The only thing in terms of hardware acceleration that we loose when vertex programs are enabled is hardware tcl. From the perspective divide onward everything is accelerated again.
Philipp Klaus Krause
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
