https://bugs.freedesktop.org/show_bug.cgi?id=30002
Summary: [regression r300g] Menu problem in Tiny and Big Product: Mesa Version: git Platform: Other URL: http://www.tinyandbig.com/download/ OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: sa@whiz.se
As mentioned in bug 28869 the menu in the game "Tiny and Big" isn't working correctly: all of the buttons only show up as white rectangles on mouseover, and the following is printed on the terminal:
r300: texture_create: Got invalid texture dimensions: 0x0x0
I tried some earlier git versions and noticed that this used to work, further digging turned up this change:
commit 5cdedaaf295acae13ac10feeb3143d83bc53d314 Author: Marek Olšák maraeo@gmail.com Date: Mon May 3 19:14:31 2010 +0200
r300g: refuse to create a texture with size 0
Unsurprisingly, commenting out this change gets the menu working again. I haven't had this problem with any of the other drivers (like llvmpipe).
https://bugs.freedesktop.org/show_bug.cgi?id=30002
--- Comment #1 from Ian Romanick idr@freedesktop.org 2010-09-03 15:30:15 PDT --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=30002
--- Comment #2 from Marek Olšák maraeo@gmail.com 2010-09-03 16:41:17 PDT --- Created an attachment (id=38413) View: https://bugs.freedesktop.org/attachment.cgi?id=38413 Review: https://bugs.freedesktop.org/review?bug=30002&attachment=38413
possible workaround
Sven, couĺd you try this patch?
https://bugs.freedesktop.org/show_bug.cgi?id=30002
Marek Olšák maraeo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #38413|0 |1 is obsolete| |
--- Comment #3 from Marek Olšák maraeo@gmail.com 2010-09-03 16:43:52 PDT --- Created an attachment (id=38414) View: https://bugs.freedesktop.org/attachment.cgi?id=38414 Review: https://bugs.freedesktop.org/review?bug=30002&attachment=38414
possible workaround
Crap, I made a mistake there. A new patch is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=30002
--- Comment #4 from Sven Arvidsson sa@whiz.se 2010-09-03 17:30:33 PDT --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=30002
--- Comment #5 from Marek Olšák maraeo@gmail.com 2010-09-03 17:35:10 PDT --- Are you saying that reverting 5cdedaaf295aca is better than the patch?
https://bugs.freedesktop.org/show_bug.cgi?id=30002
--- Comment #6 from Sven Arvidsson sa@whiz.se 2010-09-04 05:07:45 PDT --- Yes, with the commit reverted there are no problems.
https://bugs.freedesktop.org/show_bug.cgi?id=30002
--- Comment #7 from Corbin Simpson MostAwesomedude@gmail.com 2010-09-04 11:18:12 PDT --- (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?
https://bugs.freedesktop.org/show_bug.cgi?id=30002
--- Comment #8 from Marek Olšák maraeo@gmail.com 2010-09-04 14:44:20 PDT --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=30002
--- Comment #9 from Ian Romanick idr@freedesktop.org 2010-09-06 21:56:40 PDT --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=30002
Matt Turner mattst88@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|Drivers/DRI/r300 |Drivers/Gallium/r300
https://bugs.freedesktop.org/show_bug.cgi?id=30002
Marek Olšák maraeo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #10 from Marek Olšák maraeo@gmail.com 2011-02-21 23:15:20 PST --- 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).
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org