radeonsi tiling dilema

[Christian König]

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

radeonsi tiling dilema

[Michel Dänzer]

On Mit, 2013-04-03 at 13:04 -0400, Jerome Glisse wrote: 
> On Wed, Apr 03, 2013 at 06:11:26PM +0200, Michel D?nzer wrote:
> > On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: 
> > > On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer 
> > > wrote:
> 
> > > The information we loose is what index
> > > > match to prefered surface format/type combination.
> > 
> > How so? We can add descriptive names for the existing indices.
> 
> Look at my kernel patch, for instance i define :
> RADEON_TILE_MODE_COLOR_2D_32BPP
> 
> You can then query the kernel with RADEON_TILE_MODE_COLOR_2D_32BPP which
> gave you corresponding tile index and also correspond gb tile config.
> 
> http://people.freedesktop.org/~glisse/si2d-sol1/0001-drm-radeon-add-tile-mode-ioctl.patch

I did look at your patches. That's the layer of indirection I'm
referring to. 


> > > 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.
> > 
> > The layer of indirection for the indices seems like overengineering at
> > this point. Even if the fixed indices stop being good enough for some
> > reason in the future, how can we be sure now the layer of indirection
> > will be good enough? So I think we shouldn't worry about that until that
> > day may come.
> 
> Well i am fine with that but i just want to make sure everybody understand
> the implications.

I think it should be fine. If necessary, we can add another query for
the index mapping. But as Alex explained, the indices should be fixed at
least within one HW generation. 

Thanks for working on this BTW!


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

Re: radeonsi tiling dilema

[Michel Dänzer]

On Mit, 2013-04-03 at 13:04 -0400, Jerome Glisse wrote: 
 On Wed, Apr 03, 2013 at 06:11:26PM +0200, Michel Dänzer wrote:
  On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: 
   On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer mic...@daenzer.net
   wrote:
 
   The information we loose is what index
match to prefered surface format/type combination.
  
  How so? We can add descriptive names for the existing indices.
 
 Look at my kernel patch, for instance i define :
 RADEON_TILE_MODE_COLOR_2D_32BPP
 
 You can then query the kernel with RADEON_TILE_MODE_COLOR_2D_32BPP which
 gave you corresponding tile index and also correspond gb tile config.
 
 http://people.freedesktop.org/~glisse/si2d-sol1/0001-drm-radeon-add-tile-mode-ioctl.patch

I did look at your patches. That's the layer of indirection I'm
referring to. 


   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.
  
  The layer of indirection for the indices seems like overengineering at
  this point. Even if the fixed indices stop being good enough for some
  reason in the future, how can we be sure now the layer of indirection
  will be good enough? So I think we shouldn't worry about that until that
  day may come.
 
 Well i am fine with that but i just want to make sure everybody understand
 the implications.

I think it should be fine. If necessary, we can add another query for
the index mapping. But as Alex explained, the indices should be fixed at
least within one HW generation. 

Thanks for working on this BTW!


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeonsi tiling dilema

[Christian König]

Am 03.04.2013 17:57, schrieb Alex Deucher:

On Wed, Apr 3, 2013 at 11:48 AM, Christian König
deathsim...@vodafone.de wrote:

Am 03.04.2013 15:57, schrieb Jerome Glisse:

On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer mic...@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



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

radeonsi tiling dilema

[Michel Dänzer]

On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: 
> On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer 
> wrote:
> On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
> >
> > 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 current index scheme already is de facto part of the API.


> The information we loose is what index
> > match to prefered surface format/type combination.

How so? We can add descriptive names for the existing indices.


> And the tile mode
> > might be considered API as if kernel ever change what
> userspace expect
> > then we might break some userspace.

Not sure how that could happen if the purpose of each index is clearly
defined.


> 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.

The layer of indirection for the indices seems like overengineering at
this point. Even if the fixed indices stop being good enough for some
reason in the future, how can we be sure now the layer of indirection
will be good enough? So I think we shouldn't worry about that until that
day may come.


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

radeonsi tiling dilema

[Christian König]

Am 03.04.2013 15:57, schrieb Jerome Glisse:
> On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer  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: 

radeonsi tiling dilema

[Jerome Glisse]

On Wed, Apr 03, 2013 at 06:11:26PM +0200, Michel D?nzer wrote:
> On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: 
> > On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer 
> > wrote:
> > On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
> > >
> > > 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 current index scheme already is de facto part of the API.

Only index 4,8,9,13 are part of current API no of the other are use.

> 
> > The information we loose is what index
> > > match to prefered surface format/type combination.
> 
> How so? We can add descriptive names for the existing indices.

