Does the same happen if you load them in a different order ? What is the difference between these textures ?
the first and last texture are the only textures that work properly. If I change the order it is still the first and last texture.
To me it smells like an texture allocation/management bug.
Since we get a lockup it is reasonable to assume that the texture offset is screwed up.
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.
best
Vladimir Dergachev
Rune Petersen
------------------------------------------------------- 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
