Hi, I have been testing the performance of rendering to textures and creating different sized FBOs and Textures on the fly. Using intervals of 10 frames, starting with 2x2 size and *2 until a threshold, then starting back at 2x2 again. so: if(framecount==10) if(size!=4096)size*2; else size=2; createFBOs() framecount=0 else framecount++ The threshold of 2048x2048 runs nice and smoothly with no noticeable frame dropping all the way. However as soon as i go to the next level (4096x4096) there is noticeable lag, then it goes back to 2x2 and runs smoothly til 4096x4096 where it jolts again whilst allocating the texture and FBO. I was just wondering if someone could give me an insight into where the bottleneck would be. Im not planning on alleviating it since for my uses that slight frame drop is no big issue, but i was just wondering what exactly i am saturating. Thanks and i hope that all makes sense ;) -J

Quote:Original post by V-man
If you are allocating while your game or whatever is running, then it's normal to get a lag as the driver does it job.

Yes i know that, but it only lags when allocating the 4096x4096 texture. CPU usage is not maxxing out (not even close), nor is RAM so im wondering is it a certain bus that is saturated when allocating large textures?

Quote:If you mean rendering to a 4096x4096 is slower, well I think it's obvious. It's called fill rate.

No, thats not the problem. Its the allocation of the texture and FBO, not the rendering.

Quote:Original post by V-man
No, it can't be a bus issue. The driver thinks about where to put the FBO in VRAM and it also stores the FBO properties in it's own structures in RAM.
In the worst case, it might move things around in VRAM.

So you suggest its a shuffling of video ram? Its a consistent hiccup regardless of how many textures i am already storing...even if i am storing none.

Quote:Original post by blaze02
I can't back this up, just repeating what I've heard...

Graphics cards [usually] use 24-bit pointers to access textures. This allows for up to 4096x4096. The 2 most significant bits of the pointer are "slower" to use. So if you stay within the 22 bits of the 24-bit pointer, this allows for textures up to 2048x2048.

This applies mostly to rendering. Not sure if it would slow down allocating the texture.

Hrm...id say the reason for the 2 most significant bits being used is something much lower level, but your comment would stand to reason (2048x2048)==2^22 and (4096x4096)==2^24.

Id be interested to know why using those 2 most significant bits causes such a slowdown but perhaps thats not a topic for this forum.

Thanks for your input ;)