For those who havent read the thread fully, this was said by Cass
Palletted textures will not be supported on GeForceFX. While the functionality obviously has uses, it consumed a disproportionate amount of real estate relative to the number of applications that made use of it.
There you go. Now shut your freaking pie hole! (Just kidding)
There are a few other posts that you might wanna read (Korval’s explanation)
Someone mentioned that some previous drivers supported the ext on the FX. Maybe you should do a benchmark and we will see if it actually has some performance benifits (or not).
Originally posted by PeteBernert:
[b]I find it interesting that you always come back to one point, that it seems to be hyper-complicated and very expensive for nVidia to support that extension. I wonder from where exactly do you have this information? If it’s based simply on your common sense, then you are treating a mere assumption as a fact, just for arguing.
The only facts I do know:
nVidia was able to support it on GF1,GF2,GF3 and GF4 cards
nVidia isn’t supporting it on FX cards (for whatever reasons).[/b]
To quote Matt from nVidia above, “You might be surprised at how much it can cost to support some features”. Given the way paletted textures work it’s a fairly reasonable assumption to make that it can be quite expensive. Yes, it may have worked before, but as you smack on new features on a card or clock it higher it may become incredibly hard to keep it up to speed. For instance, remember the original Athlon, they began with a L2 cache running at half the clockspeed. Then as they ramped up clockspeed they had to scale back L2 cache speed. I suppose they could have kept it up to the same speed if they really wanted to, but it would be a lot more expensive in terms of transistors.
Consider the work done in a standard texture lookup for a while, then compare to a paletted texture lookup. The standard lookup takes the texcoord, grabs the four closest texels from the texture and four texels from the mipmap below then blends these together. For a paletted texture however, it must first lookup all those 8 samples as above, then it must look up the corresponding palette value for all those 8 samples and then blend. For this to run at the same speed as normal texture lookups you’d have to have a very low-latency, multiport and high bandwidth cache for the palette. Doesn’t sound cheap to me.
Why did it work fine it previous generations? According to some information (which aren’t official, but sound likely) NVidia used to extract texel values and store these in the cache in previous generation hardware. This is what caused DXT1 textures to only get 16 bit interpolation, as they were stored in 16bits in the cache, all kinds of textures were expanded and stored in simple texel formats in the cache. It’s a simple scheme that works fairly well, but the bad thing about this though is that you’re wasting a lot of cache space. The GFFX however to my knowledge takes the same approach as other vendors use to do, let the cache mirror the memory instead of expanding texels before storing them in cache. This way you can either make the cache smaller (and save loads of transistors) or make it more efficient (and improve performance). The bad thing is that it may make features like paletted texture prohibitly expensive to support, or if they were to be supported would have to have too low performance and thus not really be worth it.
Of course I understand the complexity to support different texture concepts in the same piece of hardware (good explanations, Humus), but also of course I tend to bitch around somewhat when I see hours of my work wasted. Same situation was when MS dropped the stretched surface blit support, and the color keying, in DX8. Perfect solutions for special things I had to do… and suddenly gone, sniff.
>Tom:
>Are you expanding to RGB and uploading a new
>texture every time the palette changes, or
>are you using a dependent texture read (in a
>fragment program)?
Tom, no, I don’t use shaders/combiners as fallback. Basically I use an (imho) clever texture caching sheme, which reduces the texture uploads to an absolute minimum, by storing as much needed palette variations of the used textures as possible in vram. To be honest, that works so well, that I even do that on cards which are supporting palettized textures. My plugins only use the extension (if available) in certain situations, whenever my main caching tends to fail (when it’s getting flooded with paletted textures by certain game engines). If the extension is not available, well, in such situations a brute force texture data uploading sheme kicks in, right.
Major drawbacks I see with a fragment program fallback:
a) I don’t like the thought to use another extension (which is even different from vendor to vendor) to fall back to. And I also have to consider that my DX and OpenGL/Mesa ports are staying as similar as possible.
b) it wouldn’t mix well with my current gpu plugin engine. I wouldn’t only need to emulate the texture palette lookup, but also all of my kinky texture enviroment setup, something which I have already well optimized (without shaders) for my tasks.
Anyway, in time of course I will need to use a different approach (yeah, most likely shaders), considering that in my next projects again texture color look up tables have to get emulated. But that’s a different story, so I don’t worry much about missing palettized textures for that, I have to admit.
Great,
at the moment i´m downloading
and testing the new NVidia driver 45.23
for my GeForce FX 5800 and i saw that
NVidia now supports the GL_EXT_paletted_texture and GL_EXT_shared_texture_palette
extension again which i´m using in my
OpenGL based isometric “2D” Engine to minimize the needed texture memory.
I dont now whether it is although supported by the GeForce FX 5200 and 5600.
And the extension GL_IBM_rasterpos_clip
is new.
Originally posted by DarkCutler:
[b]Great,
at the moment i´m downloading
and testing the new NVidia driver 45.23
for my GeForce FX 5800 and i saw that
NVidia now supports the GL_EXT_paletted_texture and GL_EXT_shared_texture_palette
extension again which i´m using in my
OpenGL based isometric “2D” Engine to minimize the needed texture memory.
An NVIDIA employee has publicly stated that it’s not in the hardware. Which means that it’s emulated in software. Guess what? You won’t be saving texture memory by using it.
thx NVidia