If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
For the OGG lovin Freetards like me who don't want any proprietary crap, can you elaborate on what impact the lack of said features will have on my desktop? Is it safe to assume we are just talking about losing a chunk of performance here, and that major features like Gallium3D, Clutter, and all that stuff will still work?
S3TC's been iffy for a while. Floating-point textures are required for certain computational apps.
You lose a couple esoteric features. No performance loss; these features are largely for improving rendering quality, sometimes at the cost of speed (floating-point buffers are four times the size of normal 32-bit buffers.)
I'm getting sick and tired of all the useless and immature complaining about software patents. Yes, they totally suck, we have all known this for quite some time now. But they exist, and don't appear to be going anywhere anytime soon - you can't just ignore them or stick your head in the sand and hope they go away. We don't need another SCO situation but where this time Evil Co. comes up with the patent goods to back up their lawsuit, and is awarded an order for Canonical/RedHat to stop shipping Linux, they spread more FUD, etc, etc. So, given that situation, how should the community deal with the situation within the confines of the law? This is why MESA is (smartly) adding compile time flags, and why Free formats like OGG were created, great. I would just like to see a more serious impact assessment - what needs to be worked around, and what problems will this actually cause us. Any?
S3TC's been iffy for a while. Floating-point textures are required for certain computational apps.
You lose a couple esoteric features. No performance loss; these features are largely for improving rendering quality, sometimes at the cost of speed (floating-point buffers are four times the size of normal 32-bit buffers.)
Thank you very much for letting us know what the actual situation here is. It sounds like we don't have too too much to worry about then.
I guess almost every today's game out there requires floating-point textures (e.g. for advanced shadow mapping and HDR postprocessing), so do not expect them to run or be watchable. Then put S3TC out, which might increase your videomemory consumption up to 8x (the compression ratio of DXT1), and you can really forget about doing some serious computer graphics with open source drivers. Thank god I don't live in US and never will.
Most of the other GL3.x functionality can be exposed through extensions, except the ClearBuffer API.
Thank you very much for letting us know what the actual situation here is. It sounds like we don't have too too much to worry about then.
Actually...the problem lies in getting studios to sign off on something less than this stuff. They WANT this sort of stuff because it makes it easier to do their "art" with "less effort". Not that I blame them, mind- but trying to get games on Linux, well, it'll be a smidge harder to sell people on it if we don't have OGL 3.0 or ES 2.0 in hand in their entirety in a form that many, if not most, can use largely out of box with.
S3TC is a problem.
Lack of having the "good" render targets is a problem.
The thing that concerns me is that we're getting told that a data structure (that's all a render target is within the API) is covered by patent(s). S3TC is "covered" in the sense of not easily or readily being able to use it- not because of the data, but because you need to use the algorithm that IS patented to provide these textures. Now, you can merely provide the compressed textures directly to the card, but since you have to be able to support providing a raw texture and then compressing it to the specified compressed format, they opt (and rightly so) to not support any aspect of it currently (though it sounds like that's changing... ). I find it disturbing that they're having to side-step floating point rendering/texture targets for "patent reasons".
To the best of my knowlege, no algorithms needed. Just a data structure to pull from or put into since it's NOT compressed.
Last edited by Svartalf; 01 October 2009, 10:46 PM.
Um shouldn't it be that the hardware implementation of floating point compression is patented?
I mean you can reimplement that same compression with different hardware at least that is how patents are supposed to work. Afaik basic computer components are not patentable although archetecutral designs are. ie MIPS ARM ALPHA x86 etc... patents on registers or and gates would just be stupid specific kinds of and gates and registers however are patentable I suppose
Patents are to protect the exact method for doing something not every method for doing it under teh sun
When did all this stuff get stupid (when money came into the picture I suppose) its like saying you own a copyright on hardback books or something.
Perhaps the S3TC texture compression could be fought on the basis that it is the defacto standard for floating point compression? Or that any proprietary implementation can't be stolen and used but can be reimplemented in a different way.
Look at it this way. Patents haven't prevented anybody determined from getting patented audio or video support.
That's nice, but patents are actually preventing everybody from getting S3TC in Mesa, regardless of the country. Hopefully this one will change soon...
Comment