On Wed, 2009-06-24 at 22:32 +0200, Roland Scheidegger wrote: > On 24.06.2009 20:17, Jerome Glisse wrote: > > I think we should let user ask at gem map ioctl time if userspace wants > > an surface backed mapping or not, and gem map will reply with a success > > or failure. So if object is in vram and there is a surface reg available > > it will succeed, if object is in system ram it will report to userspace > > that there is not automatic untiling and that userspace is on its own > > to untile the buffer. > > > > For the X server that the front buffer is mapped first and never > > unmapped, it should get a surface (assuming no other process already > > stole all the surface). For pixmap i think be better of not using > > tiling for time being (or macro tiling only benchmark below). > > > > Mesa, map/unmap things and should be able to untile on its own for > > front/zbuffer (we need to add texture but i am not sure it's worth > > it, see benchmark below). > I don't see benchmark with texture tiling below... > It definitely made some difference though when I implemented (and > measured...) this, though I never really worried that much about tiled > compressed textures, not sure micro tiled is even possible (and would > make sense) but macro tiled certainly should be (but IIRC I tried to > measure it and it didn't make much of a difference on r200 but it could > have changed with newer chips). > That said, don't forget that the performance improvement this gives is > chip specific, generally giving more improvement with newer chips. IIRC > you definitely don't want to micro tile the front buffer pre-r300. > > Roland
Yeah i loose texture benchmark but it was very small 1-2% on quake3 but maybe quake3 isn't asking for much texture filtering, assuming filtering is the process which benefit from tiled texture. Cheers, Jerome ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
