Re: radeonsi tiling dilema

["Christian König" <deathsimple@vodafone.de>]

Am 03.04.2013 17:57, schrieb Alex Deucher:
> On Wed, Apr 3, 2013 at 11:48 AM, Christian König
> <deathsimple@vodafone.de> wrote:
>> Am 03.04.2013 15:57, schrieb Jerome Glisse:
>>
>> On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer <michel@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.
>>
>>
>> Just as a side node: If I understood it correctly the hardware isn't
>> completely capable to use those indexes interchangeable, e.g. only a certain
>> range can be used for the DB, and another rule matters for AA indexes etc....
>>
>> I don't know those rules exactly and I don't know how strict they are, but
>> as far as I understood it even the closed source driver didn't need to mess
>> with it. So I'm something like 90% sure that hardcoding them is ok, but well
>> on the other hand it just doesn't feels good to do so...
> The DB_[Z|STENCIL]_INFO.TILE_MODE_INDEX is only 3 bits so all of the
> depth formats have to be within the first 8 slots.  The CB and texture
> blocks support 5 bits for the index.  That's why the indices are laid
> out like they are with the depth formats first.

Well, that makes sense. I just read on some internal docs that the DB 
unit can only use certain indexes, but they not mentioned why.

Thanks for the explanation,
Christian.

> Alex
>
>> Christian.
>>
>> Cheers,
>> Jerome
>>
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>