Mesa Preparing Software Fallback For S3TC Texture Compression

[phoronix]

Phoronix: Mesa Preparing Software Fallback For S3TC Texture Compression

Mesa recently landed BPTC software fallback handling that is a requirement for OpenGL 4.2 support but BPTC is not natively supported by all GPU hardware, particularly on the embedded side. That software emulation support for BPTC is similar to what already has existed within Mesa for the ASTC and ETC formats too. A merge request is pending that also adds S3TC software fallback handling, which helps out some of the smaller, embedded GPU drivers too for getting more games running that are dependent on S3 Texture Compression...

https://www.phoronix.com/news/Mesa-22-S3TC-Software-Fallback

[Inopia]

Wasn't this distributed as a separate package for the longest time due to the patents?

[CommunityMember]

Wasn't this distributed as a separate package for the longest time due to the patents?

The S3TC patents expired in late 2017, as reported on this site: https://www.phoronix.com/news/S3TC-P...ires-Next-Week

[jabl]

Wasn't this distributed as a separate package for the longest time due to the patents?

Yes, there was the libtxc_dxtn library, whose upstream repo has disappeared although you can find copies floating around on the net. However, there are several distinct usecases:

• HW supports S3TC, application uploads S3TC compressed textures. This is the common case, and support for this was AFAIU wired up in Mesa quite soon after the patents expired.
• HW does NOT support S3TC, application uploads S3TC textures. This is apparently not entirely uncommon on mobile, as mobile GPU's often don't support S3TC. Thus the driver needs to uncompress the textures before handing them over to the HW. This is what this patch does.
• HW supports S3TC, application provides uncompressed textures and asks the driver to compress them. Apparently games based on the Quake III engine do this, although otherwise it's not common. I think for this usecase the libtxc_dxtn library is still needed, as the two situations above only handle uncompressing, not compressing. But considering how popular Quake3 based games still are, it sounds a bit weird if the only way to make them work with Mesa is to use some old unmaintained library, so I guess I my understanding is slightly off here? Maybe Quake3 will fall back to just using uncompressed textures?

[zboszor]

Yes, there was the libtxc_dxtn library, whose upstream repo has disappeared although you can find copies floating around on the net. However, there are several distinct usecases: ...

None of the use cases need the external libtxc_dxtn library for Mesa since this commit that happened right after the S3TC patent expired:

commit 04396a134f003aece573df593acfa1ab4418ffe8
Author: Matt Turner <[email protected]>
Date:   Wed Sep 27 19:58:28 2017 -0700

    mesa: Import libtxc_dxtn sources
    
    Imported from master (commit ef07298391c6dcad843e0b13e985090c1dd76e76)
    of https://cgit.freedesktop.org/~mareko/libtxc_dxtn/
    
    Acked-by: Nicolai Hähnle <[email protected]>
    Acked-by: Emil Velikov <[email protected]>

[jabl]

None of the use cases need the external libtxc_dxtn library for Mesa since this commit that happened right after the S3TC patent expired:

commit 04396a134f003aece573df593acfa1ab4418ffe8
Author: Matt Turner <[email protected]>
Date: Wed Sep 27 19:58:28 2017 -0700

mesa: Import libtxc_dxtn sources

Imported from master (commit ef07298391c6dcad843e0b13e985090c1dd76e76)
of https://cgit.freedesktop.org/~mareko/libtxc_dxtn/

Acked-by: Nicolai Hähnle <[email protected]>
Acked-by: Emil Velikov <[email protected]>

Thanks for digging up that commit! But now I'm confused; if the full libtxn_dxtn was already in Mesa, why is this MR now being discussed needed?

[zboszor]

Thanks for digging up that commit! But now I'm confused; if the full libtxn_dxtn was already in Mesa, why is this MR now being discussed needed?

Probably some of the use cases didn't actually use the imported library code as a software fallback in case the HW didn't support S3TC.

[QwertyChouskie]

Thanks for digging up that commit! But now I'm confused; if the full libtxn_dxtn was already in Mesa, why is this MR now being discussed needed?

My understanding is that the MR is new functionality that wasn't supported before.

[SteamPunker]

Perhaps the people working on this could be persuaded to take another look at this idea, basically having Mesa transcode S3TC-compressed textures to ETC1 as they are uploaded to the video RAM, so as to take advantage of the hardware-accelerated support for ETC1-compressed textures in the VC4 GPU in older Raspberry Pis. It would save precious video RAM in such devices.

[smitty3268]

My understanding is that the MR is new functionality that wasn't supported before.

This merge request adds S3TC support for (mobile) hardware which doesn't natively support it. That wasn't much of an issue in the past, because S3TC is mostly used by desktop games, and those don't commonly run on mobile ARM devices. But with Zink now providing full OpenGL support on them it's more of a possibility.

Prior to this, the GL driver would have told the application it didn't support S3TC and if the app was coded properly it would have fallen back to some other format directly. However, in most cases the apps simply assume the format they want to use is going to work, in which case it would probably lead to broken textures being displayed. With this change, the driver will tell the app it does support S3TC, and the driver will decode the textures as needed on the CPU as a fallback.