   Large texture performance hints?
  After about a week of searching and fiddling with various methods, I'm stumped.  I'm just streaming data from a big RAID into a texture map.  I was happy with the 1920x1080 version of the program with glTexImage2D, but when I bump it up to 4096x2160, the performance just isn't there.  I'm getting about 420 MB/s, when the nvidia whitepapers for the QuadroFX 4400 says I should be able to get on the order of 2000 MB/s.It also says that I have to be careful about texture formats and possible texture swizzling, otherwise I'll end up with the performance I'm getting.  I have tried every combo of GL_BGR(A) and GL_RGB(A) and I either get the slow, swizzled texture performance or a blank quad.So I tried a framebuffer object, since they're the latest and greatest, but since I'm streaming data, I get slightly worse performance, since I suspect the driver has to copy the texture into the FBO before it gets sent to the card.  Or I could just be implementing it completely wrong, I won't discount that.I also tried the nvidia pixel data range extension, which was fun.  Okay,  fun as in I managed to hardlock the computer several times (I'm running Mepis linux).  Speed was very impressive once I got it to work, but it only works at the lower resolutions (blank quad at higher res again).  The speed looks like it'll be boarderline at full res anyway, judging by the scaling.I can add source code later, I'm new to OpenGL so I'm completely open to the possibility that I'm doing something really stupid.  Even as I type this I get the feeling I should be splitting it up into smaller textures, but the performance appears to scale with the resolution, I haven't found a magic texture size yet.  I've been using GL_TEXTURE_RECTANGLE_NV, tests with GL_TEXTURE_2D gives me the same performance, even at 4096x2048 resolution.I guess my questions are, can glTexImage2D give me better than 800 MB/s on a PCI Express QuadroFX?  Can PDR buffers work at obscene resolutions?  I know I haven't posted source or gory details, I can update tomorrow in case anyone wants more info.   
  The card may need to shuffle data around to make space for a texture that big. If you use 4 bytes per texel, a 4096x2048 takes up 32 megabytes of data, without MIP maps!It may be that it's the call to glTexImage() that slows you down. I would call glTexImage() only once, to create the texture and size it in memory, and then upload a new image by calling glFinish(), followed by glTexSubImage() to replace the existing texels of the image. If that's still too slow, I would try creating two texture objects, and calling glTexSubImage() on one of them (without the glFinish()) while drawing with the other (double-buffering).You might want to also benchmark the uploading of different size images, to see whether there's a threshold at which performance degrades.;  I've never seen a difference in performance between glTexImage2D and glTexSubImage2D, but I'm using glTexSubImage2D now anyway.  I don't have an alpha channel in my data, but I presume the driver is probably padding it much faster than I could.I do like the double-buffer idea, assuming the driver can multithread, especially since I'm on a dual-cpu machine.  Measuring performance might get interesting... :)My performance results in bytes per second, all with glTexSubImage2D:res = GL_TEXTURE_RECTANGLE_NV = GL_TEXTURE_2D512x512 = 256,114,000 = 393,216,0001024x512 = 262,039,142 = 224,694,8571024x1024 = 174,762,666 = 165,564,6314096x2160 = 373,832,112 = 344,737,315 (4096x2048)These seem extremely slow to me, especially since I'm taking the fastest times.  All I'm measuring is the time it takes to execute glTexSubImage2D, I don't even include the call to glFinish in these times (apparently glTexSubImage2D is blocking until it's finished).  If double-buffering could exactly double my performance, it would be sufficient except for the slower frames I keep getting.  My timing code might not be perfect, but the numbers it reports appears to be about what I'm seeing on the screen, so it can't be too far off.According to this, http://developer.nvidia.com/object/fast_texture_transfers.html, I should be getting a lot more.  Granted, I'm not using Pixel Buffer Objects, but I tried a Framebuffer object and wound up with pretty much the same performance.  I heard FBO's are supposed to be pretty much the same thing except faster and easier to use.  Of course, I'm only reasonably certain I got the FBO implemented correctly.I'm using glut for my initialization framework, but glut gamemode vs. a glut window offers no difference.EDIT: Oops, can't pad spacing, no fake tables for me   ;  Well, I hope I don't get murdered too badly for bumping my own thread.  I've cleaned up my FBO code so I'm more certain it's working correctly and it's still slow.  I've tried multiple textures with glTexSumImage2D (even tried the multitexture extension, which is kinda cool and surprisingly easy to use) and no matter what I do, I can't top  about 400 MB/s.  Even when I drop the resolution and switch to say, 512 x 512 textures in the GL_TEXTURE_2D format, I can't get more than 400 MB/s.My biggest problem appears to be that glTexSubImage2D blocks until it's finished uploading.  There's a rusty old extension out there that's supposed to turn it off, glEnable(GL_ASYNC_TEX_IMAGE_SGIX), but that had no apparent effect (but it did compile, amusingly enough).Thanks for the help so far hplus0603...   