Does not Support EXT_paletted_texture on GeForceFX?

In my experience S3TC pretty much always gives better quality than paletted textures. On standard color maps that is, though not on normal maps as you said where s3tc is useless. Most color maps compressed to s3tc will still subjectively look very good (though you can find the errors if you measure or look for them), while many if not most of the palette compressed textures have visible defects, IMO anyway.

I wasn’t talking about emulating the actual palette lookups as such. I was talking about the typical palette rolling effects, like the flashing object or whatever someone mentioned earlier in this thread. Effects where using a palette could be useful. These effects can all be achieved by other means, and are generally fairly simple to implement. I can’t even remember the last time I thought a palette would be helpful.

Also, given that paletted textures never were widely supported I don’t think the loss will hurt, people would have had to code a separate path anyway.

m2, every penny saved counts. When you’re dealing with high volume shipments those savings for nvidia can be substantial. Because of this they can lower the price on their chips and more video card makers enter the market causing competition and further lowering of the prices which translates to my savings. Some should realize that extensions are not permanent and will be dropped in the future as the api is evolving. You need to get your head around the fact that you need to code alternative paths. I have one arb tex.env. path and one reg.comb. path. It’s even worse under d3d as you don’t have a nice cheat sheet as in gl. Gl core functions are the only ones that you can depend on not changing in the future. That’s why it takes eons for the arb to promote an extension to the core. The extension must be widely used to be promoted to the core and since paletted textures weren’t nvidia dropped them and arb didn’t want them either. Quake2 should be able to drop to multipass if the sgi multitexture ext. is taken out. Since everyone nowdays have at least gf2, quake2 can ran fast in multipass on that hw I think. By the time they drop that extension everyone will at least have gf3/4 which can run q2 really fast. I think my thinking is reasonable.

It wont result in cheaper cards because the idea is to get rid of these little guys and concentrate on the big concepts.

It’s possible that it will come back in the future. I dont think this feature will be forgotten, but vertex_shader, vertex_weigthing, ATI_fragment_program, NV_register_combiners and many others have become obselete and can be easily removed from the extension list in a few years.

Why talk about Q2? Why is it important?

Well, it was brought in because it uses the GL_SGIS_multitexture extension which I proposed should be removed. The game should run fine without the extension anyway.

Well guys,the things are clear.We can talk and talk and talk but nothing will change the dumm(for me personaly) fact that FX doesn’t support EXT_paletted_texture with the default drivers.This is maybe one of the most irrational things that NVidia has ever done.Why we have to tripple the image size and request huge amounts of memory when we can simply update our indexed image with 768???I trully hope that NV will add support for this GREAT extension in the future drivers…

It’s not about one feature, it’s about the gazillions of other demands that require die space development, testing and add risk, and the related decisions to include one or exclude another. What’s in, what’s out, what’s the market share, is there a fallback, will the apps work, what’s the competition doing, is the benefit really worth the die space or is it just legacy cruft, is this new feature worth including or is it just some academic’s ego trip?

As for being treated badly by NVIDIA or ATI. They treat us all great and we don’t even know them. Daym, they spend hundreds of millions on R&D and all we have to do is walk into Fry’s and hand over a few hundred bucks and we get a product we would have had to spend $1million 5 years ago just to get a fraction of the performance & features. I guess there’s no pleasing some folks.

Get used to the new environment, enjoy it, get over your loss.

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

SGIS_multitexture is probably easy to support. It’s just multicasting of texture coordinates AFAIK. It was almost the ARB spec, so essentially ARB is a subset of SGIS (that could have been the ARB choice anyway). Just imagine for a second that they included multicasting in the ARB spec in the first place, (more reason for it now than ever if you ask me), and you really don’t have an extension there at all :wink:

You are mistaken my dear friend.We can’t just get used to whatever someone sais.The EXT_paletted_texture is one of the best solutions ever.Not only it saves memory but it’s also very fast.Can you imagine programming without multitexturing???No!Can you imaging programming without memory???No!And EXT_paletted_texture helps you save memory.Why we have to store one image when we can store 3???Or with other words:why we have to tripple the size of the memory taken???

>Get used to the new environment, enjoy it,
>get over your loss.

Sorry, but I don’t agree to this ‘customers should be grateful sheeps and worship the decisions of big companies’ point of view.

Of course my little voice will not change the decision to drop this extension on the GF FX in any way, but at least I will not be quiet if I think an useful feature bites the dust.

So prolly from now I have to answer questions from my users, asking if to get an ATI 97/9800 or GF FX for psx emulation: “get the ATI card, it’s cheaper and less noisy anyway, and nVidia dropped an important extension, so feature-wise for psx emulation they are the same”. If nVidia can ignore the demands of hundred thousants of die-hard psx emulation users, fine.

I guess a better question would be why you need the equivalent of ~384MB of RGB texture or why you even care when you consider the very effective color cell style compression supported. You can complain it takes more memory but in taking this away NVIDIA has doubled the size of available memory in the process, while improving paging performance), and infact have done so several times since this extension was introduced. You only have so many pixels on screen, at some point you need to get smart about texture useage.

If you’re going to say I’m mistaken let’s be specific. I didn’t pull your extension, the benefits of it are clear to me, the real question is was it worth the space, and that’s by no means as clear a decision for the rest of us as it is for you.

