Announcement

Collapse
No announcement yet.

Marek Files Patches For Floating-Point In Mesa Master

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

  • Marek Files Patches For Floating-Point In Mesa Master

    Phoronix: Marek Files Patches For Floating-Point In Mesa Master

    Forget about the fun being had today on April Fools' Day with openSUSE / Gentoo / Arch / Debian supposedly merging to form the Centerbury Linux distribution, GNOME 3.0 being delayed until September, or hypothetical Linux disasters as there is actually some serious and important news: Marek Olk has published his patch-set he wishes to push into Mesa master for OpenGL 3.0 floating-point textures and render-buffers support. He's pushing for this legally-iffy code to go into the mainline Mesa code-base but to block it by an opt-in --enable-texture-float build flag...

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

  • #2
    Hopefully this will get merged. I noticed that the other half of Marek's floating point branch got merged a couple days ago. It was the color_buffer extension which has something to do with clamping.

    Hopefully all this can be quickly ported to r600g.

    Comment


    • #3
      Originally posted by pvtcupcakes View Post
      Hopefully all this can be quickly ported to r600g.
      this is what i wanted to ask

      does the patches work on all gallium cards right???



      Either way thumbs up and czech beers for marek

      Comment


      • #4
        According to my git-log scanning,

        r300g cards are totally supported.
        Nouveau guy ported some or all of the current merged stuff in nv50/nvc0.
        r600g don't have anything in yet

        Comment


        • #5
          I just had an idea today...

          This involves sending floating point to the GPU right? What if it was a big fsckin integer, with a float flag and a comma position flag, then hack the firmware to calculate that as float?

          Does this circumvent the patent?

          Comment


          • #6
            If that's all there is to it, then I have to ask: why is there a patent on sending floating point numbers to a GPU in the first place?

            Comment


            • #7
              marek is just impressiv the r300 (openGL2.1 hardware) do more openGL3 than the dx10/openGL3 hardware like hd2600 ...

              really strange...

              Comment


              • #8
                Originally posted by aaaantoine View Post
                If that's all there is to it, then I have to ask: why is there a patent on sending floating point numbers to a GPU in the first place?
                I think it's floating-point encoded textures, which may cover some kind of codec. It's probably all bullshit anyway, but there's a risk involved in using it without written permission and there goes a lot of money in defending yourself from patent infringement, even if it's bullshit.

                The real problem with patents is that they accept anything to be patented nowadays.

                Comment


                • #9
                  Nice. In after character limit.

                  Comment


                  • #10
                    Let's hope this gets in

                    I don't understand at all why h.264 patented code was agreed to be allowed in (not compiled by default) but they have an issue with this code doing the same thing.

                    Was the h.264 decision reversed later? Are people making different decisions on a patent-by-patent basis? It would be nice if they clarified their position and set down some hard rules about how it should be handled. Even if it's just "this will never happen" at least that would clarify things for anyone who wants to contribute.

                    Comment


                    • #11
                      No wait; I got a better idea... Assume double float, then have the firmware round it of to this 'unprecise float'.

                      AMD still has to have a license, but Mesa/Gallium is in the clear because it obviously supersedes this 'invention'.

                      And last but not least it's new prior art to combat future bullshit.

                      Comment


                      • #12
                        Originally posted by V!NCENT View Post
                        No wait; I got a better idea... Assume double float, then have the firmware round it of to this 'unprecise float'.

                        AMD still has to have a license, but Mesa/Gallium is in the clear because it obviously supersedes this 'invention'.

                        And last but not least it's new prior art to combat future bullshit.
                        I think the patent relies at least in part on work the actual hardware is accelerating, so any type of workaround that results in the same stuff being done on the hardware may not be any better. And it's been said before that some patents AMD has licensed are only valid with their own drivers, not others.

                        Comment


                        • #13
                          Originally posted by smitty3268 View Post
                          I think the patent relies at least in part on work the actual hardware is accelerating, so any type of workaround that results in the same stuff being done on the hardware may not be any better. And it's been said before that some patents AMD has licensed are only valid with their own drivers, not others.
                          I seriously doubt that... You're not sending float to the GPU. Furthermore the patent itself states that it's different from prior art of Pixar: which is about using float in software and rounding it of before sending it to the GPU and discribing it inside of the GPU as being float.

                          Comment


                          • #14
                            Originally posted by V!NCENT View Post
                            I seriously doubt that... You're not sending float to the GPU. Furthermore the patent itself states that it's different from prior art of Pixar: which is about using float in software and rounding it of before sending it to the GPU and discribing it inside of the GPU as being float.
                            *Stupid edit limit!*

                            Also; if the firmware decides to make it float then the AMD driver (firmware = driver) does it (and not mesa), although you could argue that the AMD drivers are not fully FLOSS (but who the hell cares?).

                            Comment


                            • #15
                              Originally posted by V!NCENT View Post
                              No wait; I got a better idea... Assume double float, then have the firmware round it of to this 'unprecise float'.

                              AMD still has to have a license, but Mesa/Gallium is in the clear because it obviously supersedes this 'invention'.

                              And last but not least it's new prior art to combat future bullshit.
                              Hmm...interesting. Wish we had a couple lawyers that followed these forums who could comment.

                              Comment

                              Working...
                              X