Am 03.04.2013 17:57, schrieb Alex Deucher:
On Wed, Apr 3, 2013 at 11:48 AM, Christian König
<deathsimple@xxxxxxxxxxx> wrote:
Am 03.04.2013 15:57, schrieb Jerome Glisse:
On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer <michel@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
