pouët.net

For those who procedurally create their textures, do you work with floating point(32 bit/channel) and convert to 8888 at the very end of ops?

Yeah.

Yes.

no

no.
or maybe: not yet :)

i used to in our old texgen, but i switched to working entirely with ints on the most recent one for speed/smaller code/laziness reasons.

32bit floats would waste unacceptable amounts of bandwidth if much content are generated imo, 16bit fixed point (6:10?) would IMO be a nice tradeoff.

Well it really depends what you're doing with said textures...

we use 16bit/color channel (int) - well, actually 15, which avoids several annoying boundary cases.

i did that from the beginning on (i.e. fr-013), chaos took somewhat longer to convert :)

my perlin generator uses 16 b/channel iirc. looks okay.

Give me coder colours !!!

Zweckform: in your case, 1 bit per channel should be enough. ;)

we dont

We use 8 bit integer values per color channel.

64bit mmx registers

(for the whole color... not per component heh)

hmm i don't agree so much with converting to 4 channels in the end, it loses flexibility. you can also use floating point computation all the way, without having it hurt the performance. assuming you do your texgen in pixel shaders, yes. ;) it can also be faster than all the fixed point shit you can imagine, not even mentioning the bilinear filtering that comes for free. :)

by doing so, you also win through the asynchronism. while your gpu calculates your textures, your cpu can take care of mesh generation. and if your texgen is fast enough, you could even get animated textures. in fact, it's such a good idea i wonder why no one did it already. :)

we do floating point generation, and just convert to 8bit/chanel when finished (when ready for uploading to the gfx card). For our way of creating textures it's a lot faster than using integers, you get better quallity, and uses exactly the same amount of memory. So no doubt.

nystep: reasons why we haven't used it so far in a released production:

• precision. this is a non-issue on ps2.0-level cards, but 8 bit is just too little for most of our nicer textures.
  
• memory. you can't fit more than 64 512x512 64bpp textures into VRAM on a 128MB card - and in practice, it's obviously even less (backbuffers, zbuffer etc). we usually need more than that. you can get around some of that by just throwing away "cheap" intermediate results and recalculating as needed, but there's still...
  
• gpu->cpu bandwidth. at some point, you need to get those textures back into main memory again (if alone for the reason that you often have more textures in a demo/intro than fit in video memory at once). readback is quite slow on non-pcie systems. this is no showstopper, but it does eat some of the speed benefits.
  

2 and 3 are just annoyances (and i mentioned them mainly to show that it's not QUITE as easy :) - but the fact that you pretty much need ps2.0 is the reason why we haven't done it so far.

want some other downsides? :)

- there's some (very useful for texture generation) things which are really annoying to do in pixelshaders, are very slow, require a lot of setup, and need very long shaders or multiple passes.
- anything that is too complex for a pixelshader and requires reading back to the cpu totally messes up your speed. (gpu->cpu bandwidth as ryg said)
- pixelshader code (esp. 2.0 or 3.0) isnt half as small as you might think. cpu-based, integer-only code can be a lot smaller for the same job, you can do things like, you know, call functions and stuff, and you get the benefit of excellent exepackers designed to deal with it.
- hardware support. you're talking about floating point throughout, but fp blending and fp filtering are just not supported enough for that yet. and i'd hate to debug the differences between hw, it's bad enough on the renderer.

i'll think about it twice then, thanks for sharing the experience :)

i'd like to add the little thing called variance also. different gpus have different precision at different steps of the pipeline. this can easily give quite different results for some operations. one example is the glsl-implementation nvidia uses for atan2.

not to mention people which fiddle around with driver settings, esp. texel centers and antialiasing settings, both of which can cause major problems when you rely on hw filtering to give certain results.

and then there's the bane of every gpu texture generator, blur: (reasonably) fast, accurate, support for large filter kernels - pick two.

so true, that (especially the texel center thing) made me loose many days at work because of the way ATI and nVidia handled things (differently)