Originally posted by V!NCENT
View Post
Announcement
Collapse
No announcement yet.
Marek Files Patches For Floating-Point In Mesa Master
Collapse
X
-
-
Originally posted by smitty3268 View PostI 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
-
Originally posted by V!NCENT View PostI 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.
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
-
Originally posted by V!NCENT View PostNo 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
-
Originally posted by V!NCENT View PostI seriously doubt that... You're not sending float to the GPU.
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
-
Originally posted by smitty3268 View PostI 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.
I am not aware of H.264-related code present in Mesa, but I guess I could be missing something.
Comment
Comment