From: Geoffrey A. <geo...@an...> - 2002-12-19 03:14:29
|
I believe that it is safe to go ahead and implement S3TC texture decompression code in DRI. Microsoft has licensed S3TC to put in DirectX, and since DirectX 6, S3TC has been called DXTn or DXTC, and has been part of the DirectX Specification The DirectX Documentation is semi-freely available. The SDK + SDK Docs can be downloaded for free off the internet. The Windows DDK + DDK Docs must be ordered, but only shipping and handling fees occur. The CD itself costs nothing. With these resources, the format is "freely" available for all NVidia has posted an open source library from BlackBoxGames that can decode/encode S3TC/DXTC/DXTn images. The library is located at: http://developer.nvidia.com/docs/IO/2657/ATT/ImageLib.zip The devIL project at SourceForge has code to convert between .ddc files, DirectX's do-it-all texture format, which can be compressed with S3TC/DXTn/DXTC. The project is located at http://openil.sourceforge.net Thus, there are many indications that S3TC can be used for Open Source projects without fear. |
From: Adam K K. <ad...@vo...> - 2003-12-28 15:23:37
|
Now that there are patches available to support S3TC compressed textures on Radeon cards, are there any plans to integrate those patches into the DRI source tree? Adam |
From: Jacek <jp...@an...> - 2003-12-28 16:03:16
|
On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote: > Now that there are patches available to support S3TC compressed textures > on Radeon cards, are there any plans to integrate those patches into the > DRI source tree? I think there is one little problem: - S3TC included into DRI CVS - DRI CVS copied into XFree86 CVS - XFree86 makes release - RedHat puts new XFree86 in distribution - S3TC patent holder sues RedHat So maybe it's better to put patches/binaries on unofficial websites and in p2p? -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net |
From: Adam K K. <ad...@vo...> - 2003-12-28 16:08:34
|
On Sun, 28 Dec 2003, Jacek [iso-8859-2] Pop=B3awski wrote: > On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote: > > Now that there are patches available to support S3TC compressed texture= s > > on Radeon cards, are there any plans to integrate those patches into th= e > > DRI source tree? > > I think there is one little problem: > > - S3TC included into DRI CVS > - DRI CVS copied into XFree86 CVS > - XFree86 makes release > - RedHat puts new XFree86 in distribution > - S3TC patent holder sues RedHat > > So maybe it's better to put patches/binaries on unofficial websites and i= n p2p? Why not just leave it up to RedHat, then, to either leave the code in or pull it out? Adam |
From: Jacek <jp...@an...> - 2003-12-28 16:41:46
|
On Sun, Dec 28, 2003 at 11:08:26AM -0500, Adam K Kirchhoff wrote: > Why not just leave it up to RedHat, then, to either leave the code in or > pull it out? RedHat was just example. Point is that patent holder may sue anyone who: - will release XFree86 version with S3TC support - has some money And it is possible that some distribution would remove whole DRI support just to not have problems with S3TC. -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net |
From: Adam K K. <ad...@vo...> - 2003-12-28 17:49:00
|
On Sun, 28 Dec 2003, Jacek [iso-8859-2] Pop=B3awski wrote: > On Sun, Dec 28, 2003 at 11:08:26AM -0500, Adam K Kirchhoff wrote: > > Why not just leave it up to RedHat, then, to either leave the code in o= r > > pull it out? > > RedHat was just example. Point is that patent holder may sue anyone who: > > - will release XFree86 version with S3TC support > - has some money > > And it is possible that some distribution would remove whole DRI support = just > to not have problems with S3TC. Then no one will download/purchase/use that distribution. Their loss :-) Adam |
From: Dieter <Die...@ha...> - 2003-12-28 16:52:22
|
Am Sonntag, 28. Dezember 2003 17:08 schrieb Adam K Kirchhoff: > On Sun, 28 Dec 2003, Jacek [iso-8859-2] Pop=B3awski wrote: > > On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote: > > > Now that there are patches available to support S3TC compressed > > > textures on Radeon cards, are there any plans to integrate those > > > patches into the DRI source tree? > > > > I think there is one little problem: > > > > - S3TC included into DRI CVS > > - DRI CVS copied into XFree86 CVS > > - XFree86 makes release > > - RedHat puts new XFree86 in distribution > > - S3TC patent holder sues RedHat > > > > So maybe it's better to put patches/binaries on unofficial websites and > > in p2p? > > Why not just leave it up to RedHat, then, to either leave the code in or > pull it out? Very, very true! That's exactly what I would have suggested. There are NO "software patents" in the EU (EP=DC) at least here in Germany. We have asked (S3/VIA etc.) so many times for advice, but haven't had any=20 definitive answer, even sometimes NO answer at all. So let's put it in and see "what will happen". Here in Europe (Germany) the patent "owner" have to "fight" (defend) his=20 patent. Without that it can be deleted... Maybe we should host mesa3d and DRI in a "save" country. Greetings, Dieter =2D-=20 Dieter N=FCtzel @home: <Dieter.Nuetzel () hamburg ! de> |
From: Alan C. <al...@lx...> - 2003-12-28 23:18:09
|
On Sul, 2003-12-28 at 16:55, Dieter N=C3=BCtzel wrote: > We have asked (S3/VIA etc.) so many times for advice, but haven't had any= =20 > definitive answer, even sometimes NO answer at all. I don't think S3, VIA and friends even know who actually owns it right now. You need to distinguish between: An implementation of S3TC compression A tool that is using existing licensed S3TC compression aware hardware The former is certainly covered by the patent. The latter does not seem to be, no more than say an X86 application violates patents on aspects of x86 CPU design If someone can precisely define what the patch has in it and the patent numbers again (I lost them) I can see if our patent/legal people will take a look at that aspect and give an opinion |
From: Daniel V. <vo...@ep...> - 2003-12-28 23:49:38
|
> I don't think S3, VIA and friends even know who actually owns it right > now. S3Graphics (subsiduary of VIA) is the patent holder with Nadeem Mohammad being the contact person about licensing there. -- Daniel, Epic Games Inc. |
From: Roland S. <rsc...@hi...> - 2003-12-28 17:12:32
|
Dieter N=FCtzel wrote: > Am Sonntag, 28. Dezember 2003 17:08 schrieb Adam K Kirchhoff: >=20 >>On Sun, 28 Dec 2003, Jacek [iso-8859-2] Pop=B3awski wrote: >> >>>On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote: >>> >>>>Now that there are patches available to support S3TC compressed >>>>textures on Radeon cards, are there any plans to integrate those >>>>patches into the DRI source tree? >>> >>>I think there is one little problem: >>> >>>- S3TC included into DRI CVS >>>- DRI CVS copied into XFree86 CVS >>>- XFree86 makes release >>>- RedHat puts new XFree86 in distribution >>>- S3TC patent holder sues RedHat >>> >>>So maybe it's better to put patches/binaries on unofficial websites an= d >>>in p2p? >> >>Why not just leave it up to RedHat, then, to either leave the code in o= r >>pull it out? >=20 >=20 > Very, very true! >=20 > That's exactly what I would have suggested. > There are NO "software patents" in the EU (EP=DC) at least here in Germ= any. >=20 > We have asked (S3/VIA etc.) so many times for advice, but haven't had a= ny=20 > definitive answer, even sometimes NO answer at all. >=20 > So let's put it in and see "what will happen". > Here in Europe (Germany) the patent "owner" have to "fight" (defend) hi= s=20 > patent. Without that it can be deleted... >=20 > Maybe we should host mesa3d and DRI in a "save" country. I think using an external library (such as the already mentioned stuff=20 from 3dfx) for compression/decompression would solve potential problems.=20 Just passing the already compressed textures to the chip should be no=20 problem IMHO, Mesa/DRI would just rely on the external library for=20 compression (and decompression for software fallbacks). So distributors=20 wouldn't have to worry, and end users could install the external library=20 if they want without the need to patch and compile everything. Another possiblity would be to #ifdef everything out per default -=20 disabled code shouldn't be a problem (if some algorithm is patented, it=20 is open to the public anyway). That would still mean everybody needed to=20 compile Mesa/DRI themselves, though. Roland btw I don't think you can lose a patent, even in europe. You can lose=20 trademarks if you don't defend them. If a patent is actually valid and=20 can be enforced (bascially court will decide this, not patent office) is=20 a different matter of course. |
From: Dieter <Die...@ha...> - 2003-12-28 17:21:52
|
Am Sonntag, 28. Dezember 2003 18:16 schrieb Roland Scheidegger: > Dieter N=FCtzel wrote: > > Am Sonntag, 28. Dezember 2003 17:08 schrieb Adam K Kirchhoff: > >>On Sun, 28 Dec 2003, Jacek [iso-8859-2] Pop=B3awski wrote: > >>>On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote: > >>>>Now that there are patches available to support S3TC compressed > >>>>textures on Radeon cards, are there any plans to integrate those > >>>>patches into the DRI source tree? > >>> > >>>I think there is one little problem: > >>> > >>>- S3TC included into DRI CVS > >>>- DRI CVS copied into XFree86 CVS > >>>- XFree86 makes release > >>>- RedHat puts new XFree86 in distribution > >>>- S3TC patent holder sues RedHat > >>> > >>>So maybe it's better to put patches/binaries on unofficial websites and > >>>in p2p? > >> > >>Why not just leave it up to RedHat, then, to either leave the code in or > >>pull it out? > > > > Very, very true! > > > > That's exactly what I would have suggested. > > There are NO "software patents" in the EU (EP=DC) at least here in Germ= any. > > > > We have asked (S3/VIA etc.) so many times for advice, but haven't had a= ny > > definitive answer, even sometimes NO answer at all. > > > > So let's put it in and see "what will happen". > > Here in Europe (Germany) the patent "owner" have to "fight" (defend) his > > patent. Without that it can be deleted... > > > > Maybe we should host mesa3d and DRI in a "save" country. > > I think using an external library (such as the already mentioned stuff > from 3dfx) for compression/decompression would solve potential problems. > Just passing the already compressed textures to the chip should be no > problem IMHO, Mesa/DRI would just rely on the external library for > compression (and decompression for software fallbacks). So distributors > wouldn't have to worry, and end users could install the external library > if they want without the need to patch and compile everything. > Another possiblity would be to #ifdef everything out per default - > disabled code shouldn't be a problem (if some algorithm is patented, it > is open to the public anyway). That would still mean everybody needed to > compile Mesa/DRI themselves, though. > > Roland > btw I don't think you can lose a patent, even in europe. You can lose > trademarks if you don't defend them. True. But someone can request a "patent action of nullity". > If a patent is actually valid and=20 > can be enforced (bascially court will decide this, not patent office) is > a different matter of course. But we have NO "software patents" currently, here. =2D-=20 Dieter N=FCtzel @home: <Dieter.Nuetzel () hamburg ! de> |
From: Alan C. <al...@lx...> - 2003-12-28 23:20:59
|
On Sul, 2003-12-28 at 17:16, Roland Scheidegger wrote: > btw I don't think you can lose a patent, even in europe. You can lose > trademarks if you don't defend them. If a patent is actually valid and > can be enforced (bascially court will decide this, not patent office) is > a different matter of course. In certain cases you can. Mostly by a process known as Estoppel (which is just a very old word for a promise). The behaviour is very different to that of trademarks however. For example if I own a patent and I release code that uses that patent and invite you to use it then it is likely that if I tried to sue you for patent violation I'd lose. By my actions I made a promise to you not to do so. Now you know why every intel and other document contains "no patents licensed" type clauses 8) |
From: areversat <are...@tu...> - 2003-12-28 23:34:08
|
As far as i know, software patents are not even legal in europe yet. Hopefully they won't ever be... So, at least in europe, there shouldn't be any problem using S3TC compression algorithm. Well that's all i wanted to say... Bye Le lun 29/12/2003 =C3=A0 00:16, Alan Cox a =C3=A9crit : > On Sul, 2003-12-28 at 17:16, Roland Scheidegger wrote: > > btw I don't think you can lose a patent, even in europe. You can lose=20 > > trademarks if you don't defend them. If a patent is actually valid and=20 > > can be enforced (bascially court will decide this, not patent office) i= s=20 > > a different matter of course. >=20 > In certain cases you can. Mostly by a process known as Estoppel (which > is just a very old word for a promise). The behaviour is very different > to that of trademarks however. >=20 > For example if I own a patent and I release code that uses that patent > and invite you to use it then it is likely that if I tried to sue you > for patent violation I'd lose. By my actions I made a promise to you not > to do so. >=20 > Now you know why every intel and other document contains "no patents > licensed" type clauses 8) >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel |
From: Ian R. <id...@us...> - 2003-12-29 18:35:45
|
Adam K Kirchhoff wrote: > Now that there are patches available to support S3TC compressed textures > on Radeon cards, are there any plans to integrate those patches into the > DRI source tree? Until an agreement can be reached between the open-source community and the patent holder, IT WILL NEVER HAPPEN! STOP ASKING!!! |
From: Adam K K. <ad...@vo...> - 2003-12-29 18:52:39
|
On Mon, 29 Dec 2003, Ian Romanick wrote: > Adam K Kirchhoff wrote: > > Now that there are patches available to support S3TC compressed textures > > on Radeon cards, are there any plans to integrate those patches into the > > DRI source tree? > > Until an agreement can be reached between the open-source community and > the patent holder, IT WILL NEVER HAPPEN! STOP ASKING!!! Why are you YELLING?!!! It's an easy question that A) I've never heard asked, and B) I've never heard a definative answer (just speculation that pops up every few months, last time before the patches were even available). There's no reason to cop an attitude. Just politely answer: "Due to the legal implications, it's not going to happen at the moment." See how simple that is? If it will never happen this should be noted *prominently* on the DRI website in big bold letters. Otherwise, when it becomes common knowledge that their are patches available and that they aren't being applied to the code base, you can expect a whole hell of a lot more people asking this very simple question, and we wouldn't want to upset you any more than you already are. And then you shouldn't be surprised when peole stop using the open source DRI drivers in favor of closed source drivers. Adam |
From: Adam K K. <ad...@vo...> - 2003-12-29 18:59:37
|
BTW, since I originally asked this question, the general tone of the discussion has been positive and the general consensus seems to be that simply uploading the compressed textures to the card, and allowing the hardware to handle the decompression is not a violation of the patents in question. Perhaps you'd like to wait till we hear back from the legal people Alan Cox has asked to take a look at the issue before you jump to your decision. Adam On Mon, 29 Dec 2003, Ian Romanick wrote: > Adam K Kirchhoff wrote: > > Now that there are patches available to support S3TC compressed textures > > on Radeon cards, are there any plans to integrate those patches into the > > DRI source tree? > > Until an agreement can be reached between the open-source community and > the patent holder, IT WILL NEVER HAPPEN! STOP ASKING!!! > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Ian R. <id...@us...> - 2003-12-29 20:42:02
|
Adam K Kirchhoff wrote: > BTW, since I originally asked this question, the general tone of the > discussion has been positive and the general consensus seems to be that > simply uploading the compressed textures to the card, and allowing the > hardware to handle the decompression is not a violation of the patents in > question. > > Perhaps you'd like to wait till we hear back from the legal people Alan > Cox has asked to take a look at the issue before you jump to your > decision. Again, I'm not a lawyer and this is not legal advice. As you've already found, you need to implement software decompression for rendering fallbacks. I don't know of any way that could /not/ be problematic. |
From: Matt S. <ma...@ki...> - 2003-12-29 19:12:11
|
Even if a decision isn't reached, or a compromise with the patent holder isn't possible, knowing who the patent holder is might be nice - we're doing Radeon drivers right now for our own OS (unfortunately DRI is a little too Linux-specific :) and we could license it for ourselves if so desired. Ian: wouldn't it be possible to have an "official patch", for compressed texture stuff, that tracks the trees & releases? The same way Freetype contains patented code, you can get the source, you can compile it, the moment you use it for anything you need to go talk to Apple's licensing guys.. -- Matt Sealey ----- Original Message ----- From: "Adam K Kirchhoff" <ad...@vo...> To: "Ian Romanick" <id...@us...> Cc: "DRI developer's list" <dri...@li...> Sent: Monday, December 29, 2003 10:58 AM Subject: Re: [Dri-devel] S3TC > > BTW, since I originally asked this question, the general tone of the > discussion has been positive and the general consensus seems to be that > simply uploading the compressed textures to the card, and allowing the > hardware to handle the decompression is not a violation of the patents in > question. > > Perhaps you'd like to wait till we hear back from the legal people Alan > Cox has asked to take a look at the issue before you jump to your > decision. > > Adam > > On Mon, 29 Dec 2003, Ian Romanick wrote: > > > Adam K Kirchhoff wrote: > > > Now that there are patches available to support S3TC compressed textures > > > on Radeon cards, are there any plans to integrate those patches into the > > > DRI source tree? > > > > Until an agreement can be reached between the open-source community and > > the patent holder, IT WILL NEVER HAPPEN! STOP ASKING!!! > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: IBM Linux Tutorials. > > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > -- > > _______________________________________________ > > Dri-devel mailing list > > Dri...@li... > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Linus T. <tor...@os...> - 2003-12-29 19:53:02
|
On Mon, 29 Dec 2003, Matt Sealey wrote: > > Ian: wouldn't it be possible to have an "official patch", for compressed > texture stuff, that tracks the trees & releases? I think that would be good, if somebody maintains it. It's pretty much guaranteed that anybody who has a modern graphics card has already been licensed for the patent, since the hw manufacturers would have done so already. So using the patch should be entirely legal, even if the DRI project may not want to worry about it. Especially a patch that only passes the compressed textures down to the hardware - it might make sense to not even have a software fallback. After all, the only people who care about this patch are game users, and those people likely do not want to see software fallbacks anyway. Once you do that, the software doesn't actually do anything that was patented. It's all in the hardware. Linus |
From: Daniel V. <vo...@ep...> - 2003-12-29 20:23:51
|
> It's pretty much guaranteed that anybody who has a modern > graphics card has already been licensed for the patent, > since the hw manufacturers would have done so already. FWIW, for the longest time SiS (now XGI) didn't have S3TC support for their Xabre Windows OpenGL drivers though supported it via DirectX/Direct3D. I guess they didn't feel like licensing the patent from a competitor. From the GL_EXT_texture_compression_s3tc specification: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same functionality in OpenGL. > Once you do that, the software doesn't actually do anything that was > patented. It's all in the hardware. I believe exposing the GL_EXT_texture_compression_s3tc and GL_ARB_texture_compression extensions implies the driver to handle S3TC compression as an application can pass in uncompressed data, ask the driver to compress it and then retrieve the compressed data. -- Daniel, Epic Games Inc. |
From: Linus T. <tor...@os...> - 2003-12-29 20:37:46
|
On Mon, 29 Dec 2003, Daniel Vogel wrote: > > FWIW, for the longest time SiS (now XGI) didn't have S3TC support for their > Xabre Windows OpenGL drivers though supported it via DirectX/Direct3D. I > guess they didn't feel like licensing the patent from a competitor. Interesting. > I believe exposing the GL_EXT_texture_compression_s3tc and > GL_ARB_texture_compression extensions implies the driver to handle S3TC > compression as an application can pass in uncompressed data, ask the driver > to compress it and then retrieve the compressed data. Sure. But do apps actually _do_ that? If the issue is to just make gamers happy, who cares what people _could_ do? And if it means that the code doesn't need to do something that might be patented, that's the right thing to do. I would not be surprised if the SiS issue was exactly that: the hardware was licensed, but not the software that allowed people to just ask the driver to do the compression for them. But I'm obviously not a lawyer. I do know that a lot of countries don't allow software patents anyway, and that it would be silly for the DRI project to not allow or encourage people in Europe to have their own patches. Linus |
From: Ian R. <id...@us...> - 2003-12-29 20:50:58
|
Daniel Vogel wrote: > I believe exposing the GL_EXT_texture_compression_s3tc and > GL_ARB_texture_compression extensions implies the driver to handle S3TC > compression as an application can pass in uncompressed data, ask the driver > to compress it and then retrieve the compressed data. The spec allows that behavior, but does not require it. The internalFormat specified to glTexImage2D is a *suggestion* that the driver can follow or not. If the app asks for GL_COMPRESSED_RGBA_S3TC_DXT1_EXT, it may get GL_RGBA8 or GL_COMPRESSED_RGBA_TXT1_3DFX. The final choice is entirely at the driver's discression. See also http://marc.theaimsgroup.com/?l=dri-devel&m=107178093226572&w=2 |
From: Daniel V. <vo...@ep...> - 2003-12-29 21:04:12
|
> > I believe exposing the GL_EXT_texture_compression_s3tc and > > GL_ARB_texture_compression extensions implies the driver to > > handle S3TC compression as an application can pass in > > uncompressed data, ask the driver to compress it and then > > retrieve the compressed data. > > The spec allows that behavior, but does not require it. D'oh, you're right. -- Daniel, Epic Games Inc. |
From: Andreas S. <A.S...@gm...> - 2003-12-29 21:29:45
|
Am 2003.12.29 21:23:45 +0100 schrieb(en) Daniel Vogel: [...] >=20 > I believe exposing the GL_EXT_texture_compression_s3tc and > GL_ARB_texture_compression extensions implies the driver to handle S3TC > compression as an application can pass in uncompressed data, ask the driv= er > to compress it and then retrieve the compressed data. >=20 > -- Daniel, Epic Games Inc. >=20 why not just advertise 4 for GL_NUM_COMPRESSED_TEXTURE_FORMATS and GL_COMPRESSED_RGB_DXT1_EXT GL_COMPRESSED_RGBA_DXT1_EXT GL_COMPRESSED_RGBA_DXT3_EXT GL_COMPRESSED_RGBA_DXT5_EXT for GL_COMPRESSED_TEXTURE_FORMATS And dont advertise the GL_EXT_texture_compression_s3tc extension. So programs would detect that theres no compression in the driver but that its ok to use precompressed textures. Andreas |
From: Alan C. <al...@lx...> - 2003-12-29 21:10:12
|
On Llu, 2003-12-29 at 19:52, Linus Torvalds wrote: > Especially a patch that only passes the compressed textures down to the > hardware - it might make sense to not even have a software fallback. > After all, the only people who care about this patch are game users, and > those people likely do not want to see software fallbacks anyway. The hardware also supports decompression of the texture since it can be told to render it offscreen at 1:1 magnification for each size, its not the nicest way to do it perhaps but that does avoid software issues. The only thing it seems you can't do is compress to S3TC in the driver, but I really don't see why that is ever needed ? As to a patch, moving texture compression formats in general to a standardised interface for software and using dlopen to load arbitary texture format libraries as needed is more modular anyway. |