S3TC Support Will Land In Mesa Now That The Patent Has Expired

[oibaf]

True, but at the same time, the less work on packagers, the less potential for bugs

The packages are using the external library since about... 20 years, so it is more likely to found bugs in the merged code rather than the external library. Really no hurry for this in stable

[oibaf]

I would not exactly say same effect. Thinking that removing the external library feature end up deleting more code than what is used todo s3tc compression/decompression including a lot of platform dependant code.

Also if you read the bug report this is the first merge there are plans to look to crunch implementation and other things to optimise more that it can be legally worked on mainline. So might be close now in performance in a few releases who knows.

So, other than saving some lines of code, why would you risk to backport it to stable?
Also, all the other developments you propose seem relevant only for master branch.

[bug77]

The packages are using the external library since about... 20 years, so it is more likely to found bugs in the merged code rather than the external library. Really no hurry for this in stable

I'm just saying, you never know when you ship a library that's not compiled with the right gcc, having a wrong conf parameter set. Minor things that manage to slip undetected from time to time.

[oiaohm]

I used Crunch library for DXT (S3TC) compression for about a year and then switched to codecs from AMD Compress (old Compressonator) when it was open sourced.
AMD's codecs worked better for our tasks they gave compressed textures with good quality in much less time than Crunch.

There is no such format. May be you meant CRN format?
Anyway it has NO SUPPORT in hardware and have to be transcoded to DXT1/DXT5 formats to be usable by hardware.

Not correct. From documentation page on CRN and clustered DDS (https://github.com/BinomialLLC/crunch):

Crunch is discontinued now. Author now working on another commercial texture compression library/tool called Basis.

Crunch before BinomialLLC researched different things. The research versions of crunch did not worry about patent limitations. The one you looked at was the one in production. I typed crunch S3TC for a reason. Its not current day crunch its the whitepapers that lead to current day crunch. There is a lot of interesting stuff in the different S3TC whitepapers that have been blocked from production by the patent.

Also the no hardware acceleration this is explained quite simply. The fuzz testing on GLSL recently shows the problem. You send complex stuff to video card GLSL compliers and it stuffs it up. So BinomialLLC is crunch is a production usable compromise..

There is a long list of stuff that has not been usable due to the S3TC patent and issues in video card drivers.

[oiaohm]

So, other than saving some lines of code, why would you risk to backport it to stable?
Also, all the other developments you propose seem relevant only for master branch.

There are issues in the Library loading code those bugs would be removed from stable by backporting the patch. There are performance issue between call out to a library and remaining inside 1 library..

lot of platform dependant code.<< When you read this read here be gremlins. So every time one of those platforms tweaks something related to that code hello breakages. Basically its not the s3tc code that would justify the back-port is how much trouble the library loading and memory sharing code is particularly when you are trying to be time sensitive to have s3tc as a library.

[oiaohm]

I'm just saying, you never know when you ship a library that's not compiled with the right gcc, having a wrong conf parameter set. Minor things that manage to slip undetected from time to time.

Yes that is one of the gremlins. So mesa built with one gcc the libtxc_dxtn built with a different version of gcc and have the some of the structures aligned differently and watch the complete thing crash completely. The code to attempt to prevent those issues is large in mesa mainline than merging libtxc_dxtn in. So merging libtxc_dxtn into mesa equals less lines of code to maintain and debug and less of that code being platform or complier dependant. So there is a fairly good reason to backport the patch into stable. Of course even if there is a fairly good reason does not mean they will.

[bug77]

oiaohm Multi-quote hint: hit "quote" on posts you want to reply to, then click "post reply" at the top of the page. Doesn't work when you want to reply to messages on multiple pages though.