Bug 30002

The handling of textures with a 0 width, height, or depth is an odd corner case in the spec, so it's not too surprising that it's not handled correctly.

     "where ws, hs, and ds are the specified image width, depth, and depth,
     and wt, ht, and dt are the dimensions of the texture image internal to
     the border. If wt, ht, or dt are less than zero, then the error INVALID
     VALUE is generated.

     An image with zero width, height, or depth indicates the null texture.
     If the null texture is specified for the level-of-detail specified by
     texture parameter TEXTURE BASE LEVEL (see section 3.8.4), it is as if
     texturing were disabled."

The last bit is the tricky part.  You have to create the texture but disable texturing on any unit where it is bound.  We could use a piglit test for this corner case.

Created attachment 38413 [details] [review]
possible workaround

Sven, couĺd you try this patch?

Created attachment 38414 [details] [review]
possible workaround

Crap, I made a mistake there. A new patch is attached.

It's still a problem, but now the buttons are black instead of white, and I only get one warning about invalid dimensions, instead of a whole terminal full.

Are you saying that reverting 5cdedaaf295aca is better than the patch?

Yes, with the commit reverted there are no problems.

(In reply to comment #1)
> The handling of textures with a 0 width, height, or depth is an odd corner case
> in the spec, so it's not too surprising that it's not handled correctly.
> 
>      "where ws, hs, and ds are the specified image width, depth, and depth,
>      and wt, ht, and dt are the dimensions of the texture image internal to
>      the border. If wt, ht, or dt are less than zero, then the error INVALID
>      VALUE is generated.
> 
>      An image with zero width, height, or depth indicates the null texture.
>      If the null texture is specified for the level-of-detail specified by
>      texture parameter TEXTURE BASE LEVEL (see section 3.8.4), it is as if
>      texturing were disabled."
> 
> The last bit is the tricky part.  You have to create the texture but disable
> texturing on any unit where it is bound.  We could use a piglit test for this
> corner case.

Interesting. Should this be part of Gallium's API as well, or should we handle it one level up and make these textures illegal in Gallium? Does anybody know what Dx does?

(In reply to comment #7)
> (In reply to comment #1)
> > The handling of textures with a 0 width, height, or depth is an odd corner case
> > in the spec, so it's not too surprising that it's not handled correctly.
> > 
> >      "where ws, hs, and ds are the specified image width, depth, and depth,
> >      and wt, ht, and dt are the dimensions of the texture image internal to
> >      the border. If wt, ht, or dt are less than zero, then the error INVALID
> >      VALUE is generated.
> > 
> >      An image with zero width, height, or depth indicates the null texture.
> >      If the null texture is specified for the level-of-detail specified by
> >      texture parameter TEXTURE BASE LEVEL (see section 3.8.4), it is as if
> >      texturing were disabled."
> > 
> > The last bit is the tricky part.  You have to create the texture but disable
> > texturing on any unit where it is bound.  We could use a piglit test for this
> > corner case.
> 
> Interesting. Should this be part of Gallium's API as well, or should we handle
> it one level up and make these textures illegal in Gallium? Does anybody know
> what Dx does?

Look at R5xx docs and that's pretty much what D3D9 does. If we had to implement a D3D9 driver, we'd be finished loooong ago. There is a set of samplers and you bind textures to those samplers. This is the low level function to create a texture:

http://msdn.microsoft.com/en-us/library/bb174363%28v=VS.85%29.aspx

It doesn't seem 0x0 textures are allowed, or meaningful. However if I had a choice, I would use this high level function:

http://msdn.microsoft.com/en-us/library/bb172800%28v=VS.85%29.aspx

Which explicitly states that if you request a 0x0 texture, you get a texture of size 1x1.


Anyway, I was looking into this issue and I am almost sure this is a bug in st/mesa and that the game doesn't actually create a zero-sized texture. IIRC, the mipmap setup is broken. In Tiny and Big, I get this failure:

state_tracker/st_texture.c:68:st_texture_create: Assertion `width0 > 0' failed.

(In reply to comment #7)
> (In reply to comment #1)
> > The handling of textures with a 0 width, height, or depth is an odd corner case
> > in the spec, so it's not too surprising that it's not handled correctly.
> > 
> >      "where ws, hs, and ds are the specified image width, depth, and depth,
> >      and wt, ht, and dt are the dimensions of the texture image internal to
> >      the border. If wt, ht, or dt are less than zero, then the error INVALID
> >      VALUE is generated.
> > 
> >      An image with zero width, height, or depth indicates the null texture.
> >      If the null texture is specified for the level-of-detail specified by
> >      texture parameter TEXTURE BASE LEVEL (see section 3.8.4), it is as if
> >      texturing were disabled."
> > 
> > The last bit is the tricky part.  You have to create the texture but disable
> > texturing on any unit where it is bound.  We could use a piglit test for this
> > corner case.
> 
> Interesting. Should this be part of Gallium's API as well, or should we handle
> it one level up and make these textures illegal in Gallium? Does anybody know
> what Dx does?

This is a quirk of the OpenGL API.  I think it's pretty clear that this is something that should be completely handled by core Mesa.  The driver should never see the request for the 0x0 texture.  When the texture is bound to a texture unit, Mesa should disable that unit.

Fixed with a commit somewhere between e9ff76aa81d9bd973d46b7e46f1e4ece2112a5b7 and 9e872a5865c66ed0a518dd1c6c54e72f3afa71f1. Closing.

There's a new regression, which is going to be fixed soon (there's already a patch for it on ML).