radeonsi tiling dilema

[Jerome Glisse]

On Tue, Apr 2, 2013 at 4:32 PM, Alex Deucher <alexdeucher at gmail.com> wrote:

> On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse <j.glisse at gmail.com> 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.
> >
> >
> > Thought, idea ?
>
> If it helps any, the tiling information for the GB_TILE_MODE register
> settings and index locations come from a table provided by the
> hardware team during bring up and barring any typos in transcribing
> the information, never really changes.
>
> Alex
>

Still sounds like you likely want to update those given gap there is inside
them.

Patch set for solution 1:
http://people.freedesktop.org/~glisse/si2d-sol1/

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