This is strange as the texture management code was pulled straight from r200 driver - I would have expected it to work.
Can you tell me how to get at these offsets? it will be easier to debug compared to lockups :)
I started looking for the code to point you to and could not resist to experiment a little.
Turns out offsets are not at fault, rather the issue is with HOSTDATA_BLT (again !).
If you comment out the code in r300_texmem.c in the end of the function
uploadSubImage (starting with LOCK_HARDWARE) then lesson20 works without a lockup.
What this code does is upload textures to the hardware - so you'll see some random patterns instead of what it is supposed to look like.
I think this is the same problem that causes Quake or tuxracer to lockup as well - both are certainly trying to upload a ton of textures at the start of the game.
The fix needs to be made someplace inside DRM driver.. It would be interesting to find out why some HOSTDATA_BLT calls succeed and some don't - maybe it is as simple as calling HOSTDATA_BLT in sequence (without any 3d commands in between) locks up.
Hi Rune,
I think I fixed it - looks like the texture upload function in drm/shared-core/radeon_state.c needed a fix similar to cp_idle() function.
Could you let me know how it work with your card ? You would need to update the DRM driver from CVS and recompile it.
thank you !
Vladimir Dergachev
PS Both q3demo and tuxracer still lock up, something to do with ClearBuffer code..
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
