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.
videocard - ati radeon x1300pro;
xorg-server - 220.127.116.111;
xf86-video-ati - 6.12.2.
Do you still have this issue with recent mesa git checkout ?
Yes, I still have the same issue with recent git.
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.
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.
(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.
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)
(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.
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...
Mass version move, cvs -> git
Can you check if the bug is still reproduceable on current mesa_7_7_branch?
Please check if commit 960464e42dce138fde11c379ce7744bc4be14aa2 on mesa_7_7_branch fixes the problem.
There is no error anymore with mesa 7.7.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.