Announcement

Collapse
No announcement yet.

Marek Files Patches For Floating-Point In Mesa Master

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

  • #16
    Originally posted by Prescience500 View Post
    Hmm...interesting. Wish we had a couple lawyers that followed these forums who could comment.
    I whish BridgeMan would notice it and would curiously poke the legal dep.

    Comment


    • #17
      Originally posted by V!NCENT View Post
      I seriously doubt that... You're not sending float to the GPU.
      Sigh.

      You're confusing "floating point" with the C native type "float". A double is still a floating point number, and is still represented by IEEE754 formats. The patent is (probably) just as valid for 32-bit, 64-bit, and 16-bit floating point types. All three of which are already supported by consumer hardware.

      Also, sending everything as a 64-bit type when you only want 32 bits is bad. Double the memory bandwidth usage. Longer loading times. More disk space usage for resources. No application/game developers want to put up with that just to work around a patent bug that isn't directly impacting them.

      Your supposed workaround doesn't work. Sorry.

      Comment


      • #18
        It doesn't look like the other devs are even going to discuss the patches Marek sent. Let alone apply them. It's a lost cause

        Comment


        • #19
          Originally posted by smitty3268 View Post
          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.
          Care to elaborate? The pipe-video stuff (based on Younes Manton's GSoC project I think) is mostly related to MPEG2. And the new work being done in this year's GSoC is mostly related to VP8 and other open formats. Are my assumptions on what's in pipe-video wrong?

          I am not aware of H.264-related code present in Mesa, but I guess I could be missing something.

          Comment


          • #20
            Originally posted by gzed View Post
            It doesn't look like the other devs are even going to discuss the patches Marek sent. Let alone apply them. It's a lost cause
            It's being discussed in private and it's looking good...

            Comment


            • #21
              Originally posted by marek View Post
              It's being discussed in private and it's looking good...
              Thanks for the update Marek!

              One question for you though: why are you working for R3XX HW only?
              Is it so much easier to program than R6XX?

              Cheers

              Comment


              • #22
                I suspect main parts may easily be ported to r600g. First focusing on the base (prior r600 chips) and then go advance (porting features to r600g) makes sense to my mind.
                Though, I don't think Marek is following that strategy. It's more or less a coincidence.

                Comment


                • #23
                  Originally posted by Veerappan View Post
                  Care to elaborate? The pipe-video stuff (based on Younes Manton's GSoC project I think) is mostly related to MPEG2. And the new work being done in this year's GSoC is mostly related to VP8 and other open formats. Are my assumptions on what's in pipe-video wrong?

                  I am not aware of H.264-related code present in Mesa, but I guess I could be missing something.
                  No, you're correct that there is no code in Mesa yet. I'm referring to a face-to-face meeting Mesa devs had back in 2008 (i think) where the decision was supposedly agreed to that an h.264 decoder could be allowed in as long as it was not compiled by default. That hasn't happened yet, but as far as i know it's only because of a lack of developers working on it, not because of patent concerns.

                  Comment


                  • #24
                    Originally posted by gzed View Post
                    Thanks for the update Marek!

                    One question for you though: why are you working for R3XX HW only?
                    Is it so much easier to program than R6XX?

                    Cheers
                    There are several reasons for this:
                    - I like my r500 hw.
                    - I know the hw and the driver code very well.
                    - The driver is so stable, fast, and superior to any other gallium driver that it's a good reference driver for testing other pieces of Mesa.
                    - I am unpaid, so I do what I consider useful to myself.

                    Comment


                    • #25
                      Originally posted by marek View Post
                      There are several reasons for this:
                      - I like my r500 hw.
                      - I know the hw and the driver code very well.
                      - The driver is so stable, fast, and superior to any other gallium driver that it's a good reference driver for testing other pieces of Mesa.
                      - I am unpaid, so I do what I consider useful to myself.
                      Fair enough Marek.

                      I wasn't criticizing the fact, I was just being a curious cat :P

                      I was considering donating R6XX class HW to you, but it will probably become paperweight considering your last reply.

                      R6XX or not I admire your constant work on mesa/gallium.

                      Cheers

                      Comment


                      • #26
                        Originally posted by gzed View Post
                        I was considering donating R6XX class HW to you, but it will probably become paperweight considering your last reply.
                        Not needed, I own at least one card from each generation up to evergreen and I did work on r600g in the past (was optimizing vertex uploads and made lightsmark 3x faster).

                        Comment


                        • #27
                          Originally posted by marek View Post
                          There are several reasons for this:
                          - I like my r500 hw.
                          - I know the hw and the driver code very well.
                          - The driver is so stable, fast, and superior to any other gallium driver that it's a good reference driver for testing other pieces of Mesa.
                          - I am unpaid, so I do what I consider useful to myself.
                          All very good reasons, not that I doubted. I've still got an x300 laying around in one of my laptops, so you'll get no arguments here.

                          Work on the hardware you know best. It's a better use of time than learning an entirely new chip architecture, especially when some of the commits directly improve all gallium drivers.

                          Well, since you've got the hardware angle covered, the first beer's on me if we ever meet.

                          Comment


                          • #28
                            Originally posted by Veerappan View Post
                            Well, since you've got the hardware angle covered, the first beer's on me if we ever meet.
                            Yep, I guess he has loads promises of "free beer" from all around the globe. Marek, you should start travelling!

                            Let me know if you do and I'll get a round or two for you as well!
                            Oh, and the same goes for Corbin and Christian (if he finishes the h264 decoder )!

                            Comment

                            Working...
                            X