Re: [Dri-devel] i810 texmem patch..
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.. 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 .. 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.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
Re: [Dri-devel] i810 texmem patch..
Dave Airlie wrote: 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
Re: [Dri-devel] i810 texmem patch..
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). texmem doesn't make a huge difference I can do this with the old codebase as well, I was ignoring it out of ignorance, and just upping my Videoram value.. now I think about it it was broken :-) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
[Dri-devel] i810 texmem patch..
Okay I've gotten around to updating the i810 driver to texmem interface... http://www.skynet.ie/~airlied/patches/dri/i810_texmem.diff I've a couple of issues perhaps someone can help with: 1. In texstate.c UpdateTexUnit for most drivers (except i830) the following appears: 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? 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? apart from all that it seems to work :-) patch is also missing the sarea change .. it generates a warning... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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
Re: [Dri-devel] i810 texmem patch..
Dave Airlie wrote: Okay I've gotten around to updating the i810 driver to texmem interface... http://www.skynet.ie/~airlied/patches/dri/i810_texmem.diff I've a couple of issues perhaps someone can help with: 1. In texstate.c UpdateTexUnit for most drivers (except i830) the following appears: 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. 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. apart from all that it seems to work :-) patch is also missing the sarea change .. it generates a warning... Dave. 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
