driUpdateTextureLRU( (driTextureObject *) t ); /* XXX: should be locked */ I've taken this approach as well.. but should it be locked? if so how? is the i830 correct should I try to do something similiar?
Because this function call modifies the global (ie shared memory) LRU, it should be locked, eg. with LOCK_HARDWARE() macros. Why isn't it? I can't remember - there might not be any good reason.
I could try and do something similiar to the i830 where it does the updateLRU in its EmitHwState function.. but am wondering why no other driver has an issue.. or doesn't notice it perhaps..
You'd only see it when running multiple apps and in a state of texture swapping. Even then you'd probably only notice poor performance or maybe texture corruption.
2. context.c driCalculateMaxTextureLevels from the i830 has a big FIXME beside it about how the intel chips don't pack as well as everyone elses,
3. I 've noticed I've had to increase my Videoram from 16384 (to run my internal application, else I get some all white textures..), so I've probably messed up some allocation somehwere. .should texmem need more RAM?
I've recently had some reports about texture corruption in the i830 driver when using lots of textures. Something is lurking in there, I think.
If I use a lot of textures my program should still run but run slower? it shouldn't show white textures.. which is what it does if I lower the videoram to 16MB, I got this before the texmem change as well if I ran with a low VideoRam setting ..
Yes, it should just run slower. I'm suprised texmem makes a difference -- this is really worth investigating to find out what texmem is doing differently (assuming you have the time to do so).
So I think I'll check in the changes I have over the next couple of days as I don't think they really make things any worse..
Fair enough.
Keith
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