Look at my kernel patch, for instance i define :
RADEON_TILE_MODE_COLOR_2D_32BPP

You can then query the kernel with RADEON_TILE_MODE_COLOR_2D_32BPP which
gave you corresponding tile index and also correspond gb tile config.

http://people.freedesktop.org/~glisse/si2d-sol1/0001-drm-radeon-add-tile-mode-ioctl.patch

> 
> > And the tile mode
> > > might be considered API as if kernel ever change what
> > userspace expect
> > > then we might break some userspace.
> 
> Not sure how that could happen if the purpose of each index is clearly
> defined.

Well that's the question, are we happy, confident that we will never shuffle
around the tile mode array. If so then we need to hard code tile index with
a meaning and call it API. It's already the case for index 4,8,9,13

> 
> 
> > 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.
> 
> The layer of indirection for the indices seems like overengineering at
> this point. Even if the fixed indices stop being good enough for some
> reason in the future, how can we be sure now the layer of indirection
> will be good enough? So I think we shouldn't worry about that until that
> day may come.
>

Well i am fine with that but i just want to make sure everybody understand
the implications.

Cheers,
Jerome

radeonsi tiling dilema

[Alex Deucher]

On Wed, Apr 3, 2013 at 11:48 AM, Christian K?nig
 wrote:
> Am 03.04.2013 15:57, schrieb Jerome Glisse:
>
> On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer  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.

Alex

>
> Christian.
>
> Cheers,
> Jerome
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

radeonsi tiling dilema

[Michel Dänzer]

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? 

-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

radeonsi tiling dilema

[Jerome Glisse]

On Wed, Apr 3, 2013 at 5:37 AM, Michel D?nzer  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.

Cheers,
Jerome
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: radeonsi tiling dilema

[Jerome Glisse]

On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer mic...@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.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeonsi tiling dilema

[Christian König]

Am 03.04.2013 15:57, schrieb Jerome Glisse:

On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer mic...@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@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

Re: radeonsi tiling dilema

[Alex Deucher]

On Wed, Apr 3, 2013 at 11:48 AM, Christian König
deathsim...@vodafone.de wrote:
 Am 03.04.2013 15:57, schrieb Jerome Glisse:

 On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer mic...@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.

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

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeonsi tiling dilema

[Michel Dänzer]

On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote: 
 On Wed, Apr 3, 2013 at 5:37 AM, Michel Dänzer mic...@daenzer.net
 wrote:
 On Die, 2013-04-02 at 14:13 -0400, Jerome Glisse wrote:
 
  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 current index scheme already is de facto part of the API.


 The information we loose is what index
  match to prefered surface format/type combination.

How so? We can add descriptive names for the existing indices.


 And the tile mode
  might be considered API as if kernel ever change what
 userspace expect
  then we might break some userspace.

Not sure how that could happen if the purpose of each index is clearly
defined.


 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.

The layer of indirection for the indices seems like overengineering at
this point. Even if the fixed indices stop being good enough for some
reason in the future, how can we be sure now the layer of indirection
will be good enough? So I think we shouldn't worry about that until that
day may come.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

radeonsi tiling dilema

[Jerome Glisse]

On Tue, Apr 2, 2013 at 4:32 PM, Alex Deucher  wrote:

> On Tue, Apr 2, 2013 at 2:13 PM, 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.
> >
> >
> > 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: 

radeonsi tiling dilema

[Alex Deucher]

On Tue, Apr 2, 2013 at 2:13 PM, 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.
>
>
> 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

radeonsi tiling dilema

[Jerome Glisse]

On Tue, Apr 2, 2013 at 2:13 PM, 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.
>

Well that one can also be slightly modified to not strictly enfore index
association with surface format/type preference.


>
> 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 ?
>
> Cheers,
> Jerome
>
-- next part --
An HTML attachment was scrubbed...
URL: 

radeonsi tiling dilema

[Jerome Glisse]

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 ?

Cheers,
Jerome
-- next part --
An HTML attachment was scrubbed...
URL: 

radeonsi tiling dilema

[Jerome Glisse]

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 ?

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeonsi tiling dilema

[Jerome Glisse]

On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse j.gli...@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.


Well that one can also be slightly modified to not strictly enfore index
association with surface format/type preference.



 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 ?

 Cheers,
 Jerome

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeonsi tiling dilema

[Alex Deucher]

On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse j.gli...@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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: radeonsi tiling dilema

[Jerome Glisse]

On Tue, Apr 2, 2013 at 4:32 PM, Alex Deucher alexdeuc...@gmail.com wrote:

 On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse j.gli...@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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel