ASTC (specification) weak spot or wiki lagging?

On the OpenGL Wiki we can find the following remark:

Note: The ASTC extension is… unclear as to exactly how ASTC compressed images work in desktop OpenGL. Because it was written against OpenGL ES 3.0, it does not mention many elements of desktop GL, such as 1D textures and the like. Clarifications on these elements are in the process of being compiled, but are not available at this time.

https://www.khronos.org/opengl/wiki/ASTC_Texture_Compression#Dimensions

Is this information out of date or does this mean ASTC currently has some weak spots?

There being lack of generalised N-dimensional encoding/decoding and data layout strategy.
Resulting in a lack of 1D textures, generalised N-dimensional array, array image views and other features.
And that for a next gen texture compression format touted as being Adaptable Scalable Texture Compression (ASTC). The words adaptable and scalable are right in the name.

This is not the only issue the wiki remark seems to indicate, another problem seems to be unspecified desktop OpenGL. Having important functionality unspecified on many elements seems a big, important flaw that should be addressed. Especially since ASTC is to be used on OpenGL, OpenGL ES and Vulkan.

Last but not least for a scalable adaptable texture compression format I really hoped to see a mention about ROI decoding and encoding in the wiki page.
https://en.wikipedia.org/wiki/Region_of_interest
Such a feature would be very welcome in software using arrays of textures and texture views.
Other compression formats seem to support and prominently document that stuff, like PGF:
https://en.wikipedia.org/wiki/Progressive_Graphics_File#Comparison_with_other_file_formats

No mention of MIPmap levels in the ASTC wiki page.
And no finds when using LOD or Level of Detail (case insensitive) in the wiki page and ASTC specification.
https://www.khronos.org/registry/OpenGL/extensions/OES/OES_texture_compression_astc.txt
(Could at least put those words in the specification along MIPmap and other stuff in the relevant registry section and in the wiki.)

Without wide-ranging hardware support ASTC is never going to have any meaningful status. Meantime S3TC is coming out of patent later this year, and already has hardware support. I suspect that by trying to be too perfect, ASTC will have doomed itself to failure.

Block size for ASTC ranges from 4x4 to 12x12, so 1D textures are never going to be a possibility. Best case: emulate them using a 2D texture with the extra coord set to 0.

True, but only on mobile.

ASTC is really needed much more on mobile GPUs (OpenGL ES) than desktop GPUs (OpenGL). While decent cross-GPU-vendor texture compression has been ubiquitous on desktop for going on 15 years (patent or no), in mobile it’s still this largely vendor-specific mish-mash of formats that means you have to re-compress and deliver your textures differently for different mobile GPU vendors and even GPUs. And the memory consumption of these formats is different, so you may have to rework how you utilize GPU memory as well.

If you’re on PowerVR, use PVRTC1/2 and consider yourself lucky (solid compression down to even 2 bpp; DXT/LATC never had this). If you’re on Adreno, no PVRTC support of course (PVR = PowerVR). Well… does it support OpenGL ES 3.0? If no (and yes, new products are still shipping on these GPUs), then you’re lucky if you have ETC1, which is sort of a DXT1-like format but with no alpha support (RGB only). If it does support OpenGL ES 3.0-3.1, then you’ve got ETC2/EAC to choose from, which expands your palette to roughly a DXT1/5 + LATC1/2 level of support. It’s not until OpenGL ES 3.2 that you get the ASTC option. …repeat ad nauseaum for other mobile GPU vendors and their GPUs. OpenGL ES 3.2-capable mobile GPUs are still relatively new (a few years), and I doubt they’ve worked their way through all the reference platforms used in some industries for mobile. But it is coming. Mobile really needs this.

Desktop …not so much. We’ve already got great options. Main reason I can see for native ASTC in desktop GPUs is desktop development of mobile games. That said, mobile OpenGL ES development already has some great desktop OpenGL ES emulators that just run-time decompress mobile-only compressed texture formats when you provide them to the GL-ES API (e.g. via glCompressedTexSubImage2D). Yes, there’s a frame spike, and yes you’re using more desktop GPU memory than you will end up using on mobile. But desktops GPUs have Gigs of memory nowdays, and you know you can’t trust the performance you get on desktop GPUs with mobile GPU programs anyway because the GPU architectures are so radically different. So it’s ok.

Beyond that, about the only big plus I see for native ASTC compressed texture support on desktop GPUs is for the niche market that wants to develop mobile games that they think they can cross-ship on a desktop as well (possibly via browser with WebGL). If desktop GPUs provided a way for that market to do so without having to recompress all of their texture assets, that helps them out a little bit.

So while it’d be nice, ASTC certainly doesn’t need to be ubiquitous (or even supported) natively on desktop GPUs for ASTC to really be a smash hit on mobile.