https://bugs.freedesktop.org/show_bug.cgi?id=26428 --- Comment #11 from Roland Scheidegger <sroland@xxxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
