Re: S3TC/DXTC patch status
On Thu, Jun 03, 2004 at 01:34:58AM +0200, Roland Scheidegger wrote: [EMAIL PROTECTED] wrote: Hi, I'd like to know where is the texture compression now? Has it been integrated to the mesa tree or is it still provided in a separate library ? It is still in a separate library, the legal issues have not changed. Is it possible to integrate s3tc but ship with it disabled, similar to how FreeType operates regarding the hinting patents owned by apple? Then individual distributors can choose whether or not to enable it depending on their location. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Xorg] DRI merging
On Sat, 12 Jun 2004 16:44:43 +0200, Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2004-06-11 at 23:17 -0700, Eric Anholt wrote: I would like to see a merge from DRI CVS to X.Org in the near future. Is there any opposition to this? No opposition, but a concern: Where are we going to integrate the DRI with the Composite extension, in the X.Org or DRI tree? I'd be in favour of moving the DRI tree to a branch of the X.Org tree altogether, but I'd like to hear what other people's current opinions are on this. I agree. While we are on the subject, there are also two big patches that ought to be merged at some point which could make the merge from the DRI somewhat more complicated. The first is Ati's new radeon code drop (with revamped crtc handling, r4xx suppot, and render accel) and the second is the new intel DDX. since the intel driver now supports multi-head and ryan's latest work removes the hallib requirements from the matrox driver, it might be a good time to decide how to proceed with mergedfb. right now it's all DDX specific code, but most of it could be made generic, which would make it easier to support mergedfb in all the drivers that currently support dualhead (intel, matrox, sis, radeon, etc.). Doing this may, however, affect compatibility with xfree86 unless they picked up the patches. Talking with daniels on irc, I understand there might be license concerns floating around. DRI CVS hasn't had a merge from XFree86 since 4.3.99.12, which was before the license changes. Yeah, I've always voiced my opinion against infecting the DRI tree with the new XFree86 licence. I don't know about the X-Oz licence though. I'd rather not mess with that either. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sat, 2004-06-12 at 08:40, Alex Deucher wrote: On Sat, 12 Jun 2004 16:44:43 +0200, Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2004-06-11 at 23:17 -0700, Eric Anholt wrote: I would like to see a merge from DRI CVS to X.Org in the near future. Is there any opposition to this? No opposition, but a concern: Where are we going to integrate the DRI with the Composite extension, in the X.Org or DRI tree? I'd be in favour of moving the DRI tree to a branch of the X.Org tree altogether, but I'd like to hear what other people's current opinions are on this. I agree. While we are on the subject, there are also two big patches that ought to be merged at some point which could make the merge from the DRI somewhat more complicated. The first is Ati's new radeon code drop (with revamped crtc handling, r4xx suppot, and render accel) and the second is the new intel DDX. since the intel driver now supports multi-head and ryan's latest work removes the hallib requirements from the matrox driver, it might be a good time to decide how to proceed with mergedfb. right now it's all DDX specific code, but most of it could be made generic, which would make it easier to support mergedfb in all the drivers that currently support dualhead (intel, matrox, sis, radeon, etc.). Doing this may, however, affect compatibility with xfree86 unless they picked up the patches. I'm working on the Render acceleration -- there were some conformance issues in the ATI patch that I'm working on fixing, along with making it more featureful. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sat, 2004-06-12 at 07:44, Michel Dänzer wrote: On Fri, 2004-06-11 at 23:17 -0700, Eric Anholt wrote: I would like to see a merge from DRI CVS to X.Org in the near future. Is there any opposition to this? No opposition, but a concern: Where are we going to integrate the DRI with the Composite extension, in the X.Org or DRI tree? I'd be in favour of moving the DRI tree to a branch of the X.Org tree altogether, but I'd like to hear what other people's current opinions are on this. I was hoping that DRI work on pbuffers might go quickly and have the drivers ready for rendering to targets besides the screen, which is what we really need for Composite support. The other thing would be Damage, but that'll be easy I think. I assume this would be done in the tree where Composite gets integrated first, but again, I don't expect it to be too hard if we can render to other targets. I am definitely in favor of the DRI X tree stuff being a branch on the X.Org tree. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: updated i830 texture compression patch
Am Donnerstag, 10. Juni 2004 11:59 schrieb Dieter Nützel: Am Dienstag, 8. Juni 2004 00:14 schrieb Roland Scheidegger: Dave Airlie wrote: I've fixed the FXT support but DXT1 RGB is still knackered and probably won't be fixed... http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff Roland can you update your patch with this verson? Done (I've changed it slightly though since you can use fxt without the dxt library). New version: http://homepage.hispeed.ch/rscheidegger/dri_experimental/mesa_r200_radeon _i 830_txc_cvs040607.diff.gz Library still the same: http://homepage.hispeed.ch/rscheidegger/dri_experimental/libtxc_dxtn04052 4. tar.gz Do not apply after latest Mesa CVS update. I've removed the i830 stuff from your latest patch (applies with only one off) but get this: quake3 * after the splash screen finished there is a white background behind the menu. * 'console' is empty (white), too * icons are wrong * all textures are missing in game seta r_ext_compressed_textures 0 cure it Appart from S3TC I get this with Celestia: * fonts are off by (one?) * textures are wrong for distance LIBGL_ALWAYS_INDIRECT cure it all. ut2003_demo and ut2004demo works OK so far. Greetings, Dieter --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: updated i830 texture compression patch
Dieter Nützel wrote: Am Donnerstag, 10. Juni 2004 11:59 schrieb Dieter Nützel: Am Dienstag, 8. Juni 2004 00:14 schrieb Roland Scheidegger: Dave Airlie wrote: I've fixed the FXT support but DXT1 RGB is still knackered and probably won't be fixed... http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff Roland can you update your patch with this verson? Done (I've changed it slightly though since you can use fxt without the dxt library). New version: http://homepage.hispeed.ch/rscheidegger/dri_experimental/mesa_r200_radeon _i 830_txc_cvs040607.diff.gz Library still the same: http://homepage.hispeed.ch/rscheidegger/dri_experimental/libtxc_dxtn04052 4. tar.gz Do not apply after latest Mesa CVS update. I've removed the i830 stuff from your latest patch (applies with only one off) but get this: quake3 * after the splash screen finished there is a white background behind the menu. * 'console' is empty (white), too * icons are wrong * all textures are missing in game seta r_ext_compressed_textures 0 cure it Hmm. Forgot to update the patch, will do it next week. Not sure why it wouldn't work though currently (with the i830 stuff removed). Appart from S3TC I get this with Celestia: * fonts are off by (one?) * textures are wrong for distance That looks to be the same problem as the one reported with Freespace? (see thread Mesa bug in new teximage code) Roland --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sat, Jun 12, 2004 at 11:40:42AM -0400, Alex Deucher wrote: multi-head and ryan's latest work removes the hallib requirements from the matrox driver, Not yet. Hopefully soon. :) -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Xorg] DRI merging
Why not help getting mesa-solo working so that we can move to X on top of OpenGL? Keithp is hard at work converting xserver to run on OpenGL. We already have the render engine on top of of OpenGL finished in the glitz project. All we are missing is pbuffer support in the mesa hw drivers and some support for multi-head mode setting. In the xserver on OpenGL model XAA disappears. --- Eric Anholt [EMAIL PROTECTED] wrote: I'm working on the Render acceleration -- there were some conformance issues in the ATI patch that I'm working on fixing, along with making it more featureful. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
On Sat, 2004-06-12 at 19:07, Jon Smirl wrote: Why not help getting mesa-solo working so that we can move to X on top of OpenGL? Keithp is hard at work converting xserver to run on OpenGL. We already have the render engine on top of of OpenGL finished in the glitz project. All we are missing is pbuffer support in the mesa hw drivers and some support for multi-head mode setting. In the xserver on OpenGL model XAA disappears. --- Eric Anholt [EMAIL PROTECTED] wrote: I'm working on the Render acceleration -- there were some conformance issues in the ATI patch that I'm working on fixing, along with making it more featureful. As far as I understood, Mesa-solo required the linux framebuffer, which I don't have. I seriously don't want to be the one to start work on the mode-setting library. As far as pbuffers, once we've got the glue necessray I'll fix up the SiS driver for it, which should be quick. But all of this will take time to be done, and they aren't areas I've already worked in. Render, now, I should be able to fix this patch up in another day or maybe two, and make myself and normal users happy in the short term. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] DRI merging
--- Eric Anholt [EMAIL PROTECTED] wrote: As far as I understood, Mesa-solo required the linux framebuffer, which I don't have. I seriously don't want to be the one to start work on the mode-setting library. As far as pbuffers, once we've got the glue necessray I'll fix up the SiS driver for it, which should be quick. But all of this will take time to be done, and they aren't areas I've already worked in. Render, now, I should be able to fix this patch up in another day or maybe two, and make myself and normal users happy in the short term. I added mode setting support to DRM while you were gone. That caused a big stink and it is not in there now. There is a meeting scheduled at OLS to discuss the issues between DRM and fbdev. The complicated part of mode setting is what do you do when there are multiple heads involved? If multiple head mode setting stays in fbdev then fbdev needs to do memory management but DRM does complicated memory management that is not in fbdev. Another large point of contention is whether mode setting should be done completely in the kernel including DDC support. The alternate solution is to read DDC from user space and compute the mode info there. Then just pass the final register values into the driver. I also added a hot plug event to DRM to trigger a user space reset program than ran in vm86 mode, but that's been pulled too. Read the dri-devel and fbdev mail archives, there are hundreds of messages on this subject. Other topics that were discussed included printk with DRM and rework of the kernel VT subsystem. If I could get reset, mode setting, and cursor support into DRM mesa-solo wouldn't need framebuffer anymore. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
