Announcement

Collapse
No announcement yet.

What Was Decided With S3TC & Floating Points For Mesa

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

  • What Was Decided With S3TC & Floating Points For Mesa

    Phoronix: What Was Decided With S3TC & Floating Points For Mesa

    Last week I mentioned that a developer called for a discussion about merging the OpenGL floating point textures and render targets branch into mainline Mesa. This code has been ready for a while but hasn't been merged due to patent concerns, but to alleviate that while pushing the code forward, the proposed idea was to add a --enable-patented build option. Over the weekend, the discussion continued and it was then also proposed to merge the S3TC texture compression work (another feature where developers are concerned about patent infringement) and to conceal that behind the new build option too. So what happened since and did the work make it into the mainline Mesa Git repository?..

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

  • #2
    If I understand the process correctly Mesa has to be rebuild either way if the S3TC work is brought in tree or left as a library

    If it's left as a library and it isn't present at compile time Mesa won't have S3TC support again as per my understanding (and I might be wrong)

    I'm guessing it would be better to bring it in tree to prevent the library falling out of sync with the rest of Mesa

    Comment


    • #3
      Software patents suck.

      Comment


      • #4
        Originally posted by FireBurn View Post
        If I understand the process correctly Mesa has to be rebuild either way if the S3TC work is brought in tree or left as a library
        Wrong.

        Originally posted by FireBurn View Post
        If it's left as a library and it isn't present at compile time Mesa won't have S3TC support again as per my understanding (and I might be wrong)
        Wrong.

        Originally posted by FireBurn View Post
        I'm guessing it would be better to bring it in tree to prevent the library falling out of sync with the rest of Mesa
        There isn't any out of sync problem, an external library for S3TC is a very good solution.
        ## VGA ##
        AMD: X1950XTX, HD3870, HD5870
        Intel: GMA45, HD3000 (Core i5 2500K)

        Comment


        • #5
          Originally posted by thefirstm View Post
          Software patents suck.
          the bigger problem is that an open specification decided to use patented stuff IMO

          i don't know however if it could be done in another way

          Comment


          • #6
            Originally posted by darkbasic View Post
            Wrong.


            Wrong.


            There isn't any out of sync problem, an external library for S3TC is a very good solution.
            So what is correct Mr Smarty Pants?

            Comment


            • #7
              Originally posted by thefirstm View Post
              Software patents suck.
              Damn right. That's why the US residents should finally wake up and do something about it, because "Yes, you can!" and you're most likely the only ones who can.
              If you find anything in the current legislation outrageous, stupid or both, simply start urging your representative to change that and don't forget to be persistent, because they just can't ignore the flood of mail and phone calls forever. If only "bothering your congressman with something like this as many times a day as you can" was made into a competition. The only problem might be organizing something like that on a massive scale and that's when social networks come in. I wonder how much longer is it gonna take before sheeple realize the power of democracy, which they're so unwilling to use.
              I'm quite sure that many Europeans would love to help, but there's probably not much we can do other than showing our support.

              Comment


              • #8
                Originally posted by FireBurn View Post
                So what is correct Mr Smarty Pants?
                The S3TC library doesn't have to be present at compile time. You can compile it after compiling Mesa, and Mesa dynamically loads it somehow. It's linked at runtime rather than compile time. I think they use dlopen() ? It has a man page that you can read up on if you're interested.

                Comment


                • #9
                  Originally posted by FireBurn View Post
                  So what is correct Mr Smarty Pants?
                  Obviously the opposite, what else?
                  Also, don't feel offended if someone corrects you when you write yourself that you may be wrong...
                  ## VGA ##
                  AMD: X1950XTX, HD3870, HD5870
                  Intel: GMA45, HD3000 (Core i5 2500K)

                  Comment


                  • #10
                    However, it was pointed out in the mailing list thread that you're going to have to compile mesa *anyway* to get the float support, so it doesn't really matter on top to have s3tc included.

                    Then the usual benefits, ie one place to go, no bitrot...

                    Comment


                    • #11
                      Originally posted by pvtcupcakes View Post
                      The S3TC library doesn't have to be present at compile time. You can compile it after compiling Mesa, and Mesa dynamically loads it somehow. It's linked at runtime rather than compile time. I think they use dlopen() ? It has a man page that you can read up on if you're interested.
                      This is correct. The dlopen(<libname>) function opens a shared library at run-time, and then you use the dlsym() function to get pointers to named functions within that library. Then you just store a reference to the function pointer and call that whenever you need to do S3TC-related work. Check out <dlfcn.h> and the dlopen/dlsym/dlclose man pages.

                      Think of the S3TC library as a plugin which is loaded if it's present, but if the Mesa library doesn't find it, or can't load it, it's no big deal.

                      Comment


                      • #12
                        Originally posted by darkbasic View Post
                        Obviously the opposite, what else?
                        Also, don't feel offended if someone corrects you when you write yourself that you may be wrong...
                        I don't mind being corrected, saying "Wrong" isn't a correction though

                        Thanks for the dlopen() info the reason I was confused was one of the previous articles comments mentioned having to rebuild mesa

                        Comment


                        • #13
                          Maybe I just didn't read enough of the discussion, but has anyone said anything against putting this stuff behind the --enable-patented configure option and why not?

                          Comment


                          • #14
                            Maybe I just didn't read enough of the discussion, but has anyone said anything against putting this stuff behind the --enable-patented configure option and why not?
                            I thought the article did a reasonably good job. The floating point work apparently causes performance regressions, and s3tc is already more convenient as an optional shared object.

                            Comment


                            • #15
                              Originally posted by 89c51 View Post
                              the bigger problem is that an open specification decided to use patented stuff IMO

                              i don't know however if it could be done in another way
                              "Open" means that the specification is available to read and study free of royalty; nothing else. You are confusing "open specifications" with "open implementations."

                              And no, it couldn't have been done any other way. There is an actual _reason_ why people want OpenGL 3 support including all of its mandatory features; you realize this, right? Floating point textures are _essential_ for many modern rendering techniques. You cannot do them without floating point textures and render buffers. Period.

                              Without floating point textures, I really don't give a shit what other OpenGL 3/4 features Mesa gains. It's useless for modern AAA game engines until there is proper floating point support. Everything else modern games do is totally possible on OpenGL 2/DirectX 9. Geometry shaders, hardware tessellation, and so on are nice and useful but are not as essential.

                              The only other thing that the newer OpenGL versions bring with them that is essential is instanced rendering (which is already available as an extension in Mesa, so that's all good) and newer versions of GLSL that are ever so slightly less retarded than the original GLSL. (But GLSL still sucks. Nobody serious is using it directly; I've yet to meet anyone who didn't vastly prefer HLSL or Cg, and Cg only when portability is essential -- that's how bad GLSL is. For the simple graphics stuff I do it's fine, but the graphics pros I work with uniformly despise it, and the OpenGL API in general. That includes the ones who learned OpenGL before DirectX, I might note, so don't claim it's bias from familiarity. Mostly the GLSL complains all revolve around how hard it is to build advanced runtime effects composition layers, which was actually literally impossible to do right until GLSL 4.10/3.30, and even with those it's still way harder to get right than with HLSL/Cg.).

                              Comment

                              Working...
                              X