Re: [RFC][PATCH] drm/radeon/kms: add initial colortiling support.

[Jerome G. <gl...@fr...>]

On Mon, 2009-06-29 at 12:21 +0200, Michel Dänzer wrote:
> 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?

The more i think about surface the more i think we should forget them,
it really sounds like a lot of pain to allocate surface on fault and i
fear we will have enough concurrent map to run out of surface reg and
thus lead to surface reg allocation contention issue which will kill
performance badly.

Of course we don't have a good infrastructure in X to deal with tiling
or swapping (assuming wfb is too slow and not an option). Still, i
think we better teach userspace to deal with that rather than hopping
that we will have some hw does the magic for us.

Cheers,
Jerome