From: Michel D. <mi...@da...> - 2009-06-29 10:22:29
|
On Wed, 2009-06-24 at 20:17 +0200, Jerome Glisse wrote: > On Wed, 2009-06-24 at 13:25 +0200, Michel Dänzer wrote: > > On Wed, 2009-06-24 at 10:21 +1000, Dave Airlie wrote: > > > From: Dave Airlie <ai...@re...> > > > > > > This adds color tiling support for buffers in VRAM, it enables > > > a color tiled fbcon and a color tiled X frontbuffer. > > > > > > It changes the API: > > > adds two new parameters to the object creation API (is this better than > > > a set/get tiling?) we probably still need a get but not sure for what yet. > > > relocs are required for 2D DST_PITCH_OFFSET and SRC_PITCH_OFFSET type-0, > > > and 3D COLORPITCH registers. > > > > > > TTM: > > > adds a new check_tiling call to TTM, gets called at fault and around > > > bo moves. > > > > > > Issues: > > > Can we integrate endian swapping in with this? > > > > Not sure about that in gernal; unless I'm missing something, it would > > require moving BOs from TT to VRAM for CPU mappings, and I don't think > > that's a good idea. > > > > It might be useful for scanout buffers though. Maybe another object > > creation parameter which specifies the CPU byte swapping vs. the GPU > > byte order (little endian) could work, then we could use surface > > registers for VRAM mappings or GPU byte swapping bits for GPU access > > to/from TT. > > 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). > > Using gem map ioctl makes me wonder if we want to specify tiling at > bo creation time. If we got several users, each one with its X server > we might exhaust the number of surface register. Over the weekend I discovered that unfortunately the byte swapping bits of the 3D engine in my PowerBook's RV350 seem to be ineffective. So I thought some more about how byte order could be handled, and I've come up with the following: * Specify byte-swapping between CPU and GPU access at BO creation time. * Swap bytes accordingly when moving BOs between TT (CPU byte order) and VRAM (GPU byte order). * If byte swapping is required, use surface registers for CPU mappings while BOs reside in VRAM. (Re-)Allocate surface registers on page faults. * If byte swapping is required, only allow GPU access in VRAM (can be handled in userspace I think). That is assuming we can at least sensibly swap bytes when moving BOs - hopefully the byte-swapping bits of DMA transfers work... otherwise, I don't see any other solution but to leave byte order completely up to BO users, which would probably preclude 16 bpp in X. Could a scheme like this be useful for tiling as well? -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer |