Hi everyone, I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, but I've got a problem. The function most convert a loaded surface's data to a user specified surface format (I did not yet find a way to do it elsehow, UpdateTexture and StretchRect are to limited for that task, suggestions welcome if I missed anything). Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 surface to DXT1 (or to save a surface to a DXTn compressed DDS file), I'm not sure wether I can implement that behavior; on #winehackers I was told that the (de)compression part is coverered by S3's patents, but the Gimp DDS plugin and this (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS solutions for it anways. So... Can anybody tell me for sure wether I may implement this code or not?
Best regards, Tony
2009/5/22 Tony Wasserka tony.wasserka@freenet.de:
Hi everyone, I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, but I've got a problem. The function most convert a loaded surface's data to a user specified surface format (I did not yet find a way to do it elsehow, UpdateTexture and StretchRect are to limited for that task, suggestions welcome if I missed anything). Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 surface to DXT1 (or to save a surface to a DXTn compressed DDS file), I'm not sure wether I can implement that behavior; on #winehackers I was told that the (de)compression part is coverered by S3's patents, but the Gimp DDS plugin and this (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS solutions for it anways. So... Can anybody tell me for sure wether I may implement this code or not?
Best regards, Tony
If it counts for anything, I'd like to see a converter going the other way (bug 14939).
On Fri, May 22, 2009 at 2:08 PM, Ben Klein shacklein@gmail.com wrote:
2009/5/22 Tony Wasserka tony.wasserka@freenet.de:
Hi everyone, I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, but I've got a problem. The function most convert a loaded surface's data to a user specified surface format (I did not yet find a way to do it elsehow, UpdateTexture and StretchRect are to limited for that task, suggestions welcome if I missed anything). Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 surface to DXT1 (or to save a surface to a DXTn compressed DDS file), I'm not sure wether I can implement that behavior; on #winehackers I was told that the (de)compression part is coverered by S3's patents, but the Gimp DDS plugin and this (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS solutions for it anways. So... Can anybody tell me for sure wether I may implement this code or not?
Best regards, Tony
If it counts for anything, I'd like to see a converter going the other way (bug 14939).
Note that there is some basic s3tc support in mesa these days which you can activate using driconf. I forgot what its limitations are. I believe it is enough for rendering.
Roderick
You may find this helpful: http://code.google.com/p/nvidia-texture-tools/
Wrt the legalese check the last question here: http://code.google.com/p/nvidia-texture-tools/wiki/FAQ
Using a proven library for s3tc handling is a good idea even without the legal troubles. s3tc decompression isn't rocket science, but s3tc compression is harder than it seems. Nvidia, ATI and Microsoft have fought a long battle for the best s3tc compression algorithm. For a long time s3tc was considered bad because there was no really good compressor - so I recommend not to reinvent the wheel here.
On Fri, May 22, 2009 at 6:11 PM, Stefan Dösinger stefandoesinger@gmx.at wrote:
You may find this helpful: http://code.google.com/p/nvidia-texture-tools/
Wrt the legalese check the last question here: http://code.google.com/p/nvidia-texture-tools/wiki/FAQ
Using a proven library for s3tc handling is a good idea even without the legal troubles. s3tc decompression isn't rocket science, but s3tc compression is harder than it seems. Nvidia, ATI and Microsoft have fought a long battle for the best s3tc compression algorithm. For a long time s3tc was considered bad because there was no really good compressor - so I recommend not to reinvent the wheel here.
So what they are saying is that Nvidia has a license on the s3tc patent for use in those tools but if we would rip their code out we wouldn't be covered unless (but that is gray area) we put all their image code in wine (which would be impossible since it is C++). Perhaps if we want to be safe we could ask s3 for a license for use in Wine?
Roderick
Am Freitag, 22. Mai 2009 19:15:22 schrieb Roderick Colenbrander:
So what they are saying is that Nvidia has a license on the s3tc patent for use in those tools but if we would rip their code out we wouldn't be covered unless (but that is gray area) we put all their image code in wine (which would be impossible since it is C++). Perhaps if we want to be safe we could ask s3 for a license for use in Wine?
Hmm. My idea would have been to link against this lib, but if it is C++ it makes troubles.
2009/5/23 Stefan Dösinger stefandoesinger@gmx.at:
Am Freitag, 22. Mai 2009 19:15:22 schrieb Roderick Colenbrander:
So what they are saying is that Nvidia has a license on the s3tc patent for use in those tools but if we would rip their code out we wouldn't be covered unless (but that is gray area) we put all their image code in wine (which would be impossible since it is C++). Perhaps if we want to be safe we could ask s3 for a license for use in Wine?
Hmm. My idea would have been to link against this lib, but if it is C++ it makes troubles.
Interestingly enough, nvidia-texture-tools is MIT license and provides no provision for patent protection. In theory, a fork of this project to C would be linkable with Wine without legal issues.
Ben Klein schrieb:
2009/5/23 Stefan Dösinger stefandoesinger@gmx.at:
Am Freitag, 22. Mai 2009 19:15:22 schrieb Roderick Colenbrander:
So what they are saying is that Nvidia has a license on the s3tc patent for use in those tools but if we would rip their code out we wouldn't be covered unless (but that is gray area) we put all their image code in wine (which would be impossible since it is C++). Perhaps if we want to be safe we could ask s3 for a license for use in Wine?
Hmm. My idea would have been to link against this lib, but if it is C++ it makes troubles.
Interestingly enough, nvidia-texture-tools is MIT license and provides no provision for patent protection. In theory, a fork of this project to C would be linkable with Wine without legal issues.
Their FAQ states that "[we] don't have to obtain a license of the S3TC patent to use any of NVIDIA's products" but it also adds that "certain uses of NVIDIA Texture Tools source code cannot be considered NVIDIA products anymore." Thus, forking the project and integrating it into Wine would probably have the same legal status as writing an own S3TC (de)compressor within Wine. Seems like asking for a license or directly using the binaries of this lib are the only options we have then. Forking NVIDIA TT and disable it by default would probably not be accepted by AJ I guess...
2009/5/22 Tony Wasserka tony.wasserka@freenet.de:
Hi everyone, I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, but I've got a problem. The function most convert a loaded surface's data to a user specified surface format (I did not yet find a way to do it elsehow, UpdateTexture and StretchRect are to limited for that task, suggestions welcome if I missed anything). Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 surface to DXT1 (or to save a surface to a DXTn compressed DDS file), I'm not sure wether I can implement that behavior; on #winehackers I was told that the (de)compression part is coverered by S3's patents, but the Gimp DDS plugin and this (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS solutions for it anways. So... Can anybody tell me for sure wether I may implement this code or not?
What it comes down to is that I don't think we want to take that risk, so essentially "No".
I believe mesa looks for libtxc_dxtn @ http://homepage.hispeed.ch/~rscheidegger/dri_experimental/s3tc_index.html and then enables full s3tc support. The library itself is tiny and in (ugly) C, so that is already good news. But as stated on the website, you cannot use the code due to legality. Maybe there would be a way to do on-demand loading as with mesa and output a warn/fixme if the library is not found? It seems like the approach would be similar to the way the font bytecode interpreter was handled (turn on if available).
On a sidenote, I may not know what I'm talking about so feel free to completely disagree.
Mike.
On Sat, May 23, 2009 at 4:48 PM, Henri Verbeet hverbeet@gmail.com wrote:
2009/5/22 Tony Wasserka tony.wasserka@freenet.de:
Hi everyone, I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, but I've got a problem. The function most convert a loaded surface's data to a user specified surface format (I did not yet find a way to do it elsehow, UpdateTexture and StretchRect are to limited for that task, suggestions welcome if I missed anything). Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 surface to DXT1 (or to save a surface to a DXTn compressed DDS file), I'm not sure wether I can implement that behavior; on #winehackers I was told that the (de)compression part is coverered by S3's patents, but the Gimp DDS plugin and this (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS solutions for it anways. So... Can anybody tell me for sure wether I may implement this code or not?
What it comes down to is that I don't think we want to take that risk, so essentially "No".
Am Sonntag, 24. Mai 2009 21:11:27 schrieb Mike Kaplinskiy:
I believe mesa looks for libtxc_dxtn @ http://homepage.hispeed.ch/~rscheidegger/dri_experimental/s3tc_index.html and then enables full s3tc support. The library itself is tiny and in (ugly) C, so that is already good news. But as stated on the website, you cannot use the code due to legality. Maybe there would be a way to do on-demand loading as with mesa and output a warn/fixme if the library is not found? It seems like the approach would be similar to the way the font bytecode interpreter was handled (turn on if available).
Wine did that a while ago, prior to my ddraw rewrite. However, from testing it seems that the S3TC decompression of that lib did not work properly(Gothic 2 showed bad textures), and the compression code according to that site is ugly.
So my 2c is that we need a better library than this libtxc_dxtn stuff. Maybe we can get a C wrapper around the nvidia texture tools lib in place. The nvidia texture tools also have command line utilities - maybe that works.
Note that I don't think we can ship nvidia texture tools, but we can load the lib dynamically and enable / disable. Maybe we should require the Win32 version, not the Linux version, and handle it similarily to gecko.
-
Ben Klein -
Henri Verbeet -
Mike Kaplinskiy -
Roderick Colenbrander -
Stefan Dösinger -
Tony Wasserka