pouët.net

Texture gen question

category: general [glöplog]
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?
added on the 2006-08-14 04:17:43 by duffman duffman
Yeah.
added on the 2006-08-14 08:13:45 by kurli kurli
Yes.
added on the 2006-08-14 08:28:42 by Preacher Preacher
no
added on the 2006-08-14 09:43:01 by gencha gencha
no.
or maybe: not yet :)
added on the 2006-08-14 09:49:16 by styx^hcr styx^hcr
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.
added on the 2006-08-14 10:06:24 by smash smash
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.
added on the 2006-08-14 10:15:50 by kusma kusma
Well it really depends what you're doing with said textures...
added on the 2006-08-14 12:36:26 by noouch noouch
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 :)
added on the 2006-08-14 13:16:06 by ryg ryg
my perlin generator uses 16 b/channel iirc. looks okay.
added on the 2006-08-14 15:24:03 by earx earx
Give me coder colours !!!
added on the 2006-08-14 16:20:33 by Zweckform Zweckform
Zweckform: in your case, 1 bit per channel should be enough. ;)
added on the 2006-08-14 17:42:57 by KK KK
we dont
added on the 2006-08-16 01:33:07 by Gargaj Gargaj
We use 8 bit integer values per color channel.
added on the 2006-08-16 01:42:18 by hunta hunta
64bit mmx registers
added on the 2006-08-16 07:27:26 by blackpawn blackpawn
(for the whole color... not per component heh)
added on the 2006-08-16 07:28:35 by blackpawn blackpawn
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. :)
added on the 2006-08-16 11:14:20 by nystep nystep
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. :)
added on the 2006-08-16 11:20:36 by nystep nystep
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.
added on the 2006-08-16 11:54:44 by iq iq
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.
added on the 2006-08-16 15:27:37 by ryg ryg
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.

added on the 2006-08-16 15:47:08 by smash smash
i'll think about it twice then, thanks for sharing the experience :)
added on the 2006-08-16 15:54:19 by nystep nystep
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.
added on the 2006-08-16 16:03:06 by kusma kusma
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.
added on the 2006-08-16 16:48:04 by ryg ryg
Quote:
not to mention people which fiddle around with driver settings, esp. texel centers and antialiasing settings, both of which can cause major problems


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)
added on the 2006-08-16 22:17:11 by keops keops

login