On Wed, 2009-06-24 at 15:29 +0200, Thomas Hellström wrote: > Michel Dänzer 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? > >> > > > > 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. > > > > > > > Hmm, > Out of interest, are there actually buffer objects in TT that are used > during normal rendering?
I don't think there are normally at this time, as long as everything fits in VRAM. Which isn't guaranteed though, especially with small amounts of VRAM. So it needs to be dealt with anyway. > Doesn't that affect performance adversely on devices with on-card vram? For pure GPU rendering, sure. But for alternate GPU and CPU rendering, it might actually be better to keep some BOs in TT in some cases. (Maybe even with pure GPU rendering in some cases, if there would be VRAM thrashing otherwise). -- 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
