Does not Support EXT_paletted_texture on GeForceFX?

OpenGL OpenGL: Advanced Coding
41

HS,
you’ll have to find a new solution then, for cards that don’t expose EXT_paletted_textures.

There are pretty straightforward ways for the driver to give you that functionality if the silicon is really gone. NVIDIA obviously didn’t chose this route (yet?).

(assuming that you really need paletted and can’t make do with single channel textures and/or fragment program tricks)

Both driver ‘emulation’ and an app driven solution share a disadvantage: tripled texture memory footprint (and bandwidth reqs).

The app solution goes something like this:
1)Predecode textures at load time (to RGB888).
2)Reupload textures on palette changes.
3)Be lazy. Don’t redecode a texture on palette change if you’re going to bind a different texture anyway.

You’re losing 66% storage on FX cards. This is not perfect, but it can be made working without changing your data files.

You may then proceed to blame the performance drop (if any) on NVIDIA’s decision, but you’ll have to accept that the functionality is gone.

42

Zeckensack you dont get it (no offense).

I KNOW that I have to change my code (thats why I am so pissed off), and Jwatte already showed me the way I need to go. Its working ok so far but I dont need Nvidia based hardware for it though…

I can upgrade the lab to 9500’s without a problem, but what you dont get is that customers dont understand that they have to upgrade they hardware to something that supports fragment programms then the harware did just fine a month ago (Geforces2).

I dont need any advice how I can fix it with ‘current’ hardware (I did not even asked for it, but I am greatful for jwatte’s advice).

The life cycle of a game is a couple of month, I dont care, the live cylcle for scientific software is a couple of years. I cant stand a company that drops extensions like underware.

[This message has been edited by HS (edited 04-29-2003).]

43

He, sorry. Didn’t mean to sound patronizing or anything, just that old “anticipate possible questions and answer them beforehand” habit.

I may sound boneheaded again, so please correct me if I’m wrong, but …
For any Geforce below FX level, Delphi3D indicates that EXT_paletted_texture is still in the 43.45 drivers (the current ones I think).

It doesn’t look like they’re dropping it for the Gf1/2/3/4 tech level. Just the FXes won’t get it. Which would mean, you need not worry about having to change your software, as long as you keep the same hardware, right?

edit: here

[This message has been edited by zeckensack (edited 04-29-2003).]

44

Originally posted by zeckensack:
It doesn’t look like they’re dropping it for the Gf1/2/3/4 tech level. Just the FXes won’t get it. Which would mean, you need not worry about having to change your software, as long as you keep the same hardware, right?

So I can I sue you if they dont keep it?

No, as far as I am concerned they are unreliable and I dont thrust them anymore.

I will rewrite my code (I have to) but only based on extensions that are available on more then just one vendors hardware (I rather deal with a buggy implementation then with a non existence one).

45

Welcome to the real world.

Most of us can’t use any extensions without also providing fallbacks for systems that don’t have these extensions. Having control over the HW your app will be run on is a real luxury – stop whining and count yourself lucky that it’s just this one extension that you have to worry about.

– Tom

46

You should be GLAD hardware vendors are prepared to occasionally drop features from generation to generation. The alternative is a snowball effect where features accrete over time and even features that are rarely used end up slowing development & innovation, wasting die space and increasing the cost of your card.

The biggest loss for this particular feature IMHO is some scientific applications but it’s already been shown that the extra programmability can be used to replace the extensionit. I’d rather have the programmability than the extension and get my hands on the card sooner.

47

Originally posted by HS:
(I rather deal with a buggy implementation then with a non existence one).

I think you are going insane over nothing really special.

It’s definitly guaranteed that more extensions will drop. And dont be surprised if register combiner, and texture shaders dissappear in the next generation.

paletted texture are a little different. I think it would be better to have it in the GL core, but I guess some vendors stood in the way, and now it lost on NV platform because it takes up to much space (I find it hard to beleive).

48

it lost on NV platform because it takes up to much space (I find it hard to beleive).

I don’t find that too hard to believe.

In order for palatte “decompression” to be reasonably fast, you’ll likely need to have to have dedicated cache space on-chip (not merely video RAM, but uber-low latency, expensive, and bulky SRAM) with those palattes in it.

