Am 03.04.2013 15:57, schrieb 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.
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... Christian. > Cheers, > Jerome > > > > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130403/a3924aea/attachment-0001.html>
