Michel Dänzer wrote:
On Mon, 2002-11-04 at 13:06, Keith Whitwell wrote:

Michel Dänzer wrote:

On Son, 2002-11-03 at 17:06, Keith Whitwell wrote:

Michel Dänzer wrote:


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...


Yes, providing the kernel version is able to support the cmdbuf ioctl.

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?

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.

Ah, so the r100 driver is unchanged there? I'll look into moving the
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!
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.

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

Reply via email to