A single 256-entry 32-bit palatte requires 1K of memory. That’s not much for regular video, but for SRAM, that’s 48+K transistors (6-transistors per-bit, + extra for memory controller logic). And this is horrible for multi-textured palatting, as each access must fully upload a new palatte. As such, with hardware that can bind 16 textures, you must have 16K worth of palatte memory, minimum. Which corresponds to 768 transistors just for the palatte memory itself.

Note that this 16K of memory is very expensive. Also note that this 16K of memory can do nothing else. It isn’t like an on-chip texture cache; it provides only one function.

You wouldn’t want to put palattes in the texture cache either. Let’s say you had a 32K texture cache. You drop 1K for each palatted texture. Also, it complicates the cache lookup logic for the texture fetch unit, as it has to cache 32-bit entries and 8-bit ones (the palatte and the palatted texture, respectively).

Imagine being inside nVidia’s hardware development facilities. They have a choice between providing 32K of texture cache (that all textures can use), or 16K of texture cache and the requisite 16K of palatte entry space. Which is the most reasonable to choose, considering nVidia’s target market?

Granted, I don’t understand why new drivers should remove support for the extension on older cards that actually have the hardware.

49

“Too much space” is a subjective concept that’s heavily dependent on the value of a feature.

It’s not hard to believe when you consider that it’s a lookup pre filter and therefore potentially has to go somewhere in your texture fetch hardware, mostly legacy software uses it and that stuff runs like a bat out of hell on new hardware with alternate code paths for RGB texturing. On top of this you have texture compression, boat loads of bandwidth and more texture memory than you can shake a stick at.

You’re right, there’s no use getting your panties in a wad over this, bigger and better extensions may be deprecated in future. Let’s hope so. Lobbing grenades at NVIDIA for having the guts to do the right thing is futile.

50

If you would have read the posts you would know that the FX exposed the extension since the newest drivers.

That doesnt have anything to do with “whining” or “advancement” its just “marketing” you all just let happen no questions asked…

[This message has been edited by HS (edited 05-01-2003).]

51

Marketing? Didn’t it occur to you that there’s some engineering involved here? Your claim is built on many unsubstantiated suppositions. As for just letting it happen, cass has a lot of credibility IMHO.

There’s one terse post with no details that claims it was exposed on FX with all other evidence and posts suggesting it wasn’t. I don’t know for sure it was and I don’t know if it worked, how it was implemented or what other issues it impacted. What are NVIDIA forcing you to do here, buy a GeForce4? The conspiracy doesn’t hold water.

Anyway, I’m not an apologist for NVIDIA, in general OpenGL cannot be allowed to simply accrete features ad nauseum with no legacy stuff being deprecated. Now and then you have to take out the garbage or you end up… well, living in a garbage dump. In some respects this general point has nothing to do with any specific feature.

With available memory and performance I have less sympathy for someone using this for compression than I do for scientific apps like material classified volume rendering that might want the prefilter LUT and prodigious fill performance.

It’s ironic that you blame marketing, when I know that it’s the folks in marketing that often lobby to keep features like this in and engineers who want to toss them out. Marketing’s function is not as simple as you seem to assume.

[This message has been edited by dorbie (edited 05-02-2003).]

52

I guess this topic has been stressed enough.

I give up…

[This message has been edited by HS (edited 05-02-2003).]

53

EXT extensions don’t quarantee that the functionality is going to be in the hw. You need to code an alternative path in case the extension isn’t supported. I personally don’t like working with palleted textures so I don’t care much about them. They will save costs and time for ihvs so that translates to cheaper video card for me.

54

Originally posted by fresh:
P8 support couldn’t possibly cost that much extra space in this day and age of 100m+ transistors.

You might be surprised at how much it can cost to support some features.

  • Matt
55

I am not happy about a dropped palettized texture support as well.

Sure, you can find workarounds for it, but
even a clever texture generation/caching (considering the big vram available) or an high texture upload speed will not be a real replacement for palettized textures.

I am into PSX (yup, Playstation 1) emulation on the PC, and this very old console only had 2 MBytes of vram, but it was able to use 4 and 8 bit color look up tables (palettes).

I’ve coded an OpenGL based PSX graphic emulation plugin, and most times 32 (or more) MBytes of vram are enough to cache all psx texture areas. But (big but) most times doesn’t mean every time. Consider a game which is using 100 small (32x32) rgba textures. Now, to do a cool flashing effect, all that textures are changing their colors, let’s say 256 different pallettes are used on each texture.

