On 11 jan 2010, at 21.17, Zack Rusin wrote: > On Monday 11 January 2010 16:15:38 Jakob Bornecrantz wrote: >> On 11 jan 2010, at 17.49, Zack Rusin wrote: >>> I think the other stuff is acceptable. Take a look at the docs and >>> let me know >>> what you think. >> >> Hmm I don't think you should remove the CAPs but instead just say if >> level X then CAPs Y,Z,W,Q are assumed to be present. This way the >> hardware that fall between the cracks can expose one level plus the >> extra CAPs it can do. > > Would that be useful for anything? Or do you mean feature level + > exceptions, > oterhwise what's the point of feature levels if nothing supports > them fully.
Take the i915 for instance it can do level 1, but it can also do real npot textures. Not just for last_level == 0. <edit>Ian said a lot more and better</edit> > >> Another thing level 3 and below harder can not do ARB_npot but they >> can do NV_texture_rect, the only hardware we have drivers that this >> matter for is nv30 (I think) and r300. > > Yes, that's what the "unnormalized coords" part is about :) What I meant is that in st_extensions.c you check for feature level > 1 and set ARB_npot if that is true. But it isn't untill level 4 "2D textures pot if MipCount >1" is set to no. So to make the test correct and cover the i915 case the test should be level >= 4 or CAP_NPOT. Cheers Jakob. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
