Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: ETC2 Texture Compression Looks Good For OpenGL

  1. #11
    Join Date
    Sep 2009
    Posts
    116

    Default

    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 at 09:33 PM.

  2. #12
    Join Date
    Jan 2012
    Posts
    140

    Default

    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...

  3. #13
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote 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.

  4. #14
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    124

    Default

    Quote 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.)

  5. #15
    Join Date
    Sep 2009
    Posts
    116

    Default

    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 at 11:13 PM.

  6. #16
    Join Date
    Aug 2012
    Posts
    2

    Default

    Michael, I don't think you can say royalty free is the same as not patented. Ericsson probably has it completely covered but has been nice enough to let Khronos use it in their APIs.

  7. #17
    Join Date
    Mar 2012
    Posts
    79

    Default Never

    Quote 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?
    Wayland is about sharing buffers between a client and a server, you can use whatever you want in the client to draw the buffer so Wayland is irrelevant here.
    I repeat Wayland has *no* drawing API, and the article is about an improvement to a drawing API..

  8. #18
    Join Date
    Apr 2007
    Posts
    372

    Default

    Quote Originally Posted by Kayden View Post
    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.)

    Thank you for the quick answer. you guys are impressing me!

  9. #19
    Join Date
    Jan 2009
    Posts
    452

    Default

    Quote Originally Posted by Kayden View Post
    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.)
    Kayden,

    Is ETC2 arithmetically similar enough to a supported texture-compression format that you might be able to do partial acceleration via an intermediate format? Basically, take a loss on the CPU which would transcode ETC2 to the intermediate, and make up, or exceed the loss on the GPU?

    The example that comes to mind is when we were able to get an old SigmaDesign hardware MPEG1 decoder to partially accelerate MPEG2 video.

    F

  10. #20

    Default

    Is ETC2 really required by GL 4.3 as stated in the article? I don't see it listed here: http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •