openmw.org

Now that the S3TC patent is expired[1], then it shouldn't be a problem now to include software decoding support for systems where S3TC isn't supported in hardware. It is now being reported on all over[2].

My thought was that during startup, we would check for the S3TC extension and warn the user if not available and that we would fallback to decoding it before handing it off to OSG->GPU. We would either do it every time the textured is asked for and not loaded in the GPU, hold this texture in RAM or we would write it out to disk like we do compiled shaders, I'm not sure which one is the best approach.


[1] http://www.patentcountdown.org
[2] https://www.phoronix.com/scan.php?page= ... -Next-Week

It's already October?! Wow, time flies... But this is great news. I was actually a little worried that someone would extend the patent.

Yay! Looks like we're late to the party - Mesa already had a patch up their sleeves they just held it back until the expiry date.

Apart from non-supporting drivers, we have another use case for S3TC software decoding. Morrowind's cursor textures need to be uncompressed to be usable as a hardware cursor for SDL. Currently we do this by rendering the texture on the GPU then downloading it back to main memory. This is slow, not very elegant, relies on deprecated 'PBuffer' extension and appears to also trigger bugs in OS X graphics drivers (=cursors being flipped)

My thought was that during startup, we would check for the S3TC extension and warn the user if not available and that we would fallback to decoding it before handing it off to OSG->GPU. We would either do it every time the textured is asked for and not loaded in the GPU, hold this texture in RAM or we would write it out to disk like we do compiled shaders, I'm not sure which one is the best approach.

With support being added to Mesa now, this is probably not a very important issue but I'd tend towards conversion on the fly as the simplest approach.

Some reference material:
OgreDDSCodec
libsquish

We can push for an implementation in OSG's DDSReader, this is where the file is already parsed so adding the decompression routines there makes the most sense. There was a semi-recent topic on the OSG forum discussing this Edit: found it

I'm wondering how this will effect Raspberry Pi for example, I'll check with Eric Anholt to see. I was worried about none-open-source drivers that didn't support S3TC... but if this is a non-issue, I'm glad for it.

I kinda understood what S3TC is, but how can it affect OpenMW in layman's terms? Spend less GPU memory?

If the game is already working fine for you, nothing will change. This mainly affects systems that are unable to run OpenMW currently.

As in potatoes? Nice.

Not necessarily just potatoes. The compression format used by Morrowind's textures was covered by a patent, so anyone wanting to write a GPU driver that could handle them would have to pay a licencing fee. Obviously, the big GPU vendors had support in their proprietary drivers, but certain open-source ones did not. Now the patent has expired, anyone can add support for that kind of texture to anything.

Except for those edge cases where there is only a closed/binary driver or that that closed/binary driver is more performant than the FOSS alternative, in either case, they do not support S3TC. This is the case for some ARM things, but it's getting better.

It's worth noting that there are no such things are "software patent" in Europe, this is why the party for the expiration mostly happens on the other side of the ocean.