As you’re trying to beef up your memory interface for most normal applications and increasing the prefilter taps used at peak fill for the majority of applications perhaps one of the things you don’t want to do is complicate the fat end of your memory fetch with legacy functionality when you’ve been going to considerable expense to solve the problem in other ways.

Pete et.al. you completely misrepresent my posts, I agree with you in this regard, vote with your feet, by all means, I’m sure NVIDIA will miss your $5-$40 contribution to their top line. Where are you going to go for your palette support?

This could hurt them if it’s a bad choice, I doubt it is, especially if the benefit is reduced risk, reduced cost and increased performance, or do you think they throw features out for fun?

Swearing against NVIDIA…now what’s the difference between them and ATI? NVIDIA used to support a feature you liked but ATI never have? Classic customer loyalty in the PC business.

I’m not a sheep and I don’t worship big companies, but it’s amusing watching some of these posts. Yup I have a different view from you, but I’m intentionally neutral in the NVIDIA v ATI wars. May they continue to leapfrog each other and if they have to put a bullet in your pet feature to do so, so be it. Adios EXT_palette, R.I.P. now where’s my wallet, I have a graphics card to buy.

I love the smell of progress in the morning, smells like victory.

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

>I’m sure NVIDIA will miss your $5-$40
>contribution to their top line. Where are
>you going to go for your palette support?

Sadly enough, it seems that both of the two top-dogs consumer gfx cards manufacturers decided to drop it, so basically I cannot change from one to another to get it back, right.

Anyway, in the past I used Geforce cards as main development platform, therefore my emulation plugins were kinda optimized for them, but if I see no more (or at least less and less) reasons to get my next new card from nVidia, then this will easily change to ATI’s benefit.

>This could hurt them if it’s a bad choice, I
>doubt it is, especially if the benefit is
>reduced risk, reduced cost and increased
>performance, or do you think they throw
>features out for fun?

Sure, and if they want to reduce the risk and cost even more they can easily do simple VGA cards again, I am sure they have the old blueprints of the ancient Riva cards in some drawer.

>Swearing against NVIDIA…now what’s the
>difference between them and ATI?
>NVIDIA used to support a feature you liked
>but ATI never have?

That’s exactly my point. What is now (from my tunnel vision, of course) the difference between them? What is the feature which tips my decision to buy a nVidia card, instead an ATI one? Worser FSAA? More noise? More heat? Tell me.

>Classic customer loyalty in the PC business.

I am only loyal to my needs, not to any company. And if a company I’ve liked for years makes enough bad decisions (in my eyes), I will look after another company’s products. And of course I will tell every user of my Zinc/Impact/PSX plugins which road I will take.

Your prerogative, however you may even agree with NVIDIA & ATI if you could know the true cost of your needs, who knows. I can always dream. I don’t see this as a single feature issue, it goes way beyond that. It’s the cost of progress, at least from my POV.

>however you may even agree with NVIDIA & ATI
>if you could know the true cost of your
>needs

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).

So my personal response to that is:
If nVidia wants again my money and support, they have to work harder. I know they can do it.

If you don’t like what NVIDIA did to your pet extension, then by all means get yourself an ATI. None of us here will stop you or tell you you’re wrong. But it’s not going to change anything, because you still won’t have the damn extension!

I’ve said it before and I’ll say it again: your app should not be dependent on extensions with as little hardware support as EXT_paletted_texture. Your unwillingness to write a second code path for cards that don’t have the extension is, IMO, a sign of laziness and/or amateurism.

– Tom

Pete,
aren’t your plugins open source?
I have reasonably high performance and bullet proof palette emulation going (although in a slightly different context: Glide).
I might be willing to donate some of that work, if you tell me where to look.

Tom,

we can easily now exchange some insults and start cursing each others, but honestly I don’t feel like that right now, sorry.

I, as a professional and experienced coder (harhar), have of course a fallback or workaround for each and every extension I am using, including one for a missing EXT_paletted_texture.

But you, as a professional and experienced coder, also have to admit that every of those fallbacks tends to be either slower or produce a worse image quality.

So I only can state that by dropping the EXT_paletted_texture extension the most optimal path in some part of my work has been cut by nVidia. Which will result that FX cards will work worse (choppy gameplay) than GF1-GF4 cards in some situations (I estimate that 5% of all psx games will suffer by this… but hey, 5%, that’s only around 100 games, fine).

zeckensack,

my cdrom plugin, my DirectSound/OSS sound plugin, and my software gpu plugin are open source right now, but I haven’t found the time yet to release my hw/accel OpenGL/D3D plugins as OS.

Thank you for your offer, but I think I also have a very good solution for emulating palettized textures, my only concern are
a few situations were the game is throwing zillion of ever-changing palettes to each and every texture used, frame by frame by frame.

On a sitenote: why did you need palette emulation with Glide? The only reason I could think of is the missing palette alpha channel with old Voodoo1 cards, otherwise all Glide cards had perfect palettized
texture support, mmm?

I need it, because ATI cards do not support paletted textures. But these too need to be able to play Glide games

Pete, sorry for sounding harsh, but I get the impression that people are getting way too worked up over this. It’s very unrealistic to expect NVIDIA (or any other company) to spend time and money supporting something that has absolutely no commercial interest for them. PlayStation emulators do not sell video cards – Doom3 does.

That said, I’m glad to hear that you do have a fallback. 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)? Surely the latter approach can’t be that slow and inefficient compared to the optimal paletted texture path?

– Tom