Michel Dänzer wrote:
Perhaps to do with the global lru? I'm not sure how many big 'chunks' there are in there (depends on your card size, resolution, blah blah), but 21 is conceivable, and it's quite possible that allocation cycles through each one in turn. Maybe there's some correlation there, like maybe upload always overdraws and 1/21 times you get the end chunk and the overdraw maybe scribbles the ring, or some other fairy tale with a similar ending.On Mon, 2002-11-04 at 13:06, Keith Whitwell wrote:Ah, so the r100 driver is unchanged there? I'll look into moving theMichel Dänzer wrote:On Son, 2002-11-03 at 17:06, Keith Whitwell wrote:In r200_texmem.c, Brian's cleaned up the *usage* of the old ioctl to be a bit cleaner & easier to understand (as well as being able to cope with compressed textures). I guess this is only partway to what you'd like, but it makes it easier to see how to take the next step.
Michel Dänzer wrote:Yes, providing the kernel version is able to support the cmdbuf ioctl.Just tried it for the first time because I hoped it would help with the texture problems seen in http://penguinppc.org/~daenzer/DRI/bzflag.png http://penguinppc.org/~daenzer/DRI/tuxracer.png Well, it does seem to change the behaviour, but not only for the good. While the problems occur randomly with the trunk code, mostly on the first runs after the server was started, with the texmem code they never seem to happen with tuxracer, but always with bzflag and quake2. Also, I don't think I've seen this on x86, anyone? Any idea what's up? BTW, would it be feasible to do all texture uploads via blits from AGP instead of the clumsy method we're using? Might improve upload performance and even make swapping out to AGP a nop in some cases...
Brian's actually done a bit of work on the Mesa-4.1 branch to clean up the code behind the actual upload (yes, sorry another branch...) that probably goes a long way to addressing your complaints.
Seems to be about the same as the trunk, what has changed?
changes over, but it would probably be easier for Brian or you...
Meanwhile, I've made some funny experiments. The bzflag problem happens
reproducibly on the first run after the X server was started, and then
seemingly randomly. Or maybe not so: I kept starting bzflag and exiting
immediately, and it seems to happen exactly every 21 times!
Keith
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
