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
On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse j.glisse@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
On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse j.glisse@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
On Tue, Apr 2, 2013 at 4:32 PM, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, Apr 2, 2013 at 2:13 PM, Jerome Glisse j.glisse@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
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?
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.
Cheers, Jerome
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...
Christian.
Cheers, Jerome
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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.
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
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
On Mit, 2013-04-03 at 09:57 -0400, Jerome Glisse wrote:
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: > > 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.
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 michel@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.
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-mod...
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
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 michel@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-mod...
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!
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Christian König -
Jerome Glisse -
Michel Dänzer