No problem at all with palettized textures, you simply upload the new palette data, done.

Without the extension, you either upload the complete texture data again and again (slow), or you try to cache each and every (rgba converted) texture in vram. In my little example you would only need over 100 MByte of vram to do so. Double the number of palettes used, and not even 128 MB will be able to rescue you. Great.

So, in the past, GeForce cards were good suited for psx emulation (ATI cards, for example, had a very choppy gameplay with certain psx games, due to the missing palettized texture support).

But now, horray, the GF FX will suffer the same problem. Or to put it into extreme: a GF FX will be beaten by an old GeForce 1 card. Or, even more extreme: an old PSX1 gpu will beat the FX.

56

Personally I’m happy to see it go. It’s one of the least worthwhile extensions to support. There are more extensions I hope will be dropped soon too. GL_S3_s3tc, GL_SGIS_multitexture, GL_WIN_swap_hint, GL_EXT_vertex_shader etc.

57

JD: do you have any idea whatsoever what you are talking about? A cheaper card? The thing already has 100+ million transistors, and you are saying it’s going to be significantly cheaper because you are shaving off less than 1% of them? Sure, it reduces complexity and and might eventually lead to better process yields, but come on, please, do you really expect that the street price is going to be affected by that? You run-off-the-mill FX-class card is selling arround US$200. How much of that is NVIDIA’s cut in your opinion? How much of that is there because the price of the chip? Your card might become US$1 cheaper, with a bit of luck.

Humus: is that your take at sarcasm? It didn’t come out that well, you know?

Matt: do, by all means, enlighten us. I mean, I can’t imagine this sort of thing to be that much of an industrial secret, can it? I’m not asking for the secret sauce, I’m just wondering why something that’s used has been dumped without a good replacement. Just look at the proceedings from SIGGRAPH, VIS, GHWS and a couple of others from the last, what, four years at least? We have been pushing the products of your company even it treats us as crap most of the time. Please. (This is a personal opinion and it does not necessarily reflect those of my current employer).

[edit 1: tease Matt]

[This message has been edited by m2 (edited 05-04-2003).]

58

I meant exactly what I wrote. The sooner we get rid of left over legacy extensions, the better. Sometimes its harder to drop old stuff because of backwards compatibility though, but at some point you have to just get rid of stuff and go forward.

As for the paletted textures, yes, there used to be some cool effects that could be achieved by it, but today you can do all that and way more by using fragment programs. As a form of texture compression it was never that efficient, S3TC not only compresses better but also has better quality and performance. Probably cheaper to implement in hardware too.

As for the other extensions I mentioned, GL_WIN_swap_hint is more or less a null-op on todays hardware anyway, GL_EXT_vertex_shader is completely redundant since there is a GL_ARB_vertex_program and I don’t think there are enough applications supporting the EXT to be worth spending driver time maintaining support for it either. The only reason to support GL_SGIS_multitexture is probably Quake2 support. I give it a year or two, then it should go. GL_S3_s3tc, is this extension supported by anything? It’s so backwards done too, should go immediately IMO.

59

Hey, EVERYBODY!
Go to NVIDIA`s hot topic!

60

As for the paletted textures, yes, there used to be some cool effects that could be achieved by it, but today you can do all that and way more by using fragment programs. As a form of texture compression it was never that efficient, S3TC not only compresses better but also has better quality and performance. Probably cheaper to implement in hardware too.

First of all, S3TC is not a better form of compression. Not categorically, at least. It does compress some textures better, but it does have times when it doesn’t compress so well. Also, if you use more than 1-bit of alpha, you’re texture will be 8-bits per pixel; the same as palatted textures.

The others you mention are obviously depricated and not to be used or retained (except for SGIS_multitexture, as there are still some Quake 2 engine games in common use these days). The difference between palatted textures and the others is that there is still a use for palatted textures. As a compression technique, palatting can give higher image quality than S3TC. As mentioned before, S3 destroys normal maps, while palatted compression can achieve virtually lossless results.

Also, the argument that you can achieve palatted textures in fragment programs is no excuse for removing it from the texturing hardware. Doing it with fragment shaders makes it prohibitively expensive. You’re looking at 8 texture ops (for bilinear-filtering), plus the appropriate computations to achieve the appropriate results. Not only that, computing the appropate blending factors for bilinear filtering is hardly trivial.