[Mesa-dev] glTexImage3D GL_INVALID_VALUE on 512x128
Brian Paul
brianp at vmware.com
Thu Nov 18 07:16:30 PST 2010
On 11/18/2010 07:56 AM, Marek Olšák wrote:
> 2010/11/18 Brian Paul <brianp at vmware.com <mailto:brianp at vmware.com>>
>
> 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
> <mailto:brian.e.paul at gmail.com>> wrote:
>
> 2010/11/17 Török Edwin<edwintorok at gmail.com
> <mailto: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 <http://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 <http://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
>
> 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.
>
>
> Hi Brian,
>
> This really should be raised to the same value as GL_MAX_TEXTURE_SIZE.
> How would you create a 8192x4x4 R8 texture then? The r600 hardware
> supports it and it takes very little memory. Even the old r300 can do
> e.g. 2048x4x4.
The one problem (which I've mentioned several times before) is the
software renderer's fixed point arithmetic may break down when the max
drawing size (for render to texture) goes beyond 4K (IIRC). We should
really have a piglit test to exercise the max surface/texture size and
make sure basic rendering works. Otherwise, I'm fine with increasing
these limits.
The other thing is the driver should be verified to see what happens
when too large of texture is allocated (i.e. not crash).
Finally, the driver could implement the TestProxyTexImage() driver
hook to allow things like 8192x4x4 but prevent 8192^3.
-Brian
More information about the mesa-dev
mailing list