Intel Continues Work On ETC2 Texture Compression

[phoronix]

Phoronix: Intel Continues Work On ETC2 Texture Compression

Anuj Phogat of Intel has published his second round of twenty-two patches for implementing ETC2 texture compression support within the Intel Mesa driver...

http://www.phoronix.com/vr.php?view=MTIyNTU

[tomato]

it's hardly supported if the hardware does not support it natively, unlike with S3TC...

[przemoli]

it's hardly supported if the hardware does not support it natively, unlike with S3TC...

Does not matter:
1) Intel hw may not support ETC2 in hw.
2) Support in software or hardware in TRANSPARENT way was always STANDARD for all OGL texture formats.
3) If code using ETC2 works, than its as good as hw solution. Only perf will suffer (that is it will not suffer, since perf is bad already, we just change from one software texture format to other )

[przemoli]

Anyone knows who had first "true" * OpenGL ES 2.0 implementation on desktop?

Was it mesa?

* Not counting emulators of mobile gpus with GLES implementation.

[tomato]

Only perf will suffer

As if Intel GPUs had:
1. performance to spare
2. memory to spare
3. and were too power efficient

[elanthis]

Does not matter:
1) Intel hw may not support ETC2 in hw.
2) Support in software or hardware in TRANSPARENT way was always STANDARD for all OGL texture formats.
3) If code using ETC2 works, than its as good as hw solution. Only perf will suffer (that is it will not suffer, since perf is bad already, we just change from one software texture format to other )

Yup, does not matter, aside from filling in bullet points on a feature checklist for conformance reasons.

One third of the point is the performance, which as you said this doesn't help with.

Another one third is the reduction of the GPU memory usage for textures, which is at a premium, _especially_ on Intel hardware. Uncompressed textures mean you can't fit as many textures (or as high quality of textures) into memory.

The only third of the problem space of compressed textures that this solves is distribution sizes of game binaries. Granted, PNGs are also pretty small and don't have the quality loss associated with compression schemes like ETC2/S3TC, so there's not a huge advantage to using ETC2 if all you're getting is file size benefits.

Intel's reason for having ETC2 support in Mesa is that now you can test and develop ETC2-using software in preparation for the day that native ETC2 support is available, if said day ever comes. I recall one of the other manufacturers (NVIDIA, maybe?) saying that they had no plans to implement ETC2 in upcoming hardware, so we'll see where things go. It might simply be a case of getting support now so that in 5+ years when enough hardware in consumers' hands supports it that developers can actually start making use of it. (See for example how nobody uses GL4 or even GL3 for the most part and sticks to GL2.1 plus a small handful of extensions, due to the lacking support and compatibility for the newer GL standards on commonly installed drivers for hardware in consumers' hands, and how D3D11 is only just starting to take off in a big way despite being available for over 3 years and having feature-level support for DX9+ hardware).

[zxy_thf]

Anyone knows who had first "true" * OpenGL ES 2.0 implementation on desktop?

Was it mesa?

* Not counting emulators of mobile gpus with GLES implementation.

See this: http://www.khronos.org/conformance/a...ducts#opengles
"NVIDIA 2010-12-31 OpenGL_ES_2_0, OS: Windows"

However, I believe most of these implementers were passing the conformance tests just for the sake of it. OpenGL is more important on desktop.

Only Wayland based DEs have interests in using GLES seriously, IMO.

[przemoli]

ETC2 on current HW is for compilance with OPENGL ES 3.0.

ES stands for EMBEDED SYSTEMS.

Intel desktop GPU's aren't those. So lack of HW support for ETC2 is far from suprising.

(Intell will have GLES 3.0 by spring, or aim at that date, and that is reason for ETC2, not for OpenGL 4.3 early support :P that may even not come to current Intell GPU's if they lack some hw functionality)

Now. show us some nice texture compresion format that is supported by Intel hardware and is used by aplications out there in wild, real world. :P

There is non. So performance hit will not be that much visible. Unless Intel push for S3TC enabled by default. Then, and only then there will be difference between software using S3TC, and software that use ETC2.

PS S3TC is supported in hw? But just disabled, and also need some additional library right?