On Thu, 2009-06-25 at 18:39 +0200, Jerome Glisse wrote: > 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) ?
>From a byte order POV, I basically agree that surfaces make most sense for scanout buffers - the (legacy?) display engine seems to be the only relevant functional unit without any byte-swapping facilities. However, I'm not sure we can strictly couple the use of surfaces to buffers being pinned or scanned out: E.g. when we stop pinning the radeondrmfb buffer all the time, it would require different CPU access depending on whether it happens to be pinned / scanned out, and I don't know if there's any mechanism for handling that. Also consider the DRI2 page flipping case. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
