[Mesa-dev] [RFC] r600-r800 2D tiling

[Simon Farnsworth]

(resending due to my inability to work my e-mail client - I neither cc'd
Jerome, nor used the correct identity, so the original appears to be held in
moderation).

On Thursday 12 January 2012, Jerome Glisse <j.glisse at gmail.com> wrote:
> Hi,
> 
> I don't cross post as i am pretty sure all interested people are reading
> this mailing-list.
> 
> Attached is kernel, libdrm, ddx, mesa/r600g patches to enable 2D tiling
> on r600 to cayman. I haven't yet done a full regression testing but 2D
> tiling seems to work ok. I would like to get feedback on 2 things :
> 
> - the kernel API

I notice that you don't expose all the available Evergreen parameters to
user control (TILE_SPLIT_BYTES, NUM_BANKS are both currently fixed by the
kernel). Is this deliberate?

It looks like it's leftovers from a previous attempt to force Evergreen's
flexible 2D tiling to behave like R600's fixed-by-hardware 2D tiling.

> - using libdrm/radeon as common place for surface allocation
> 
> The second question especialy impact the layering/abstraction of gallium
> btw winsys as it make libdrm/radeon_surface API a part of the winsys.
> The ddx doesn't need as much knowledge as mesa (pretty much the whole
> mipmap tree is pointless to the ddx). So anyone have strong feeling
> about moving the whole mipmap tree computation to this common code ?
>
I'm in favour - it means that all the code relating to the details of how
modern Radeons tile surfaces is in one place.

I've looked at the API you introduce to handle this, and it should be very
easy to port to a non-libdrm platform - the only element of the API that's
currently tied to libdrm is radeon_surface_manager_new, so a new platform
shouldn't struggle to adapt it.

I do have one question; how are you intending to handle passing the tiling
parameters from the DDX to Mesa for GLX_EXT_texture_from_pixmap? Right now,
it works because the DDX uses the surface manager's defaults for tiling, as
does Mesa; I would expect Mesa to read out the parameters as set in the
kernel and use those.

At a future date, I can envisage the DDX wanting to choose a different
tiling layout for DRI2 buffers, or XComposite backing pixmaps (e.g. because
someone's benchmarked it and found that choosing something beyond the bare
minimum that meets constraints improves performance); it would be a shame if
we can't do this because Mesa's not flexible enough.

-- 
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/