pouët.net

I'm actually only interested in using them for screen space effects (for example bloom) through FBO in opengl. I heard this rumour that there is a problem there with multisampling... I wonder what..

If you're using FBOs (essentially render to texture), your fbo can't use multisampling since the hardware can't fetch directly from a multisampled buffer.

When reading the pitch of surfaces in direct3d on my geforce8800 it's a always some 2^n.
If the "wasted" space is assigned to other textures it doesn't even seem to be a stupid idea.
Other cards/vendors may indeed handle it differently, though.

lazy-san: you're wrong - you can use multisampling with FBO on ATI and NV.
You just need to use GL_EXT_framebuffer_blit and
GL_EXT_framebuffer_multisample.

Tested on everything better than GF6 and ATI HD2. Works perfectly. I guess it might work also with older hardware.

ALSO in NV_explicit_multisample

you get:

* The ability to fetch a specific sample from a multisampled texture from
within a shader

the driver might choose a different hardware path for a render target than for a read-only-texture. render targets do not always have a power of two pitch.


i would not hesitate to use npot-rendertargets for screen space effects, but i would avoid npot-textures everywhere else: there is no telling what the driver does. npot-textures are not the end of the (performance) world, but as soon as i allow our artist to use them, they will use them everywhere, and that can't be good.


for multisampling i prefer rendering to the primary rendertarget with multisampling, grabbing it for screen space effects into a non-multisampled npot texture, and put it back when i am done. Ii want to get all the "driver magic" the primary rendertarget MIGHT have, like ZCull and whatever... this might be old-fashioned.


wherever i write the driver myself (>consoles), i can do it less cautious and more efficient, of course: i will only need one multisampled frame buffer (which is a lot of memory) and i save that last blit back.

Yes, that's basically what I was saying.


That's indeed interessting. Thanks for the info!

lazy-san:
this code:

prints "2052" on my 8600. with a width of 512, it prints "2048". In both cases the pitch equals the width multiplied with the size of a pixel. So no, gf8-series does not seem to pow2-align as you claim - at least not on this computer.

You also wrote:



Stop answering things wrong!

i guess it's just best (on pc/abstracted and certainly when using d3dxcreate*) not to assume anything at all :)

(which doesnt make wrong statements right, indeed)

Niels: ...or just make it work on your own machine and the compo-machine ;)

ooooh, burn :D

i could tell you all again and again that that really only happened once, but i'm guessing kusma just envies the special treatment :)

Ok sorry, I was probably a bit quick with my statement here.
Locking a managed texture won't tell you much about the internal layout, though.
If you do the same with a rendertarget:

Pitch is the next power of two (4096 instead of 2048; at least here), which made me believe textures are handled the same way (which is no proof or course).

kusma, the error in your example is that you used D3DPOOL_MANAGED, effectively giving the texture to the D3D runtime instead of the driver/GPU and writing to a CPU memory copy of the texture. It's only natural that pitch equals bpp*width/8 there ;)

Try D3DPOOL_DEFAULT instead, this should go directly into the GPU memory.

kb_: yeah, but default-pool textures aren't lockable...

kusma, dynamic textures are. oherwise you wouldn't get stuff into them :)

by the way, can anyone explain the difference between the render buffer objects and FBOs ?

kb_: good point, thanks :)

Just for the record, OpenGL in GeForce 4 cards handled NPOTD textures in hardware just fine (via GL_EXT_texture_rectangle, and later GL_ARB_texture_non_power_of_two). There was a performance penalty, but it was definitely not too much... my engine back in those days had a switch for using NPOTD textures in hardware or to software-convert texture coordinates for POTD textures (I'd always internally manage them as NPOTD), and it did make a difference, but not really a lot.

You had to send OpenGL pixel-based (i.e., not normalized) texture coordinates when using nvidia's EXT extension, and you'd get no mipmaps (also, you'd use a whole different texture target)... the ARB extension "fixed" that and extended it to standard 1D, 2D, 3D and cube map targets.

kusma: result? :)

lazy-san: 512 -> "2048", 513 -> "4096", so it seems you were right :)

So what's the difference then?

kusma got pwn3d :D

lazy-san: Making hardware that correctly does mipmap-calculations, wrapping and borders get quite a bit harder for non-power-of-two textures. I'm not sure if this is what smash meant, though. I work for a GPU-vendor, and we're not extending to pow2 sizes in our hardware. But our GPUs are for mobile devices, and wasting memory is a bit more problematic in our world ;)

megazoom!: Really? I just repeated what lazy-san reported (since I was - and still is - shocked by the reportings), and some details were missing. If that's being "pwn3d", sure.

kusma: me too and do what chaos said: better use NPOT just for blits. (ok, there -is- a hardware alternative, though.. (i.e. <big company secrets/>) and you're right - it complicates things a bit ..)