[Bug 26428] [KMS] doom3-demo aborts early on rv280

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26428

--- Comment #11 from Roland Scheidegger <sroland at vmware.com> 2010-06-10 06:44:05 PDT ---
(In reply to comment #10)
> using mesa debug build and RADEON_DEBUG=tex i  have some additional info
> 
> -----
> radeon_validate_texture_miptree: Using miptree 0x114bff08
> Checking image level 0, face 0, mt 0x114bff08 ... OK
> Checking image level 1, face 0, mt 0x114bff08 ... OK
> Checking image level 2, face 0, mt 0x114bff08 ... OK
> Checking image level 3, face 0, mt 0x114bff08 ... OK
> Checking image level 4, face 0, mt 0x114bff08 ... OK
> Checking image level 5, face 0, mt 0x114bff08 ... OK
> Checking image level 6, face 0, mt 0x114bff08 ... OK
> Checking image level 7, face 0, mt 0x114bff08 ... OK

I don't think this corresponds to the texture which is rejected.

> [drm:r100_cs_track_cube] *ERROR* Cube texture offset greater than object size
> 22080 20480
> [drm:r100_cs_track_texture_print] *ERROR* width                      128
> [drm:r100_cs_track_texture_print] *ERROR* height                     128
> [drm:r100_cs_track_texture_print] *ERROR* bpp                        4
> [drm:r100_cs_track_texture_print] *ERROR* coordinate type            2
> [drm:r100_cs_track_texture_print] *ERROR* compress format            1

Just like bug #28459 this also has the seemingly impossible bpp == 4 and
compress != 0 case (bug #1). But I doubt it's the problem, as the cube texture
tracking code can't cope with compressed textures anyway (bug #2) - its size
calculation should be similar to what's done for non-cube compressed textures.
I've also got my serious doubts about the size calculation with cube mipmaps,
that offset stuff looks seriously wrong to me but I didn't look closer (that
would be bug #3).
Since I think there's something else entirely going on (more bugs), since if
you actually look at the numbers 128*128*4 (which is what the cube texture
tracking code seemingly would calculate as it ignores compress bits) would be
already 64k. That can only mean the cube faces (the sizes aren't printed) were
smaller than the corresponding texture faces, which, while the hardware allows
this, should never happen. There also appears to be a bug (let's call it bug
#4) with the command checker on the R200_PP_TXFORMAT_X packets since it ignores
the TEX_COORD_TYPES 3 and 4 - I don't think the driver would ever use 4 but 3
is projected 2d and certainly used. Hence I think something similar to bug #1
could be going on when actually 2d proj is active but due to a former packet
tex_coord_type is still set to cubic (this would explain the different sized
cube faces).
I think there are more bugs in the verifier, for one it doesn't really seem to
handle ATI_fragment_shader very well (PP_CNTL_X and PP_TXMULTI_CTL regs
mostly). These allow for instance enabled texture units with sampling disabled
which the verifier might refuse if it doesn't like the bound texture (I'm not
entirely sure though this can actually be a problem or is disallowed by the
API). Also it would completely miss to check for bogus textures in the first
phase, if sampling is only done there and not in the second phase, but at least
this shouldn't cause any unwarranted rejection :-). Unfortunately checking
correctly both phases seems quite complicated.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.