[Mesa-dev] glTexImage3D GL_INVALID_VALUE on 512x128

[Brian Paul]

On 11/18/2010 08:12 AM, Török Edwin wrote:
> On Thu, 18 Nov 2010 07:36:36 -0700
> Brian Paul<brianp at vmware.com>  wrote:
>
>> On 11/18/2010 01:10 AM, Török Edwin wrote:
>>> On Wed, 17 Nov 2010 15:23:47 -0700
>>> Brian Paul<brian.e.paul at gmail.com>   wrote:
>>>
>>>> 2010/11/17 Török Edwin<edwintorok at gmail.com>:
>>>>> Hi,
>>>>>
>>>>> Thought I'd do a Bugle trace to see if it logs any errors that
>>>>> could cause f.d.o bug #31667.
>>>>>
>>>>> I've seen just these two:
>>>>> glTexImage3D(GL_TEXTURE_3D, 0, GL_RGBA, 512, 128, 16,
>>>>> 0, GL_RGBA, GL_UNSIGNED_BYTE, 0x1af93cf0 -
>>>>> ^[NOTICE] showerror.gl:  GL_INVALID_VALUE in glTexImage3D
>>>>>
>>>>> glTexImage3D(GL_TEXTURE_3D, 0, GL_RGBA, 512, 128, 16, 0, GL_RGBA,
>>>>> GL_UNSIGNED_BYTE, 0x1cd22480
>>>>> ^[NOTICE] showerror.gl:  GL_INVALID_VALUE in glTexImage3D
>>>>>
>>>>> Is 512x128 an invalid size for r600c/r600g?
>>>>>
>>>>> I tried using gldb-gui, but it crashes when trying to retrieve the
>>>>> states. Is it supposed to work with r600c or r600g?
>>>>
>>>> Run glxinfo -l and see what GL_MAX_3D_TEXTURE_SIZE says.
>>>
>>> Says 256. Is that a limitation of the hardware, the r600 driver, or
>>> mesa?
>>
>> I don't know what the limit is on r600 off-hand, but 256 is the
>> current maximum in Mesa.  But we could easily bump it up to 512 if
>> R600 or other hardware supports it.  See MAX_3D_TEXTURE_LEVELS in
>> src/mesa/main/config.h
>
> Thanks, I bumped it, and the error went away.
> It didn't fix bug #31667 though, so that glTexImage3D error is probably something unrelated.
>
>>
>> I've increased MAX_3D_TEXTURE_LEVELS every few years as PCs get more
>> and more memory.  Bear in mind that a 512x512x512xRGB texture would
>> use 512MB of memory.  Doubling the limit again would be 4GB.
>
> Well in this case it is 512x128x16, so 4MB only. Maybe the limit should
> be on total texture size, not on one dimension only.
> Will the GL spec allow you to do that? i.e. claim you support N
> for width but don't actually support N*N*N, just N*M*O, where M<=O<N;

Yes, that's what proxy textures are for.  It looks like none of the 
DRI drivers have implemented the TestProxyTexImage() hook though.


> Actually you can claim you've run out of memory when trying to allocate N*N*N if it exceeds a maximum,
> and that wouldn't be too far from the truth, right?
>
> stex3d -w 512 -h 512 -d 512 doesn't work (after bumping):
>
> [25142.078502] [TTM] Page number range to small Need 149846 pages, range is [0, 65536]
> [25142.078509] radeon 0000:01:00.0: object_init failed for (613769216, 0x00000001)
> [25142.078511] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (613769216, 1, 4096, -22)
>
> Failed to allocate :
>     size      : 613766400 bytes
>     alignment : 256 bytes
> Failed to allocate :
>     size      : 613766400 bytes
>     alignment : 256 bytes

The driver probably shouldn't emit all those errors.  The glTexImage 
call should generate GL_OUT_OF_MEMORY.


> stex3d -w 512 -h 128 -d 16 works though (after bumping).
>
> BTW stex3d doesn't check the return value of glTexImage3D, without bumping the limit I just get a non-textured torus.

I'm adding checks for GL_OUT_OF_MEMORY now.

-Brian