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 <[email protected]>
> > >
> > > 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
------------------------------------------------------------------------------
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
