radeonsi tiling dilema

[Jerome Glisse]

On Wed, Apr 03, 2013 at 06:11:26PM +0200, Michel Dänzer wrote:
> On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: 
> > On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer <michel at daenzer.net>
> > wrote:
> >         On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
> >         >
> >         > Some might argue that we could just export the table content
> >         to
> >         > userspace, but that would loose information and possibly
> >         froze the
> >         > tile mode table forever as API.
> 
> The current index scheme already is de facto part of the API.

Only index 4,8,9,13 are part of current API no of the other are use.

> 
> >         The information we loose is what index
> >         > match to prefered surface format/type combination.
> 
> How so? We can add descriptive names for the existing indices.

Look at my kernel patch, for instance i define :
RADEON_TILE_MODE_COLOR_2D_32BPP

You can then query the kernel with RADEON_TILE_MODE_COLOR_2D_32BPP which
gave you corresponding tile index and also correspond gb tile config.

http://people.freedesktop.org/~glisse/si2d-sol1/0001-drm-radeon-add-tile-mode-ioctl.patch

> 
> >         And the tile mode
> >         > might be considered API as if kernel ever change what
> >         userspace expect
> >         > then we might break some userspace.
> 
> Not sure how that could happen if the purpose of each index is clearly
> defined.

Well that's the question, are we happy, confident that we will never shuffle
around the tile mode array. If so then we need to hard code tile index with
a meaning and call it API. It's already the case for index 4,8,9,13

> 
> 
> >         Maybe I'm missing the problem, but if libdrm_radeon were to
> >         get the
> >         tiling mode index chosen by radeonsi, and could retrieve the
> >         tiling
> >         parameters for each index from the kernel, it should be able
> >         to
> >         calculate things properly, shouldn't it?
> >         
> > 
> > 
> > Let's not discuss about who/where the index is pick. No matter where
> > it happens the question is do we want to hardcode tile index and make
> > it api or do we want to hide it behind symbolic name allowing change
> > in tile array (given that right now 4 value are already frozen). You
> > can look at my kernel patch to see what i mean.
> 
> The layer of indirection for the indices seems like overengineering at
> this point. Even if the fixed indices stop being good enough for some
> reason in the future, how can we be sure now the layer of indirection
> will be good enough? So I think we shouldn't worry about that until that
> day may come.
>

Well i am fine with that but i just want to make sure everybody understand
the implications.

Cheers,
Jerome