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

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

  1. #11
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    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.

  2. #12
    Join Date
    Oct 2008
    Posts
    3,176

    Default

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

  3. #13
    Join Date
    Aug 2009
    Posts
    2,264

    Default

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

  4. #14
    Join Date
    Aug 2009
    Posts
    2,264

    Default

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

  5. #15
    Join Date
    Jun 2010
    Posts
    245

    Default

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

  6. #16
    Join Date
    Aug 2009
    Posts
    2,264

    Default

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

  7. #17
    Join Date
    Nov 2007
    Posts
    1,024

    Default

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

  8. #18
    Join Date
    May 2009
    Posts
    4

    Default

    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

  9. #19
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    877

    Default

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

  10. #20
    Join Date
    Jan 2009
    Posts
    626

    Default

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

Posting Permissions

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