radeonsi tiling dilema

[Jerome Glisse]

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:
> > So i am facing a dilema regarding tiling on radeonsi. Given that we
> > now have a fixed table of tiling mode this put more pressure on the
> > kernel userspace api. I see either 2 solutions.
> >
> >
> > Enforce kernel to set at fixed index in the table best tiling mode for
> > given gpu for given format, such as DEPTH32_2D_4AA at index 4, or
> > COLOR_SCANOUT_2D at index 13 ... that way kernel can still adapt the
> > tile mode array value. Note that this match the design behind the tile
> > mode index being that there is a limited number of useful tile mode
> > combination and for each surface format  (depth/color/macro
> > tile/micro/tile) there is a best one.
> >
> >
> > Second solution is to add an ioctl to compute mipmap information in
> > kernel (pitch alignment slice size ...) based on format, size of the
> > surface.
> >
> >
> > 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 information we loose is what index
> > match to prefered surface format/type combination. And the tile mode
> > might be considered API as if kernel ever change what userspace expect
> > then we might break some userspace.
>
> 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.

Cheers,
Jerome
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130403/b58c20cd/attachment-0001.html>