Bug 22372 - radeon_mipmap_tree.c:114: compute_tex_image_offset: Assertion `lvl->size > 0' failed.
radeon_mipmap_tree.c:114: compute_tex_image_offset: Assertion `lvl->size > 0'...
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/R100
git
x86 (IA32) Linux (All)
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-19 11:45 UTC by Andrew Belitsky
Modified: 2010-01-04 05:01 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
implement copyteximage functions in radeon drivers (7.40 KB, patch)
2009-08-22 09:04 UTC, Roland Scheidegger
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Belitsky 2009-06-19 11:45:51 UTC
Trying lo play in game 'Darwinia' with latest mesa from git. After loading map it exits with message:

darwinia.bin.x86: radeon_mipmap_tree.c:114: compute_tex_image_offset: Assertion `lvl->size > 0' failed.

With mesa 7.4.2 it works but with low fps.
My computer:
 videocard - ati radeon x1300pro;
 xorg-server - 1.6.1.901;
 xf86-video-ati - 6.12.2.
Comment 1 Jerome Glisse 2009-07-07 07:29:11 UTC
Do you still have this issue with recent mesa git checkout ?
Comment 2 Andrew Belitsky 2009-07-07 11:21:29 UTC
Yes, I still have the same issue with recent git.
Comment 3 Tilman Sauerbeck 2009-07-20 10:34:42 UTC
I can reproduce this assertion failure with the tip of Mesa's master branch and demo1 in Doom3.

In this case, the texture is not compressed (texImage->IsCompressed is GL_FALSE), but texImage->TexFormat->TexelBytes is 0. Thus radeon_miptree_create() will create a mipmap tree that has mt->bpp set to zero. When lvl->size is computed in radeon_mipmap_tree.c:111, we end up with lvl->rowstride being zero due to multiplying by mt->bpp and thus lvl->size is zero as well.
Comment 4 Tilman Sauerbeck 2009-07-26 09:22:18 UTC
The assertion fails when the mipmap tree is recreated in radeon_validate_texture_miptree() (around line 965). At this point, the texture's TexFormat is _mesa_null_texformat.
Comment 5 Roland Scheidegger 2009-08-04 16:08:05 UTC
(In reply to comment #4)
> The assertion fails when the mipmap tree is recreated in
> radeon_validate_texture_miptree() (around line 965). At this point, the
> texture's TexFormat is _mesa_null_texformat.

Unsurprisingly, this also happens with r200. I wasn't able to get gdb to stop at this point for some reason though so I don't know if that's really all that's going on.
Comment 6 Andre Maasikas 2009-08-13 02:48:16 UTC
My understanding sofar (which might be completely wrong) is that _mesa_CopyTex* clears/initializes texImage fields and radeon does CopyTex* through swrast which tries to map the textures in radeonSpanRenderStart and it goes downhill from there.
No idea how to fix this though.  (maybe don't try to map the texobj in this state or provide own CopyTex implementation)

Comment 7 Roland Scheidegger 2009-08-13 04:39:23 UTC
(In reply to comment #6)
> My understanding sofar (which might be completely wrong) is that _mesa_CopyTex*
> clears/initializes texImage fields and radeon does CopyTex* through swrast
> which tries to map the textures in radeonSpanRenderStart and it goes downhill
> from there.
This is quite possible. CopyTexImage is definitely broken that way - you can test this with tests/subtexrate though it needs modification (replace CopyTexSubImage with corresponding CopyTexImage and skip previous TexSubImage tests which cause miptree to be defined).

> No idea how to fix this though.  (maybe don't try to map the texobj in this
> state or provide own CopyTex implementation)
I think the driver needs to follow what the intel driver does, that is provide own CopyTex implementation. It could be simple and always fall back to swrast (like intel does if it can't accelerate it) though we'd really want to accelerate it.
Comment 8 Roland Scheidegger 2009-08-22 09:04:33 UTC
Created attachment 28851 [details] [review]
implement copyteximage functions in radeon drivers

here's a quick patch which tries to get miptree defined for copyteximage (also has some functionally unnecessary stubs for copytexsubimage), copied over from the intel drivers.
Gets past that assert and in fact fixes the hacked up subtexrate test, but doesn't really do much for doom3. Just hits a different assert a couple functions later so I'm not sure what it's doing really makes sense...
Comment 9 ajax at nwnk dot net 2009-08-24 12:32:31 UTC
Mass version move, cvs -> git
Comment 10 Maciej Cencora 2009-11-18 14:17:38 UTC
Can you check if the bug is still reproduceable on current mesa_7_7_branch?
Comment 11 Maciej Cencora 2009-11-23 13:11:51 UTC
Please check if commit 960464e42dce138fde11c379ce7744bc4be14aa2 on mesa_7_7_branch fixes the problem.
Comment 12 Andrew Belitsky 2009-12-30 00:21:19 UTC
There is no error anymore with mesa 7.7.