Created attachment 30078 [details] correct map with mesa-7.6 When using GL rendering, the boswars game make r300 driver shows distorted rendering. This bug affect mesa-7.3, 7.5.1, 7.6 and current 7.7 snapshots. Tested on 3 r300 cards: - one xpress200 (aka RS380) (IGP) - one Radeon 9600 (RV350 AP) - one x1650 pro (aka Rv530) I see artefacts (See attached screenshots). How to reproduce: - run boswars (type "bos") - in the 'Video' configuration dialog of the 'Options' menu, tick "Use OpenGl" - restart the game. - in the main menu, choose "Start Game", then "bridge.map" then "Start" - move any unit along the coast to the north - after a few meters, the map is corrupted (only at some places). (Other map exhibit the same bug with r300 driver) I don't know if it's related, but it makes the r300 driver output the following: boswars: radeon_lock.c:65: radeonGetLock: Assertion `drawable != ((void *)0)' failed.
For the record, I see this on both ia32 and x86_64
Created attachment 30079 [details] bogus rendering of the map a few meters up to the north (still mesa-7.6)
Created attachment 30080 [details] bogus rendering of them main menu with mesa 7.3...7.5.1 I think boswars practices more code paths in the r300 driver. Whereas other games (such as openarena) always works fine with whatever mesa version is used, boswars often exhibits bugs in mesa. For example, up to 7.6, its main menu is bogusly rendered with GL rendering
Created attachment 30082 [details] correct rendering of them main menu with mesa 7.6
1) The failed assertion on exit is now fixed in mesa_7_6_branch and mesa_7_7_branch branches (bug #22851) and the fix will be merged on master; 2) I am not able to reproduce the corruption; the bridge map is very slow, however this is another problem that could be fixed with r300-blit branch from http://cgit.freedesktop.org/~osiris/mesa/ ; Thierry Vignaud, could you retest with current mesa_7_6_branch or mesa_7_7_branch branches?
I'll try tonight. Btw the above repository is unusable (using git-1.6.5.3): $ git clone git://anongit.freedesktop.org/~osiris/mesa (...) remote: Total 262235 (delta 216714), reused 257786 (delta 212693) Receiving objects: 100% (262235/262235), 80.39 MiB | 323 KiB/s, done. Resolving deltas: 100% (216714/216714), done. warning: remote HEAD refers to nonexistent ref, unable to checkout.
OK I manually checked that branch. I'll try it too tonight
(In reply to comment #7) > OK I manually checked that branch. I'll try it too tonight > Note that that branch is experimental and it only works with KMS atm, see also bug #25142, comment #6.
After a little holydays and after having fighted the "mesa needs " flu syndrom, I've tested the master branch of drm+mesa as of today and here's the results: - the failed assertion on exit doesn't happen anymore (I haven't tested but I supposed it's the same in the 7_6 and 7_7 branches) Do you expect me to still test those branches? - the bogus rendering of the ground on the map is fixed with r300 (but it still happens with r300g (gallium) but it's quite a lot faster though [it's the reverse with openarena which is faster with r300 rather than with r300g]) I'll test your r300-blit branch soon for that.
> - the failed assertion on exit doesn't happen anymore > (I haven't tested but I supposed it's the same in the 7_6 > and 7_7 branches) > Do you expect me to still test those branches? I already verified it was fixed also on 7_6 and 7_7 branches. > - the bogus rendering of the ground on the map is fixed with r300 Nice, closing this bug then. > (but it still happens with r300g (gallium) but it's quite a lot > faster though [it's the reverse with openarena which is faster with r300 > rather than with r300g]) You may want to open new bugs for these issues. Thanks.
Btw, the r300-blit branch is as slow as master.
Hum, I was wrong, the bogus rendering still occurs, with both r300 & r300ng
Could you please test r300g now?
(In reply to comment #13) > Could you please test r300g now? On my RV530 both r300/r300g are working fine.
Ok, closing...
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.