Announcement

Collapse
No announcement yet.

ETC2 Texture Compression Looks Good For OpenGL

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • ETC2 Texture Compression Looks Good For OpenGL

    Phoronix: ETC2 Texture Compression Looks Good For OpenGL

    With OpenGL ES 3.0 and OpenGL 4.3 there is now mandatory texture compression support in the form of ETC2, the Ericsson Texture Compression method...

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

  • #2
    This is good but, when will wayland will full suport OpenGL so we can use it in he future?

    Comment


    • #3
      Originally posted by Thaodan View Post
      This is good but, when will wayland will full suport OpenGL so we can use it in he future?
      This is also required by the new openGL ES spec, which Wayland uses. Also, the only reason Wayland uses openGL ES is that the only available full openGL implementation at the moment is GLX which has a dependency on X.

      Comment


      • #4
        Any statement yet from the big three on when we can expect this on desktop gpus, in hardware? Bridgman?

        Comment


        • #5
          So how well does ETC2 stack up with ASTC? Seems we now have several texture compression alternatives to S3TC, what would be the best for games performance and memorywise?

          Originally posted by curaga View Post
          Any statement yet from the big three on when we can expect this on desktop gpus, in hardware? Bridgman?
          I'm sure that the major GPU makers (Intel, AMD and nVidia) will have their implementations and would be good to see the feedback from their respective devs. Hopefully we'll see benchmarks on all these compression methods soon
          Last edited by DeepDayze; 08-12-2012, 05:31 PM.

          Comment


          • #6
            interesting reading, i would like to know if Sandy/Ivy Bridge will support it soon?

            Comment


            • #7
              Originally posted by DeepDayze View Post
              So how well does ETC2 stack up with ASTC? Seems we now have several texture compression alternatives to S3TC, what would be the best for games performance and memorywise?
              To be fair, we have a few years at least for these to mature and get various improvements and optimizations in hardware and encoders. You can't ship a game using either of these today. Or next year. Or even three years from now. Far too few users would have hardware that supports the features. (drivers might support them, but if they're not hardware supported, we won't care.)

              It's a lot like SSE, where SSE3/4 are only just recently becoming feasible to use in a game. It wasn't that long ago that even SSE2 was just a theoretical optimization despite having been in shipping hardware for years. It's a bit easier with code since the binaries are small and you can just ship several versions of the compiled game (Crysis did this, for instance), but for content you'd be duplicating potentially gigabytes of data for each compression algorithm or hardware feature set.

              The Steam hardware survey is really useful to figure out things like this. You can see that some 99% of Steam users have SSE2 now and over 98% have SSE3 and there's no reason not to use them anymore, but only 50% have SSE4 so it's still a no-go (and it added the dot-product operator, dammit... soon). You can see that WinXP is under 15% of users (and see that most of those have older hardware), and hence D3D10/11 are finally viable to use as your sole graphics API for high-sales-volume games. You can see that less than 7% have single-core CPUs, and only 50% of people are still using dual-core CPUs, so you can plan to require threaded engines today and prepare for requiring 4+ cores in the near future. You can see that there are still almost 30% of users with 512MB or less of video ram, so keeping low-quality (and highly compressed) textures is still a must for a little while longer. You can see that 50% still have less than 4GB of RAM and wonder why nobody is telling everyone that RAM is practically free right now. You can see that OS X usage for Steam users is still hovering at 5%, which is higher than some people expect, lower than many people hope, and can be extrapolated to what Linux might look like.

              You can also look at GPUs, see rate of uptake, and figure out what GPU features you can rely on. After ASTC support actually arrives in real hardware, you can track how long it takes for a significant-enough portion of the market to have hardware supporting, and when you can start using it in shipping titles.

              Comment


              • #8
                Originally posted by elanthis View Post
                You can see that WinXP is under 15% of users (and see that most of those have older hardware), and hence D3D10/11 are finally viable to use as your sole graphics API for high-sales-volume games.
                If only games were developed for PCs and not ported from aging consoles...

                Comment


                • #9
                  Originally posted by ShadowBane View Post
                  This is also required by the new openGL ES spec, which Wayland uses. Also, the only reason Wayland uses openGL ES is that the only available full openGL implementation at the moment is GLX which has a dependency on X.
                  Is it so hard to clear GLX from X11 depencies or rewrite a lib that gives full OpenGL support?

                  Comment


                  • #10
                    Originally posted by Thaodan View Post
                    Is it so hard to clear GLX from X11 depencies or rewrite a lib that gives full OpenGL support?
                    The real problem is manpower, Making libGL work without GLX would be nice, and will happen at some point in the future, but right now there isn't enough intrest for this to be a major push.

                    Comment


                    • #11
                      AFAIK, while ETC2 must be supported by the OpenGL implementation, most major desktop graphics vendors will implement it in software. (I know for a fact that nVidia is doing it this way and plans to continue doing it this way for future hardware as well.) This allows them to be "OpenGL compliant," but without actually making ETC2 a viable usable choice.

                      This quote from the article is wrong:
                      Graphics texture compression reduces memory usage and avoids congesting the bus, thereby trying to avoid a performance bottleneck.
                      It should say:
                      Hardware-accelerated graphics texture compression reduces memory usage and avoids congesting the bus, thereby trying to avoid a performance bottleneck. When implemented in software, all it does is add another decoding step which the OpenGL driver must implement, wasting memory and not doing anything at all for bus congestion; this is similar to the reasons why you should always use GL_RGBA instead of GL_RGB, even when you're not using the alpha channel.
                      If we're going to wait for a texture compression scheme to get widespread and implemented commonly in hardware, we might as well wait for ASTC. From what I know it's better than ETC2.
                      Last edited by MaxToTheMax; 08-12-2012, 09:33 PM.

                      Comment


                      • #12
                        Here's a link to the slides without the Phoronix watermark: http://www.khronos.org/assets/upload...RAPH_Aug12.pdf

                        Is it even legal to have the watermark on the slides since it's copyrighted by Ericsson International??? Unless Michael received permission...

                        Comment


                        • #13
                          Originally posted by bug77 View Post
                          If only games were developed for PCs and not ported from aging consoles...
                          The tide is ebbing, no worries.

                          Comment


                          • #14
                            Originally posted by Setlec View Post
                            interesting reading, i would like to know if Sandy/Ivy Bridge will support it soon?
                            None of our currently shipping hardware has native support for ETC2, which means we have to implement it in software. That means that textures are uploaded and stored to the GPU in an uncompressed format, which isn't terribly efficient, but there's not much else we can do. That will at least make applications using ETC2 compressed textures work. (I believe Chad's volunteered to write the software decoder, unless someone beats him to it.)
                            Free Software Developer .:. Mesa and Xorg
                            Opinions expressed in these forum posts are my own.

                            Comment


                            • #15
                              I realize the Intel driver department and hardware department may not communicate at this level, so you may not know this, but it's worth a shot: are you going to be prioritizing hardware ASTC or hardware ECT2 or both for future chipsets? It makes a difference for me personally in my work on Alien Arena, knowing what will and won't be hardware accelerated in the future.
                              Last edited by MaxToTheMax; 08-12-2012, 11:13 PM.

                              Comment

                              Working...
                              X