From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Christian_K=F6nig?= Subject: Re: radeonsi tiling dilema Date: Thu, 04 Apr 2013 11:00:34 +0200 Message-ID: <515D4132.7080403@vodafone.de> References: <1364981826.19749.6.camel@thor.local> <515C4F3F.7040407@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from outgoing.email.vodafone.de (outgoing.email.vodafone.de [139.7.28.128]) by gabe.freedesktop.org (Postfix) with ESMTP id AF29CE5E0B for ; Thu, 4 Apr 2013 02:00:38 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Alex Deucher Cc: =?ISO-8859-1?Q?Michel_D=E4nzer?= , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org Am 03.04.2013 17:57, schrieb Alex Deucher: > On Wed, Apr 3, 2013 at 11:48 AM, Christian K=F6nig > wrote: >> Am 03.04.2013 15:57, schrieb Jerome Glisse: >> >> On Wed, Apr 3, 2013 at 5:37 AM, Michel D=E4nzer wro= te: >> >> 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 ar= ray >> (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 cer= tain >> range can be used for the DB, and another rule matters for AA indexes et= c.... >> >> I don't know those rules exactly and I don't know how strict they are, b= ut >> as far as I understood it even the closed source driver didn't need to m= ess >> 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 >>