Originally posted by jwatte:
Luckily, DXT1 compresses even better than 8 bit paletted data, so those high-res images should be no problem in that format
Unfortunatly, scientists are very uncomfortable with the idea to compress scientific data, especialy when the compression is not lossless.
No no, just one more reason not to buy Geforces for the lab.
Any infos about GL_LUMINANCE support on FX then?
for grayscale textures for instance…
scientists are very uncomfortable with the idea to compress scientific data
I understand. That’s why I said that, for gradient volume type data, you can probably filter BEFORE the palette look-up, and then do a single dependent read. The hardware does this for you, so it’s only two TEX instructions.
Read the 3D texture (which could be in a high quality format, such as 16-bit). This filters the sample, which ought to be the right thing for a typical sampled volume.
Use the output of the 3D sample to do look-up in a wide texture. This texture could be 2048 pixels wide, which gives you 8x the resolution in your color ramp than what you’d get out of paletted texture, and filtering to interpolate between points if you wish.
Thanks for the advice, I will try that and compare the results.
I am just not happy to rewrite all my apps that use that extension. That’ll teach me not to use vendor specific (or in this case quasi specific) extensions in the future.
I could replace the old Geforce2’s with Geforce4’s but I wanted to skip over the so called DX8 generation…
Aaargh! It’s been done (still waiting for my FX from Dawn to Dusk…)! AFAIK there have been plans to drop paletted texture support for some time but developer feedback prevented it.
I’m surprised to hear of “few application that use it”. I actually thought it to be very commonly used for the excellent compression-quality ratio it provides for many textures. I certainly know some people that will be very displeased with support for this being dropped.
Palletized textures certainly have their uses, like normal maps. Try compressing those with DXTC. There are also quite a few cases where a texture looks better with an 8bit palette than DXTC. I don’t think it’s wasting too much silicon real estate, what a bunch of BS. Every past video card since the Voodoo had support for it, so it can’t be that hard considering we have hardware a zillion times as powerful with 100x the transistors. Even the PS2 supports 4 and 8 bit textures.
First of all, the PS2 is an outdated POS; do not compare it to modern video cards.
Secondly, I agree with the wish to have palatted textures as an option, but I don’t agree that it is trivial to implement. Sure, ATi found a way to keep palatted textures around, but the internals of the GeForce FX and the 9500+ series are very different. It wouldn’t surprise me that palatted textures take non-trivial room in the texture unit hardware. These two cards perform texturing in very different ways; ATi’s texture hardware and pixel pipes are laid out in a relatively conventional fashion, while nVidia opted for the ability to switch from 8 pipes with 1 texture per pipe to 4 pipes with 2 textures. This probably complicates the texturing hardware.
Admittedly, maybe nVidia should have dropped the register combiners instead of palatting, since they could transparently implement RC’s with their fragment programs.
Originally posted by Korval:
Sure, ATi found a way to keep palatted textures around…
Really? Not according to Tom Nuydens’s page: http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_paletted_texture
Cass
Originally posted by cass:
[b] Really? Not according to Tom Nuydens’s page: http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_paletted_texture
Cass[/b]
And your point is what? Your cards have the “silicon” but you dropped the support for the extension out of the blue.
For me thats in no way better then not having it at all. I am strong armed to rewrite my code by Nvidia. I dont see any point of supporting NVIDIA anymore.
Thanks Cass if I needed anymore point to drop support for Nvidia (like they did on
me) you just provided it.
A once die-hard Nvidia believer…
Hell, what was that?
Just for the record, I’ve used Radeon cards from R100 to R300 and went through all drivers ever officially released since y2k. And I’ve never seen a Radeon driver exposing EXT_paletted_texture.
And regarding that “they force us into buying Quadros” stuff: find me a QuadroFX on this list if you can.
ATI never supported paletted_textures.
NVidia supported paletted_textures on FX 5800 and Quadro FX till the 42.x drivers. No support on 43.x drivers …
I could have sworn I saw the extension somewhere in my card’s extension list. Granted, I haven’t used it yet, but I thought it was there.
Originally posted by HS:
[b] And your point is what? Your cards have the “silicon” but you dropped the support for the extension out of the blue.
For me thats in no way better then not having it at all. I am strong armed to rewrite my code by Nvidia. I dont see any point of supporting NVIDIA anymore.
Thanks Cass if I needed anymore point to drop support for Nvidia (like they did on
me) you just provided it.
A once die-hard Nvidia believer…[/b]
Sorry you feel that way, HS.
I would have an use for pre-filtered paletted textures (especially if the palette size was larger than just 256):
With paletted textures is terribly easy to shade bumbmaps in a memory efficient, cheap, easy, extremely-portable-even-on-older-laptops way.
For more details, see
http://vcg.iei.pi.cnr.it/bumpmapping.html[\url]
It is an old technique, but not entirely outdated: for example, it makes the still-more-flexible CPU do all the lighting computations, rather than the GPU (no, this does not overburden the CPU as normal-to-rgb color computations are made only for few palette entries).
So, my vote, for what is worth, is:
if EXT_paletted_texture, as it seems, is not a big burden to implement, then…
…pleeease Cass don’t drop it (anymore)!
Moreover, bigger palette sizes are better! is 4096 asking for too much?
[This message has been edited by mtarini (edited 04-28-2003).]
Each texture sampler needs to be able to read four palette entries ‘for free’ each cycle (because they usually do bilinear 2D texture samples ‘for free’ these days).
Technically that’s 8*4 dependant reads per cycle just for what I’d call “legacy support”. I’m by no means a circuit engineer, but it seems reasonable that sooner or later this becomes a major obstacle, especially if you want clock speed headroom.
I also think that the palette LUT having to be shared across all texutre samplers may be a problem. You either need a small piece of SRAM with a whole freaking lot of fast read ports, or you need to replicate it all over the chip.
Isnt it funny that this old extention is not in the core?
Maybe it was introduced in the 1.0 or 1.1 days and I thought it was supported by everyone back then.
I dont know about everyone else, but I would like to know the reasons for why something isnt getting support. Is it temporary or what?
Originally posted by Korval:
First of all, the PS2 is an outdated POS; do not compare it to modern video cards.
Yeah, my point exactly. Why does the “outdated POS” PS2 have it, but modern cards don’t. You’re telling me that hw engineers can implement things like pixel shaders 2.0 with full 128bit colours, but not full speed palettized textures? BULLSH*T. As I said, even the ancient 3Dfx Voodoo had it.
And how the hell is the PS2 “outdated”? Last I checked, every publisher is still releasing games for it. There are a hell of a lot more PS2’s out there than all of ATI’s and NVidia’s “modern” cards added together and squared.
Point is, palettized textures do still have their uses.
You’re telling me that hw engineers can implement things like pixel shaders 2.0 with full 128bit colours, but not full speed palettized textures? BULLSH*T. As I said, even the ancient 3Dfx Voodoo had it.
It’s a cost/benifit tradeoff. The, presumably minor, benifit of using palatted textures is mitigated by having to implement them in increasingly complex hardware. Considering that nVidia’s primary market (ie, games) doesn’t care, it’s not terribly surprising that the FX lacks palatting. It’s not so much that palatting is hard, but it does cost space. And space dedicated to a relatively fixed-function process that could be emulated via fragment programs (and you do have 1024 opcodes and all the texturing you could want) may not, in nVidia’s calculous, warrent the cost.
And how the hell is the PS2 “outdated”? Last I checked, every publisher is still releasing games for it. There are a hell of a lot more PS2’s out there than all of ATI’s and NVidia’s “modern” cards added together and squared.
First of all, the fact that something is still being used doesn’t mean it isn’t outdated. Look how long it took for motherboards to lose those ISA slots (and for people to stop making ISA cards). Motherboards still have serial ports, even though USB is significantly better.
Secondly, palatting (as a form of texture compression) is something of a legacy left over from the days of 2D graphics. Yes, we can still make use of it today, and we can mourn it’s passing from dedicated hardware, but with the push to programmability, it was bound to happen.
My main problem with losing palatting is that there is no alternative other than S3TC or 32-bit textures. If S3 doesn’t do a good job, or if S3 just doesn’t compress the data very well, you have to move to 32-bit textures. And that is just not a reasonable idea. Palatting was always a nice fallback.
The pixel shader route isn’t that great. You have to take into account that if you want to do any kind of filtering, you have to code it up yourself. P8 support couldn’t possibly cost that much extra space in this day and age of 100m+ transistors.
I really think they made the wrong decision with dropping support for it. But hey, what can you do…
Originally posted by zeckensack:
[b]Hell, what was that?
Just for the record, I’ve used Radeon cards from R100 to R300 and went through all drivers ever officially released since y2k. And I’ve never seen a Radeon driver exposing EXT_paletted_texture.[/b]
I am aware that Nvidia cards where the only one worth mentioning that supported the extension, thats why I stuck to them (besides the excellent drivers).
For me they dropped the support “out of the blue” which puts me in a very delicate situation. Obviously the hardware has the “sillicon” to do what I need.
This is the 2nd time Nvidia dropped an extension (I did not cared to much about the GL_NV_evaluators) but the question would be what do they drop next?
I dont care about games but I care about software live cycles, I have too…
Did you ever tried to explain your customer that your software doesnt work anymore because his drivers are too new?
Originally posted by zeckensack:
And regarding that “they force us into buying Quadros” stuff: find me a QuadroFX on this list if you can.
Yes, you are right and I stand corrected. Does it change anything? No.
[This message has been edited by HS (edited 04-29-2003).]
