Jellofish - out of curiosity, what is RTDT or CTDT?
Also, the reason why textures are swizzled is so that you have good spatial locality in your texture memory fetches. They are probably organized so they fit in memory words or texture cache lines. The orientation of the texture doesn’t really figure into it. Additional memory bandwidth is a good thing overall, but it is pretty orthogonal to the issue of swizzled v. linear.
Why would you want RTT v. pbuffer copy? I think it depends how long it takes to render, how long it takes to copy, how much video memory is available on and how many times you plan on using the texture. The different techniques are better/worse depending on the situation.
>>[b] Speed or no speed, try dynamically generating a 512x512 texture for a 640x480 display without pbuffers. Then you’ll know the answer.
B]No, I’m saying WITH pbuffers, why is there a need for render-to-texture if it’s actually slower?<<
LordKronos meant its impossible to do a 512x512 texture in a 640x480 window as any contents of a framebuffer than aint on the screen is undefined
Sorry, i just mean rendering to a depth texture or copying to a depth texture. True they can exist orthogonally, all im saying is the greatest whiz bang features are useless without more memory bandwith; enough that swizzling versus linear just isnt an issue.(I realize this may never be the case)
It seems to me like unless you are doing the simplest renders available it is always faster to render to a linear pbuffer and swizzle to your texture. RTT seems like a useless extension in this way.
Originally posted by JelloFish:
[b]Sorry, i just mean rendering to a depth texture or copying to a depth texture. True they can exist orthogonally, all im saying is the greatest whiz bang features are useless without more memory bandwith; enough that swizzling versus linear just isnt an issue.(I realize this may never be the case)
It seems to me like unless you are doing the simplest renders available it is always faster to render to a linear pbuffer and swizzle to your texture. RTT seems like a useless extension in this way.[/b]
Originally posted by zed:
[b]>>[b] Speed or no speed, try dynamically generating a 512x512 texture for a 640x480 display without pbuffers. Then you’ll know the answer.
B]No, I’m saying WITH pbuffers, why is there a need for render-to-texture if it’s actually slower?<<
LordKronos meant its impossible to do a 512x512 texture in a 640x480 window as any contents of a framebuffer than aint on the screen is undefined[/b]
Yes, I’m aware of what he meant, but my question was not “what is the point in the pbuffer extension?” - hope I’ve clarified myself.
Originally posted by mcraighead:
[b]
If you want to render to a linear format, that’s what RTTR (render to texture rectangle) is for.
Matt[/b]
Is a rectangle texture always stored in linear format? Regardless of render to texture ops?
If I want a fast window-to-texture copy, would then a rectangle texture do a better job? (presumably because both it and the window are linearly ordered). Assuming that texture would later be rendered in the same orientation (not 90 degrees rotated), I assume I will not suffer much performance drop from the fact that it is linearly ordered.
Originally posted by mcraighead:
[b]RTTR is likely faster to render to but slower to texture from
Matt[/b]
I don’t actually need RTTR in this case. The question is about general rectangle textures. Are they always with linear order? I need to copy into the texture with glCopyTexImage2D from a framebuffer window, so I thought linear-to-linear copy will be faster. Is this correct?