On Wed, 2009-06-24 at 10:21 +1000, Dave Airlie wrote: > From: Dave Airlie <airl...@redhat.com> > > 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? > Depth buffer handling? > When we run out of surface regs - needs better handling. > > Future features: > texture tiling - need to relocate texture registers TXOFFSET* with tiling > info.
Worked on that today and i think we can restrict our self to set surface only for pinned buffer (ie scanout buffer). Use case, which i believe defite surface : tiled bo in vram mapped with surface backing it, userspace know that it can access linearly the surface, bo get evicted from vram and userspace mapping invalidated, there is no way (at least i don't think so, except calling some ioctl on each memory access which is a no go) for userspace to know that now it has to until by itself. So i believe we should only set surface on scanoutbuffer and let userspace deal with untiling. I don't think this is a drawback, we can use blit to until a buffer (macro only) or simply have clever code to access the memory, if we are in a fallback we already loose. Am i missing somethings ? Does it make sense to only program surface on scanout (this would give a simpler API for tiling) ? Cheers, Jerome ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
