On Thu, 28 Jul 2005 00:38:38 +0200 Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Aapo Tahkola wrote: > >>That's true, but to avoid the huge drops you could also just decrease > >>texture detail. Or implement the second texture heap in main memory and > >>use gart texturing (though you'd also need to manually increase the gart > >>size). There are some problems with that for r200, and the strategy for > >>what textures to put where may not be optimal currently, but the drops > >>should be gone. > >>That said, the performance in ut2k4 is probably really slow (apart from > >>that problem) due to deficiencies in drawArrays handling, at least that > >>was the case for r200 last time I checked... > > > > > > First "hack" attempts to improve it. > > > > Later two patches workaround RADEON_BUFFER_SIZE limit. > > While this actually appears to work theres no speed boost in general. > > That's what I found out some time ago as well, I did pretty similar > changes (basically bring back that start value). Once upon a time I also > had a hack so mesa could handle GL_UNSIGNED_SHORT elements lists > natively (no more converting them with _ac_import_elements to > UNSIGNED_INT and later back to shorts again in the driver) without any > success neither. > I never really found out why the old mesa code was 2 times faster :-(. First patch is working alright. without(ut2k3, citadel): 7.339034 / 20.030720 / 164.477829 fps -- Score = 19.973906 rand[1492594185] and with: 11.727319 / 31.931662 / 223.457932 fps -- Score = 31.496284 rand[31108770] What I dont know is why dma_ext doesnt speed up things where fallback_drawarrays would clearly get lots of hits. -- Aapo Tahkola ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel