radeonsi tiling dilema

[Michel Dänzer]

On Mit, 2013-04-03 at 13:04 -0400, Jerome Glisse wrote: 
> 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:
> 
> > >         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

I did look at your patches. That's the layer of indirection I'm
referring to. 


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

I think it should be fine. If necessary, we can add another query for
the index mapping. But as Alex explained, the indices should be fixed at
least within one HW generation. 

Thanks for working on this BTW!


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