GenerateMipmapEXT() in FBO spec..

OpenGL OpenGL: Advanced Coding
1

hi, i’m new in here, so hope it’s the right place…

i wonder how the manual mipmap generation in GenerateMipmapEXT()of FBO spec will be implemented on actual hardware, will this be fragmentshader operation? thought about that as i’m experimenting with DOF atm and this could provide an interesting way in getting different levels of unsharpness of a frame rendered to offsceen FBO and then using it’s mipmap levels for DOF…

haven’t read the full spec now, so sorry if i simply overread the part :wink:

cu
olli

2

It will/must be implemented, according to the spec, exactly like regular mip map generation is.

3

Originally posted by Korval:
It will/must be implemented, according to the spec, exactly like regular mip map generation is.
that is not really what i wanted to know… i do not know the specification of mipmap generation (i think colorsum of 4 neighbouring pixels/4), but as it’s done usally on the cpu before texture uploading i just want to know if the implementation of GenerateMipmapEXT() touches the cpu or not? (just a question of performance)

regards
olli

4

there is alreay a mipmap generation extension (namely GL_SGIS_generate_mipmap… guess its even quite old)

if you enable it the automatic mipmap generation is invoked if you specify a new Teximage at mipmap level 0… so this extension really isnt something new. the only difference is, as i have understood, that you now can explicitly invoke mipmap generation yourself.
not quite sure from which generation on this works in hardware, but i know that it does on r3xx and nv3x type of boards

and yes it can be used to do depth of field and blur effects, even though it generates some quite ugly block artefacts if the blur should be too strong… it helps here to sample the texture at multiple mipmap levels and then doing manual filtering dependent on the blurriness you want to achieve :slight_smile:

5

to be more precise, i wonder if there could be another way of implementing this for a vendor, as sort of “hidden” blitting logic for such things that standart user does not see… (what i mean is: think of the glClear command, i would not believe that it clears the screen by drawing two triangles with screen resolution and a fragmentshader which returns the glClearColor value… would be some sort of overdose to use the pipeline for stupid things like that!?)

6

What kind of answer do you expect? Yes it will be hardware accelerated, yes it will use shaders, yes it will be ultimately fast?

All the spec ever does is define behaviour. As long as this behaviour doesn’t change, implementors can do whatever they want.
Of course there are multiple possible ways to implement glGenerateMipmapsEXT, but you can’t choose. Implementors can. And their choices may well differ.

7

If you want mipmaps generated in a specific way, EXT_fbo provides the framework to do it in hardware. Cool, huh? :slight_smile:

8

Implementors can exploit their render-to-texture capabilities to downsample textures. This requires being able to sample from miplevel n and write to miplevel n+1 simultaneously. While that’s a novelty for users of OpenGL, I’m sure that driver writers have been able to do it, under controlled circumstances, for a long time already.

For a simple equal-weight 2x2 box filter, the linear texture filter is all you need. You want to sample exactly between the four source texels, so that they contribute the same amount to the single downsampled target texel.

For a nxm source level, the correct sample points are of the form

(1/n;1/m) (3/n;1/m) (5/n;1/m) ...
(1/n;3/m) (3/n;3/m) (5/n;3/m) ...
(1/n;5/m) (3/n;5/m) (5/n;5/m) ...
...       ...       ...       ...

(NOTE that if n=1 or m=1, the coords theoretically need to be adjusted. But because of how we’re going to implement it, it’ll all work out nicely regardless)

And you can easily generate these sample coords with the texcoord interpolator and careful sizing of the target drawing region.

E.g.

glBindTexture(GL_TEXTURE_2D,source_level_128x128);
glTexParameteri(GL_TEXTURE_2D,GL_MIN_FILTER,GL_LINEAR);
glEnable(GL_TEXTURE_2D);

//quick-hackish way to draw an exact pixel sized quad
//feel free to do it properly
glViewport(0,0,64,64);  //size of target level
glMatrixMode(GL_PROJECTION);
glLoadIdentitiy();
glMatrixMode(GL_MODELVIEW);
glLoadIdentitiy();

glBegin(GL_QUADS);
  glTexCoord2f(0.0f,0.0f); glVertex2f(-1.0f,-1.0f);
  glTexCoord2f(1.0f,0.0f); glVertex2f( 1.0f,-1.0f);
  glTexCoord2f(1.0f,1.0f); glVertex2f( 1.0f, 1.0f);
  glTexCoord2f(0.0f,0.0f); glVertex2f(-1.0f, 1.0f);
glEnd();

Then you “rebind” the generated level as the new source level (which you can’t currently, you need to use glCopyTex(Sub)Image), and repeat the process until you’ve generated the 1x1 level.