radeonsi tiling dilema

[Michel Dänzer]

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.


>         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.


>         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.


>         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.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer