t would have.
> (Furthermore b) applies not only to patent issues but any contribution to any
> open source project. The only way to ensure one does not waste time is to get
> the maintainers' buy in for the general concept beforehand.)
In this case, that clearly is
- set s3tc_supported = 0 and s2tc_supported = 0
Change all references to s3tc_supported to s2tc_supported, where it is
applicable to the case (e.g. depending on input source). Change all references
to GL_COMPRESSED_*_S3TC_*_EXT to S2TC_* where applicable.
Best regards,
Rudolf Polzer
_
On Wed, Aug 10, 2011 at 11:42:11AM +0200, Philipp Klaus Krause wrote:
> Am 10.08.2011 11:34, schrieb Rudolf Polzer:
>
> >
> >> The OpenGL ARB cannot incorporate S3TC into a core spec anyway.
> >
> > But it already is core part of OpenGL 3.0.
>
>
On Wed, Aug 10, 2011 at 08:50:38AM +0200, Marek Olšák wrote:
> On Wed, Aug 10, 2011 at 7:11 AM, Rudolf Polzer wrote:
> > To exaggerate again: what if we upload null bytes into that decompressor
> > circuit? The decoding algorithms would still run on the hardware, but all we
>
ly also avoids inferred alpha values. But that this
is necessary seems to generally not be agreed on, given lots of related stuff
on various mailing lists I find on the net. S2TC also has a branch "s2tc+alpha"
that uses full DXT5 alpha encoding instead, but I am unsure whet
eme, and was invented 8 years earlier. That
can get very interesting, as I assume that Apple tries to defend against the
S3TC patent exactly by pointing out the similarity to RPZA (the Quicktime 1
codec).
Best regards,
Rudolf Polzer
___
mesa-dev m
On Tue, Aug 09, 2011 at 03:16:34PM +0200, Philipp Klaus Krause wrote:
> Am 09.08.2011 13:10, schrieb Rudolf Polzer:
> > As for compression: the compressed format is basically "each 4x4 block is a
> > 2-color optimum palette image". Similar schemes have existed way bef
nput is compressed using S2TC, though, no further quality loss would
occur at this stage, as the operation described above would be the identity.
> How should you brought this? You should have assumed that we have our reasons
> -- after all we've been living under the frustration of these patents,
> walking on a mine field, for a decade --, instead of assuming we have NIH
> syndrome.
So I should never try to do anything new, as likely someone else may have
already done it and rejected it.
Good to know.
Best regards,
Rudolf Polzer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
rought this up? I still don't understand WHY this is an
issue. Is US patent law really that retarded? I still can't believe this, as to
me that would mean that Apache would have needed a patent license in order to
transport GIF files back then (or at least, to assign the content type
"image/gif" in the default config).
Best regards,
Rudolf Polzer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
nt
preparing
a PKGBUILD for Arch Linux, but that is about all I can do without having
contact to
people at the distros who decide such things.
Best regards,
Rudolf Polzer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Mon, Aug 08, 2011 at 12:52:14PM -0700, Corbin Simpson wrote:
[force_s3tc_enable]
> It is not transparent if applications must opt into using it.
Applications must also opt into using the regular S3TC extension, by using the
appropriate texture format constant. No difference there, just a differ
ng
OpenGL. So it is available, just by a "different API" than the one in the
OpenGL extension spec (due to an extra putenv() call being required). Including
S2TC, and thus enabling compressed texture upload by default, only changes the
API by wh
;safer" from
those patents (whether it is actually a successful evasion, only a judge can
decide).
The suggestion however is to include a S2TC-like method with Mesa, to basically
make sure that in the long run NO distro has no support for S3TC uploading,
without requiring an extra decision in
gal
> expenses resulting from following your advice? You must think really highly
> of yourself, or think we are really dumb to not have thought/discussed this
> till now.
>
> We need this sort of "IANAL" opinions just as much as we need chronic tooth
> pain.
We have a problem and need to work towards a solution. I am not saying that my
solution is the right one. I am saying we have to work towards one, and need
people
who are actually qualified to do it. I provided an idea, and we need to find ou
if this idea is viable.
As, "Mesa not supporting S3TC, ever" will be the end of linux gaming before it
really started.
Best regards,
Rudolf Polzer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
fies the bitstream of the texture to see that no S3TC
IP is used by it, or "fixes" it by turning S3TC into S2TC by a proper mapping
of pixel values?
At least that's my opinion (IANAL too).
Best regards,
Rudolf Polzer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
this method? One possible implementation BTW
could
be Linux distros shipping S2TC libtxc_dxtn by default, and providing a
"simple"
way for users to upgrade to a full S3TC library, if they are aware of the
issues
with it and see themselves not affected by them
16 matches
Mail list logo
