Marek Files Patches For Floating-Point In Mesa Master

[V!NCENT]

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.

[smitty3268]

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.

[V!NCENT]

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.

[V!NCENT]

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

[Prescience500]

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.

[V!NCENT]

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.

[elanthis]

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.

[gzed]

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

[Veerappan]

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.

[marek]

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