[Dri-devel] Re: [Mesa3d-dev] Re: HEADSUP: Mesa move to freedesktop.org
Michel DÃnzer wrote: On Mon, 2003-12-29 at 02:45, Jon Smirl wrote: Would this also be a good time to move the DRM modules into the Mesa tree? Has it even been decided that's a good idea? I'm not sure it is; their being separate might help prevent compatibility problems with their interface, or at least recognize them quickly. I don't feel strongly either way though, just wondering. I've got a similar view - the drm may well be better off as a seperate project with a its own tree. Keith --- 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_id78&alloc_id371&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Re: HEADSUP: Mesa move to freedesktop.org
On Mon, Dec 29, 2003 at 09:35:38AM +, Keith Whitwell wrote: > Michel Dänzer wrote: > >On Mon, 2003-12-29 at 02:45, Jon Smirl wrote: > > > >>Would this also be a good time to move the DRM modules into the Mesa tree? > > > > > >Has it even been decided that's a good idea? I'm not sure it is; their > >being separate might help prevent compatibility problems with their > >interface, or at least recognize them quickly. I don't feel strongly > >either way though, just wondering. > > I've got a similar view - the drm may well be better off as a seperate > project with a its own tree. Doing it this way, we'd need to have regular releases of the DRM kernel modules and tag them with CVS keywords. But I'm all for this too. Alan. --- 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_id78&alloc_id371&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: HEADSUP: Mesa move to freedesktop.org
Jon Smirl wrote: The rework of of the dri drivers that I am doing is also dependent on parallel changes being made in the DRM drivers. I'd like to have them in the same cvs system so that I can keep things in sync. What the point of keeping them in the DRI tree if the only client of them now lives in the Mesa tree? We'd like to feel comfortable enough with the versioning mechanisms in place in the dri and drm that they can live in seperate trees. Your drivers should be able to figure out at runtime whether the drm has is new enough and either cope or exit with an error message. New drms must always work with old clients. Keith --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: HEADSUP: Mesa move to freedesktop.org
On Llu, 2003-12-29 at 09:45, Alan Hourihane wrote: > Doing it this way, we'd need to have regular releases of the DRM kernel > modules and tag them with CVS keywords. But I'm all for this too. This makes sense for development. Also in Linus proposed model the kernel framebuffer drivers are themselves consumers of base modules owning the hardware queues etc, so its got at least three owners. --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
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 --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
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 > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
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" <[EMAIL PROTECTED]> To: "Ian Romanick" <[EMAIL PROTECTED]> Cc: "DRI developer's list" <[EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED] > > 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 > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 4:00PM EST or 1:00PM PST, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
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 --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
I am not a lawyer. None of what follows is legal advice. Furthermore, I am speaking for myself alone, NOT my employer. Adam K Kirchhoff wrote: 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? Please forgive my frustration. I was yelling because apparently Allen Akin, Mike Harris, Brian, myself, and others saying that it's not going to happen for *years* in a normal tone of voice hasn't sunk into people's heads. At this point I'm strongly considering marking any message with the text "S3TC" in it as spam. http://marc.theaimsgroup.com/?l=dri-devel&m=104993712407263&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=104983843411445&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=104982146721455&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=104981082705861&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=104979949127559&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=104427973828003&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=104032667532589&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=103264830309986&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=103236369425011&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=98056163703227&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=98035135807986&w=2 http://marc.theaimsgroup.com/?l=dri-devel&m=97941445129143&w=2 Note that the earliest of these messages is from September of 2000. That's over *3* years ago! This has also been discussed to death at the weekly IRC meetings. http://dri.sourceforge.net/IRC-logs/ 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. My company has fairly strict policies about what sort of "policy" declarations like that employees can make for projects that we don't host. Otherwise, I can assure you I would have put that on the DRI main page ages ago. And then you shouldn't be surprised when peole stop using the open source DRI drivers in favor of closed source drivers. Right...the only cards that are supported by open-source and close-source drivers are R200-family chips on x86. Be my guest. Don't blame the distros or the open-source developers for not wanting to put their necks on the line and risk potentially years of legal woe for something as *trivial* as texture compression. We can live without S3TC. Games may not run as fast, but there are plenty of other areas in the R200 driver that can be optimized without risking any legal wrath. If *you* want to start your own CVS repository or distribute driver binaries with patent encumbered technology, knock yourself out. I strongly suspect that none of the people here that have anything to lose are going to take on that risk. --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] S3TC
> 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. --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] S3TC
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 --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
On Mon, 29 Dec 2003, Ian Romanick wrote: > I am not a lawyer. None of what follows is legal advice. Furthermore, > I am speaking for myself alone, NOT my employer. > > Adam K Kirchhoff wrote: > > 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? > > Please forgive my frustration. I was yelling because apparently Allen > Akin, Mike Harris, Brian, myself, and others saying that it's not going > to happen for *years* in a normal tone of voice hasn't sunk into > people's heads. At this point I'm strongly considering marking any > message with the text "S3TC" in it as spam. > > http://marc.theaimsgroup.com/?l=dri-devel&m=104993712407263&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=104983843411445&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=104982146721455&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=104981082705861&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=104979949127559&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=104427973828003&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=104032667532589&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=103264830309986&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=103236369425011&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=98056163703227&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=98035135807986&w=2 > http://marc.theaimsgroup.com/?l=dri-devel&m=97941445129143&w=2 Thanks for the list. You'll notice, however, that nowhere was it said by a representative of the DRI project that S3TC support (even of uploading precompressed textures) would never make it into the codebase till the legal issues were resolved. > Note that the earliest of these messages is from September of 2000. > That's over *3* years ago! > > This has also been discussed to death at the weekly IRC meetings. > > http://dri.sourceforge.net/IRC-logs/ One of the first hits for "Direct Rendering" and S3TC on google is: http://dri.sourceforge.net/faq.phtml There is no answer to the question: "Will the DRI ever get S3TC or could FXT1 be made to work in it's place?" However, if you're now saying that a decision *has* been made, I would highly recommend the FAQ be updated to show this. > > 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. > > My company has fairly strict policies about what sort of "policy" > declarations like that employees can make for projects that we don't > host. Otherwise, I can assure you I would have put that on the DRI main > page ages ago. > > > And then you shouldn't be surprised when peole stop using the open source > > DRI drivers in favor of closed source drivers. > > Right...the only cards that are supported by open-source and > close-source drivers are R200-family chips on x86. Be my guest. Don't > blame the distros or the open-source developers for not wanting to put > their necks on the line and risk potentially years of legal woe for > something as *trivial* as texture compression. We can live without > S3TC. Games may not run as fast, but there are plenty of other areas in > the R200 driver that can be optimized without risking any legal wrath. > > If *you* want to start your own CVS repository or distribute driver > binaries with patent encumbered technology, knock yourself out. I > strongly suspect that none of the people here that have anything to lose > are going to take on that risk. You're still assuming that it'd be a patent violation to allow the hardware to handle precompressed textures. I'd just as soon wait till Alan speaks with, and hears back from, the lawyers that he was going to talk to this about. Adam --- 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&
Re: [Dri-devel] S3TC
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. --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
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 --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] S3TC
> > 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. --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
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. --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3TC
Am 2003.12.29 21:23:45 +0100 schrieb(en) Daniel Vogel: [...] > > 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. > 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 --- 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_id78&alloc_id371&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] S3TC
> 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? You need it if you store your source art in a different format on disk (e.g. using jpeg) and don't want to deal with compression yourself - I believe e.g. Quake III does this. Most other games at the moment (definitely ours) just pass textures pre-compressed to the API. -- Daniel, Epic Games Inc. --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Join forces towards DRI support for Savage4, Twister, Prosavage?
On Thu, 25 Dec 2003 20:00:48 -0800 (PST), Alex Deucher wrote: >--- Felix Khling <[EMAIL PROTECTED]> wrote: >> Alex Deucher <[EMAIL PROTECTED]> wrote: >> >> After a brief look at the utah driver: the S3 driver is definitely >> not >> based on the utah-driver. They are completely different. However, the >> register defines look very similar. There is also a BCI and the >> primitive types and vertex formats are encoded in the same way. I >> havn't >> checked the 3D state registers in detail. The savage4 driver uses DMA >> buffers to transfer commands, the savage IX driver uses the BCI. I >> don't >> know if the savage IX didn't have busmaster DMA capabilities, at >> least >> the relevant register defines are missing in the utah driver. > >Tim, I don't suppose you could help clarify the situation with savage3D >vs savage4 when it comes to DMA/BCI? I thought the BCI was a command >processor like the CP on r128/radeon/r200, but it's been a while since >I messed with the savage driver. All of the Savage/ProSavage/SuperSavage chips support both BCI-through-FIFO and BCI-through-DMA. S3's Windows drivers use the DMA path exclusively, because there is a bug in the Savage4 engine (which is also in the ProSavages) that causes about 10% of the chips to lock up when reading the FIFO status register. This is the "scrolling hang" referred to on my web site. (You would think that simulations would have uncovered a problem in the single most important register in the entire chip, but I digress...) I assume the Savage/IX driver uses BCI-through-FIFO because it avoids the need for DMA kernel assistance, but the Savage4 scheme should work there just as well. If there is a strong desire, I could scan through the documents and see if any of the DMA registers have different addresses, but when I was working on the Savage Windows NT drivers, I did some experiments and learned that DMA only bought about 10% additional performance. -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. --- 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_id78&alloc_id371&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] CONFIG_X86_CMPXCHG needs to be enabled in the kernal
Hi there, I have just switched to Gentoo Linux (2.4.20 Kernel) and I have downloaded a dripkg installation install.sh script. Unfortunately trying to install provides me with the following listing in the dri.log. I have emerged xfree-drm but still no joy. Apparently it would seem that I have not got CONFIG_X86_CMPXCHG enabled in the kernel. How would I find out if this is true (I greped /proc/config for cmpxchg and got nothing at all in response) and then how would I go about doing it. Any more info you need I will glee-fully provide! Anyways, I'm really stuck now and I'm running out of coffee so I'd really appreciate some help. Thankyou for your time and efforts, Owen Thomson. http://www.owenshouse.net make -f Makefile.linux DRM_MODULES=tdfx.o modules make[1]: Entering directory `/root/dripkg/drm' make -C /lib/modules/2.4.20-gentoo-r6/build SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules make[2]: Entering directory `/usr/src/linux-2.4.20-gentoo-r6' make -C /root/dripkg/drm CFLAGS="-D__KERNEL__ -I/usr/src/linux-2.4.20-gentoo-r6/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i386 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.20-gentoo-r6/include/linux/modversions.h" MAKING_MODULES=1 modules make[3]: Entering directory `/root/dripkg/drm' Makefile:264: *** CONFIG_X86_CMPXCHG needs to be enabled in the kernel. Stop. make[3]: Leaving directory `/root/dripkg/drm' make[2]: *** [_mod_/root/dripkg/drm] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.20-gentoo-r6' make[1]: *** [modules] Error 2 make[1]: Leaving directory `/root/dripkg/drm' make: *** [tdfx.o] Error 2 Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Recent driinterface-0-0-2-branch changes
Ian Romanick wrote: Log message: All of the libglx.a and libGLcore.a code now uses __GLcontextModes to track FBconfigs / visuals. Just a heads up. The next step will be to enable "fake" support for SGIX_fbconfig on the server-side. Basically, I will just assign an FBconfig ID to the visuals supplied by the DDX driver. Once that is done and the server-side protocol support is added, we'll be able to advertise SGIX_fbconfig! Yay. Once that is done, I would like to have help modifying *all* of the drivers to use the new interfaces. After that, I think it will be safe to merge it all to the trunk. There is a subtle issue there, which was discussed some at the dri-devel chat today. Where should the per-driver changes be committed? We came up with three options, and, quite frankly, I'm not too fond of any of them. 1. Commit the changed files to the DRI tree and patch up the Imakefiles to use the files in the DRI tree instead of the unchanged files in the Mesa tree. 2. Create a driinterface-0-0-2 branch in the Mesa tree and commit the changes there. 3. Commit the changes to the trunk of the Mesa tree. The modified drivers need to work with old libGL.so binaries, and this would be a way to be sure of that. :) Option #1 is, after further consideration, really bad. Options #2 and #3 are close, but I'm leaning towards #3. Opinions? --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-12-29 23:41 --- DRI was enabled when i aplied this patch XFree86-4.4-20031205-igp.patch to xfree.4.3.99.16, but when the same patch i applied to XFree86-4.3.99.902 , there is no DRI enabled. It's complaining of not able open the drm device under /dev and I couldn't find any relevant change in the change.log that may be the problem. so i did some experiment modprobing the old radeon.o, lsmod shows that agpgart is used. but when i modprobe the new radeon.o , agpgart is unused. what may be the problem ? -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
