On Sunday 14 August 2005 14:15, Philipp Klaus Krause wrote: > Adam Jackson schrieb: > > NV_texture_rectangle > > This shouldn't be really necessary if one is > willing to waste some texture memory.
In some cases, quite a lot of memory. A 513x513 texture wastes between 1.5 and 3M of memory depending on your color depth. You could offset this some by artificially lowering the maximum texture size. That's probably not a terrible idea for a tunable anyway, since a few older cards have fairly small texture caches and 512^2 textures will basically defeat them. > > ARB_multitexture > > OK. Everything except the SiS 6326 should supports it, though I don't > know about mach64 (the driver has the extension, but I don't think the > hardware has really more than one texture unit). There's a lot of cards that don't support this, just not many that we have drivers for. Pretty sure the virge and savage3d don't really support this, for example. > Maybe I'll see if I can get Xgl eunning on the r128 or some other older > card. Try the Xglx server first. In the steady state (not moving the Xglx window) your performance should be within a wild-assed guess of about 10-20% of what you might see from Xegl. To be accurate, Xegl relative to Xglx eliminates a few round trips for things like drawable and context creation, clip list updates, and buffer swaps. Those aren't often the bottleneck. Also you wouldn't have your classic DDX chewing up card memory for offscreen pixmaps, which you might be able to work around with suitable use of XAA options. This is not meant to discourage, we really do want to know where the cutoff point is for tolerable performance on older cards. But Xglx will give you a reasonable idea of what's possible. And it's the same driver for both GLX and EGL, so improvements to the one side help the other side too. - ajax
pgpBpUamxQQsJ.pgp
Description: PGP signature
