In this specific case, the eg_surface_sanity function (or something
like that, I don't remember its name) returns an error. Then the
cascade of perfectly working fail codepaths propagate the error to the
OpenGL user as an unsupported framebuffer object setup.
Marek
On Tue, Oct 16, 2012 at 8:50 AM, Paul Menzel
<paulepanter@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Dear Marek,
>
>
> Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Olšák:
>> The calculation led to the number 8192, which is too high.
>
> what is the reason it is limited to 4096? Hardware limitation?
>
> What are the ramifications? GPU hangs, rendering errors?
>
>> ---
>> radeon/radeon_surface.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
>> index 66c2444..eb587d2 100644
>> --- a/radeon/radeon_surface.c
>> +++ b/radeon/radeon_surface.c
>> @@ -939,6 +939,8 @@ static int eg_surface_best(struct radeon_surface_manager *surf_man,
>> } else {
>> /* tile split must be >= 256 for colorbuffer surfaces */
>> surf->tile_split = MAX2(surf->nsamples * surf->bpe * 64, 256);
>> + if (surf->tile_split > 4096)
>> + surf->tile_split = 4096;
>> }
>> } else {
>> /* set tile split to row size */
>
>
> Thanks,
>
> Paul
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
