pouët.net

Texture size questions ...

category: general [glöplog]
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..
added on the 2009-01-09 15:25:34 by Navis Navis
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.
added on the 2009-01-09 15:52:57 by hfr hfr
Quote:
non-power-of-2 textures are not just subregions of power of 2 textures

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.
added on the 2009-01-09 16:04:17 by hfr hfr
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
added on the 2009-01-09 16:22:46 by bonzaj bonzaj
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.

added on the 2009-01-09 16:33:57 by chaos chaos
Quote:
Quote:
the hardware can't fetch directly from a multisampled buffer.

you're wrong - You just need to use GL_EXT_framebuffer_blit and GL_EXT_framebuffer_multisample.

Yes, that's basically what I was saying.

Quote:
NV_explicit_multisample

That's indeed interessting. Thanks for the info!
added on the 2009-01-09 16:59:33 by hfr hfr
lazy-san:
this code:
Quote:

IDirect3DTexture9 *texture = NULL;
D3DXCreateTexture(device, 512 + 1, 512, 1, 0, D3DFMT_X8R8G8B8, D3DPOOL_MANAGED, &texture);
D3DLOCKED_RECT lockedRect;
texture->LockRect(0, &lockedRect, NULL, D3DLOCK_DISCARD);
printf("%d\n", lockedRect.Pitch);

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.
added on the 2009-01-09 17:06:01 by kusma kusma
You also wrote:

Quote:
If you're using FBOs (essentially render to texture), your fbo can't use multisampling


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)
added on the 2009-01-09 17:18:07 by superplek superplek
Niels: ...or just make it work on your own machine and the compo-machine ;)
added on the 2009-01-09 17:19:57 by kusma kusma
ooooh, burn :D
added on the 2009-01-09 17:22:18 by Gargaj Gargaj
i could tell you all again and again that that really only happened once, but i'm guessing kusma just envies the special treatment :)
added on the 2009-01-09 17:29:26 by superplek superplek
Quote:
gf8-series does not seem to pow2-align as you claim

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:
Code:device->CreateRenderTarget(512+1, 512, D3DFMT_A8R8G8B8, D3DMULTISAMPLE_NONE, 0, true, &surface, NULL);

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).
added on the 2009-01-09 18:05:08 by hfr hfr
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.
added on the 2009-01-09 18:45:34 by kb_ kb_
kb_: yeah, but default-pool textures aren't lockable...
added on the 2009-01-09 20:10:32 by kusma kusma
kusma, dynamic textures are. oherwise you wouldn't get stuff into them :)
added on the 2009-01-09 20:43:11 by kb_ kb_
by the way, can anyone explain the difference between the render buffer objects and FBOs ?
added on the 2009-01-09 20:44:37 by Navis Navis
kb_: good point, thanks :)
added on the 2009-01-09 21:09:38 by kusma kusma
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.
added on the 2009-01-09 21:24:20 by Jcl Jcl
kusma: result? :)
added on the 2009-01-09 21:53:43 by hfr hfr
lazy-san: 512 -> "2048", 513 -> "4096", so it seems you were right :)
added on the 2009-01-09 22:19:37 by kusma kusma
Quote:
non-power-of-2 textures are not just subregions of power of 2 textures, no

So what's the difference then?
added on the 2009-01-09 22:36:44 by hfr hfr
kusma got pwn3d :D
added on the 2009-01-09 22:47:23 by button button
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.
added on the 2009-01-09 23:30:52 by kusma kusma
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 ..)
added on the 2009-01-09 23:44:58 by xyz xyz

login